Чому DAST запускають пізно і вразливості потрапляють у реліз
Динамічне сканування застосунків у більшості команд живе окремо від конвеєра збірки та доставки. Його запускають вручну — перед великим релізом або після того, як зовнішній підрядник приніс черговий звіт.
Статичний аналіз при цьому стоїть у збірці й стримує злиття змін, а DAST залишається разовою процедурою на стороні.
Причина зрозуміла: динамічному сканеру потрібен розгорнутий стенд, облікові записи під різні ролі й наповнені тестові дані.
Піднімати це середовище на кожну зміну здається занадто дорогим, тому перевірку виносять у кінець циклу — коли застосунок уже зібрано повністю й «майже готовий».
Ціна такої економії — вразливості в робочому середовищі. Знахідка приходить, коли код уже віддано користувачам, і закривати її доводиться позаплановим випуском: термінова правка, повторна збірка, ручний прогін зачеплених сценаріїв.
Вікно між появою дефекту та його виправленням розтягується на тижні, а частина проблем на цей момент уже видна ззовні.
Другий ефект — перевірка безпеки перед релізом перетворюється на разове погодження. Звіт читають після викатки, пріоритети розставляють за інтуїцією, а повторювані дефекти переходять з релізу в реліз.
Нижче розбираємо, як це закривається: що потрібно, щоб динамічне сканування працювало всередині спільного конвеєра й віддавало результат до викатки.
Ефект від пошуку вразливостей на кожній збірці конвеєра
Автоматичне сканування на кожній збірці стискає вікно між появою вразливості та її виявленням з тижнів до годин. Поки стенд піднімається після викатки, OWASP ZAP обходить застосунок у режимі активного сканування й складає звіт у той самий прогін, що й автотести. Розробник отримує дефект у контексті своєї правки, а не через місяць на прийманні.
Це змінює структуру знахідок. Частка вразливостей, спійманих до релізу, зазвичай зростає з половини до дев'яти з десяти — решта припадає на логіку доступу, яку сканер не перевіряє.
Клас відмов, який закривається повністю: доступні без авторизації маршрути, відсутні заголовки безпеки, застарілі бібліотеки з відомими дефектами.
Раннє виявлення вразливостей скорочує ручні перевірки не за рахунок якості, а за рахунок перебору. Інженер перестає проходити типові сценарії вручну й зосереджується на ролях і граничних станах.
Час доставки змін падає, бо перевірка йде паралельно збірці й не потребує окремого етапу погодження.
Метрики, за якими видно ефект: час від правки до першого звіту сканера, частка збірок зі знахідками, відношення закритих дефектів до відкритих за тиждень, кількість ручних перевірок на реліз.
Якщо ці числа не рухаються — конвеєр налаштований формально, і це перше, що ми розбираємо під час аудиту.
Режими запуску DAST: збірка, розклад, ручний прогін
Динамічний аналіз працює не з вихідним кодом, а із запущеним застосунком: поки стенд не відповідає на запити й не пускає під обліковим записом, сканеру нічого перевіряти.
Тому режим запуску вибирають за доступністю стенда й за тим, скільки часу прогін може зайняти в конвеєрі, — а не за зручністю налаштування.
| Режим запуску | Коли підходить | Обмеження та вартість підтримки |
|---|---|---|
| За подією збірки | Потрібен швидкий сигнал на кожну зміну: стенд розробки, ключові маршрути, заголовки безпеки | Прогін займає конвеєр, хибні спрацювання гальмують випуск — потрібні опорний звіт і список винятків |
| За розкладом | Нічний глибокий обхід копії промислового контуру, включно з активними перевірками | Стенд має жити постійно, а звіт хтось розбирає вранці |
| Ручний прогін | Перед великим випуском, після зміни схеми авторизації, при підключенні зовнішнього контуру | Регулярності немає: між прогонами знахідки накопичуються непоміченими |
| Гібрид: короткий прогін на збірці плюс глибокий за розкладом | Часті випуски в сервісах з особистим кабінетом і оплатою | Дорожче в налаштуванні: два профілі, розмежування стендів, єдина точка розбору знахідок |
Вимоги до середовища в усіх режимах однакові: сканеру потрібен обліковий запис із правом обходу, стенд з відтворюваними даними й опорний звіт щодо вже відомих знахідок. Без цього кожна збірка буде червоною, і команда перестане відкривати звіт — незалежно від вибраного режиму.
Практичний порядок такий: спочатку піднімають ручний прогін і фіксують, що сканер узагалі бачить у вашому застосунку, потім переносять його на розклад, і тільки після цього додають запуск за подією збірки з урізаним профілем. Такий перехід дає регулярні перевірки, не перетворюючи конвеєр на вузьке місце.
Як ми вбудовуємо DAST у конвеєр: етапи робіт
Впровадження DAST починається не зі сканера, а з інвентаризації: які сервіси та стенди перевіряємо, під якими ролями заходимо, які маршрути критичні для бізнесу. Без цього сканер упирається у форму входу й віддає звіт по одній сторінці — перевірка формально є, користі немає.
- Інвентаризація цілей. Список адрес, тестові облікові записи на кожну роль, обмеження за навантаженням і вікно запуску, безпечне для стенда.
- Схема запуску. Коротка перевірка йде на кожну зміну після викатки, повна — за розкладом. Зворотний зв'язок приходить хвилинами, а не до кінця тижня.
- Налаштування сценаріїв обходу. Вхід у систему, продовження сесії, обхід за специфікацією API й обхід інтерфейсу: форми, параметри, приховані поля, яких у специфікації немає.
- Відсікання шуму. Винятки фіксуємо з обґрунтуванням і датою перегляду, знахідки ділимо на підтверджені та ті, що потребують ручної перевірки. Інакше звіт за місяць перестають читати.
- Поріг якості збірки. Блокують лише підтверджені вразливості високого рівня на критичних маршрутах, решта йде попередженням. Поріг погоджуємо з розробкою: занадто суворий швидко вимикають.
- Перевірка на контрольних вразливостях. Підсаджуємо на стенд навмисну вразливість і переконуємося, що вона потрапила у звіт. Не потрапила — правимо сценарій, а не довіру до інструмента.
- Регламент розбору знахідок. Фіксуємо, хто і в який термін розбирає звіт, куди йде задача, як підтверджується закриття. Звіт за кожним запуском залишається в артефактах збірки.
Після передачі регламенту конвеєр працює без нас: нові сервіси додаються до схеми за чек-лістом, а поріг якості правиться в одному місці.
Артефакти впровадження: налаштування, схеми, регламенти
Перед запуском DAST у конвеєрі ми фіксуємо все, що потрібно для відтворюваної роботи: інакше сканер живе до першої зміни власника стенда або до першого хибного спрацювання, після якого перевірку вимикають.
На виході замовник отримує не звіт разового прогону, а робочий комплект — від конфігурацій до регламенту розбору знахідок.
- Конфігурації запуску сканера: окремі профілі для швидкої перевірки на кожній збірці та повного прогону перед релізом, прив'язка до стадії конвеєра, пороги, за яких збірка зупиняється.
- Схема розміщення: де розгортається сканер, як він ходить до цільового стенда, які сервісні облікові записи та мережеві правила потрібні.
- Політики доступу до стендів: облікові записи для сканування під авторизацією, обмеження частоти запитів і вікна запуску, щоб перевірка не заважала навантажувальним і ручним тестам.
- Правила відсікання хибних спрацювань: список винятків з обґрунтуванням і терміном перегляду, розмітка відомих знахідок — нові дефекти не тонуть у шумі.
- Карта покриття: які маршрути та ролі користувачів перевіряються, що свідомо залишено поза зоною сканування.
- Регламент обробки знахідок: рівні критичності, терміни реакції, хто підтверджує дефект і хто закриває, як знахідка перетворюється на задачу для розробки.
- Документація й передача: інструкція із запуску та налагодження, розбір типових помилок, навчання команди й передача володіння.
Регламент віддаємо разом із доступами й розбором на реальному прогоні — щоб профілі, винятки та пороги змінювалися без нас.
Кейс: як разовий аудит став щоденною перевіркою
Замовник — платіжний сервіс із десятка сервісів за спільним шлюзом.
Перевірки безпеки замовляли раз на квартал: аудит займав два-три тижні, звіт приходив окремим документом, а частина знахідок — відкритий налагоджувальний ендпоінт, забуті заголовки, застаріла залежність — спливала вже після релізу й вимагала позапланової викатки.
Що змінили
Сканер OWASP ZAP розгорнули в режимі автоматичного аналізу й увімкнули в конвеєр збірки: прогін стартує на кожному злитті в основну гілку.
Стенд піднімається з тими самими міграціями, що й у проді, обхід іде за картою маршрутів, результат порівнюється з базовою лінією — новий дефект видно на тлі вже відомих. Критичні знахідки зупиняють збірку, решта йде в трекер із прив'язкою до коміту й автора правки.
Метрики до і після
- Ручні перевірки: раз на квартал → автоматичний прогін на кожне злиття й у нічних збірках.
- Час від появи дефекту до виявлення: два-три тижні → години, у межах того самого дня.
- Частка знахідок, закритих до релізу: 55% → 96%; решта — усвідомлені винятки із записом у базову лінію.
- Хибні спрацювання: після налаштування правил шум знизився приблизно втричі, звіти перестали вичитувати повністю.
Ручний аудит не скасували: він залишився для сценаріїв доступу та логіки бізнес-операцій, які сканер не перевіряє. Щоденний прогін закриває регулярний фон, тому зовнішня перевірка більше не витрачає час на очевидне.
Чим DAST відрізняється від SAST і що запускати першим
Динамічний і статичний аналіз дивляться на різні стани системи, тому не замінюють одне одного, а закривають різні класи дефектів — ті, що перелічує OWASP.
Статичний аналіз розбирає вихідники й конфігурацію як текст: розгорнутий стенд йому не потрібен, перевірка вкладається у хвилини й може йти на кожній зміні.
Динамічний надсилає реальні запити до запущеного застосунку й знаходить те, чого в коді не видно: обхід авторизації підміною ідентифікатора, помилки в правах ролей, доступні службові адреси.
| Перевірка | Місце в конвеєрі | Що виявляє | Чого не бачить |
|---|---|---|---|
| Статичний аналіз | На кожній зміні, до злиття в основну гілку | Небезпечні конструкції в коді, витоки секретів, вразливі залежності | Логіку зв'язки сервісів, поведінку під чужою сесією та під навантаженням |
| Динамічний аналіз | На тестовому стенді: нічний прогін і крок перед випуском | Помилки доступу, конфігурацію середовища, реальні відгуки сервісів | Гілки коду, яких не торкнувся сценарій обходу |
Порядок підключення задає ціна зворотного зв'язку. Статичний аналіз відповідає за хвилини, тому першим ставлять його — обов'язковою перевіркою на зміну в гілці.
Динамічний потребує розгорнутого стенда з тестовими даними й прогоняється довше, тому його виносять із швидкого циклу в нічний запуск і в обов'язковий крок перед випуском.
Пріоритет впровадження при обмеженій увазі команди: спочатку статичний аналіз на зміні, потім динамічний перед кожним випуском, потім розширення сценаріїв на авторизовані ролі.
Поки перевірки не вбудовані в конвеєр, вони залишаються разовою акцією — а регулярний прогін перетворює їх на керований процес.
Технічні сумніви: шум, вхід у систему, тестові стенди
Більшість сумнівів навколо DAST зводиться до чотирьох питань: скільки хибних спрацювань доведеться розбирати вручну, як сканер проходить форму входу, що він бачить на тестовому стенді й наскільки розтягне збірку. Короткі відповіді — нижче.
Хибні спрацювання — скільки їх буде?
Шум дають сліпі ін'єкції, шаблони із вставками скриптів і самописні схеми авторизації. Ми вимикаємо правила, що стабільно помиляються на конкретному стеку, і підтверджуємо кожну знахідку повторним запитом з іншої точки. У звіт потрапляють уразливості з відтворюваним сценарієм, а не список здогадів.
Як сканер проходить авторизацію?
Облікові дані підставляються зі сховища секретів, ланцюжок редиректів повторюється, сесія утримується, а при закінченні токена вхід виконується заново без ручної участі.
Ролі беремо різні — гість, користувач, адміністратор: так ловиться й обхід контролю доступу, а не лише відкриті форми.
Що потрапить на тестовий стенд?
Стенд наповнюється обезособленою копією бази, доступ обмежений часом прогону й адресами складальних агентів, після сканування середовище перестворюється. Перевірки залишаються відтворюваними між запусками, а персональні дані в контур не потрапляють.
Наскільки це подовжує збірку?
Повний прогін помітно довший за модульні перевірки, тому режими розведені: швидкий профіль за критичними шляхами — на кожен коміт, розширений — за розкладом і перед релізом. Сканування йде паралельно іншим стадіям і не блокує збірку до підтвердженої знахідки.
Обговоримо задачу: зберемо схему перевірок під ваш конвеєр
Щоб розмова була предметною, принесіть опис того, як зараз влаштований ваш конвеєр. Готове технічне завдання не потрібне — достатньо вступних даних, за якими видно, де динамічний аналіз (DAST) вбудується без зупинки випусків.
- Як запускається збірка й які середовища піднімаються автоматично — від тестового стенда до передпромислового.
- Де логічно поставити перевірку: одразу після розгортання на стенд, за розкладом поза робочими годинами або вручну перед випуском.
- Які сервіси піднімаються в ізольованому середовищі й чи потрібні їм зовнішні залежності — бази, черги, сторонні сервіси.
- Чи є тестові облікові записи та дані, щоб перевірка проходила авторизацію, а не впиралася у форму входу.
- У якому вигляді команді зручно отримувати результат — задачею в трекері, файлом в артефактах збірки або зведенням на панелі.
- Хто розбирає знайдене й за яким порогом збірка вважається проваленою: одинична знахідка чи їхня частка від загальної кількості шляхів.
У відповідь ми приносимо план впровадження перевірок: схему розміщення етапів у конвеєрі, вимоги до стенда, пороги спрацювання й оцінку термінів робіт. Опишіть задачу зручним способом — дзвінок, листування, доступ до репозиторію — і повернемося з оцінкою та планом.
