"Зсув вліво" (shift left) означає перенесення перевірок безпеки з передрелізного шлюзу до найранішої точки, де дефект дешево виправити — у редактор розробника та в pull request. Економіку добре задокументовано: дослідження NIST та IBM стабільно показують, що баг, спійманий на етапі проєктування чи написання коду, коштує частку від вартості бага, знайденого у проді. Але зсув вліво — це не купівля нових сканерів. Це розміщення потрібного контролю на потрібному етапі, його налаштування так, щоб інженери йому довіряли, і чесне визнання того, чого автоматизація знайти не може.
Почніть до коду: моделювання загроз
Найдешевша для виправлення вразливість — та, яку ви усуваєте на етапі проєктування. Моделювання загроз належить до стадії дизайну функції, а не до моменту після неї. Важкий процес не потрібен — 30-хвилинної сесії за чотирма питаннями з Threat Modeling Manifesto достатньо для більшості задач: Що ми будуємо? Що може піти не так? Що ми з цим зробимо? Чи добре ми впоралися?
Використовуйте STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) як підказку для кожного потоку даних, що перетинає межу довіри. Новий ендпоінт, який приймає URL від користувача, негайно піднімає прапорець Server-Side Request Forgery (OWASP A10:2021, CWE-918); нове завантаження файлів — path traversal (CWE-22) та необмежене завантаження (CWE-434). Зафіксуйте висновки як критерії приймання з безпеки в тикеті, щоб вони були перевірюваними, а не декларативними.
Пайплайн: чотири автоматичні шари
Прагматичний пайплайн запускає дедалі важчі перевірки в міру просування коду до проду. Швидкі перевірки блокують кожен коміт; повільні та "галасливі" працюють поза основним шляхом.
- Pre-commit / IDE: сканування секретів (gitleaks, trufflehog) і лінтери. Перехоплення секрету, що витік, до потрапляння у віддалений репозиторій економить інцидент із ротацією ключів. Цей шар має бути майже миттєвим.
- SAST на pull request: Static Application Security Testing аналізує вихідний код без його запуску — ефективно проти ін'єкцій, зашитих секретів і небезпечних API. Інструменти на кшталт Semgrep, CodeQL чи SonarQube працюють за хвилини. Ключове правило: блокуйте лише за правилами з високою достовірністю. SAST-шлюз, що заливає PR хибними спрацюваннями, буде проігноровано або вимкнено протягом одного спринту.
- SCA / сканування залежностей: Software Composition Analysis — мабуть, контроль із найвищим ROI, бо більшість сучасного коду є стороннім. Запускайте
npm audit, OWASP Dependency-Check, Trivy або Snyk по згенерованому SBOM (CycloneDX або SPDX). Звіряйтеся з каталогом CISA KEV і пріоритизуйте за показником EPSS, а не за сирим CVSS — CVSS 9.8 без відомого експлойта часто менш терміновий, ніж 7.5, що активно використовується в атаках. - DAST на staging: Dynamic Application Security Testing перевіряє працюючий застосунок ззовні. OWASP ZAP або Nuclei можуть запускати пасивний базовий скан при кожному деплої та повний активний скан щоночі. DAST знаходить проблеми часу виконання, невидимі для SAST — неправильно налаштовані заголовки, дефекти автентифікації, відбитий XSS у відрендереній відповіді.
Зробіть шлюзи вартими довіри
Головний сценарій провалу зсуву вліво — втома від алертів. Якщо сканер видасть 400 знахідок на першому запуску і заблокує збірку, розробники його обійдуть. Захищайте співвідношення сигнал/шум свідомо:
- Блокуйте збірку лише на нових знахідках високої критичності та високої достовірності, внесених поточною зміною — використовуйте базову лінію/дифф, щоб старий борг не блокував сьогоднішній PR.
- Оформлюйте придушення як код. Кожна проігнорована знахідка отримує задокументовану причину та власника у файлі під контролем версій, а не клік у дашборді.
- Відстежуйте SLA з усунення вразливостей за критичністю. Наприклад: критичні — за 7 днів, високі — за 30, середні — за 90. Вимірюйте середній час до усунення, а не лише кількість відкритих задач.
- Зводьте все в одне місце. Агрегація виводу SAST/DAST/SCA (наприклад, через DefectDojo або формат SARIF у вашому код-хості) дедуплікує знахідки та дає єдину картину ризику.
Де ручний пентест досі незамінний
Автоматизація — це підлога, а не стеля. Сканери зіставляють шаблони; вони структурно сліпі до дефектів, що вимагають розуміння задуму. Жоден SAST- чи DAST-інструмент надійно не знайде:
- Дефекти бізнес-логіки — купівля товару у від'ємній кількості, пропуск кроку оплати, стани гонитви (race conditions) в оформленні замовлення. Це вимагає людини, яка розуміє, що застосунок має робити.
- Порушення контролю доступу та IDOR (OWASP A01:2021, CWE-639) — сканер не знає, що користувач A не повинен читати рахунок користувача B. Авторизація — це контекст, а контексту потрібен тестувальник.
- Ланцюжки експлойтів — незначний витік інформації плюс надто ліберальна політика CORS плюс слабкий контроль сесії можуть скластися у повне захоплення акаунта. Інструменти оцінюють знахідки ізольовано; атакувальники їх пов'язують.
Корисна періодичність: безперервне автоматичне тестування при кожній зміні, точковий ручний пентест при кожному великому релізі чи суттєвій зміні архітектури та щорічне повномасштабне залучення — відповідно до методологій OWASP WSTG і PTES. Якщо ви підпадаєте під PCI DSS, щорічні пентести й пентести після суттєвих змін — жорстка вимога, а не опція.
Порядок впровадження
Не перемикайте всі шлюзи в режим "блокування" першого ж дня. Запустіть нові інструменти в режимі лише-звіт на один-два спринти, приглушіть шум, узгодьте SLA з інженерами і лише потім вмикайте примус. Почніть зі сканування секретів і SCA — вони мають найкращий сигнал і найзрозуміліші виправлення — потім додайте SAST, а наприкінці DAST. Зсув вліво досягає успіху, коли безпека стає фоновою властивістю пайплайну, яку розробники майже не помічають, і провалюється в мить, коли перетворюється на податок, що їх дратує.