Звіт про пентест нерідко викликає розгубленість: PDF-файл на понад 40 сторінок, десятки виявлених вразливостей і кілька критичних позначок можуть легко створити відчуття невизначеності щодо того, з чого почати. Через високе поточне навантаження команди документ іноді відкладається, а повертаються до нього вже перед наступним аудитом.
Важливо пам'ятати, що сам по собі пентест – це тільки перший крок для забезпечення кіберзахисту. Звіт не ставить крапку в захисті системи, а відкриває наступний, не менш важливий етап — пріоритизації та усунення вразливостей (remediation), а також перевірки результатів.
1. Пріоритизація. Чому не можна лагодити по порядку зі списку?
Найпоширеніша помилка — виправляти вразливості лише за їхнім балом небезпеки (CVSS). CVSS показує, наскільки вразливість серйозна з технічного боку, але не відображає реального ризику для конкретної організації. Він не враховує, наскільки важливий для бізнесу вразливий актив, які захисні механізми вже працюють навколо нього, чи має зловмисник реальний доступ до вразливого компонента і до яких наслідків призведе його злам.
Наприклад, SQL injection із високою CVSS-оцінкою на публічному API, доступному з інтернету без додаткових обмежень, очевидно потребує швидкої реакції. Та сама технічна вразливість у внутрішній адміністративній панелі, доступній лише з корпоративної мережі через VPN та додаткову автентифікацію, може мати інший фактичний ризик і, відповідно, інший пріоритет усунення.
Тобто CVSS не варто замінювати бізнес-контекстом — його треба цим контекстом доповнювати. Практичний спосіб розібратися з пріоритизацією — оцінювати вразливість за двома вимірами: наскільки вона технічно серйозна і наскільки легко до неї дістатися зловмиснику. Для першого виміру якраз і підходить бал CVSS разом з оцінкою того, як сильно постраждають дані та робота системи в разі атаки (їхня конфіденційність, цілісність і доступність). Для другого — треба зрозуміти, наскільки просто зловмисник може дотягнутися до вразливого місця: напряму через інтернет, тільки після входу в систему, лише з внутрішньої мережі чи взагалі маючи спеціальні права доступу.
Це не універсальний стандарт оцінки ризику, але проста робоча модель, яка допомагає швидко відокремити проблеми, що потребують реакції в першу чергу, від тих, які можна включити до планового backlog.
Водночас не кожну вразливість обов'язково потрібно виправляти негайно. Компанія може свідомо прийняти цей ризик. Наприклад, якщо вразливий компонент планують вивести з експлуатації найближчим часом або якщо компенсаційні контролі суттєво знижують ймовірність успішної експлуатації.
Але прийняти ризик — це не означає просто відкласти задачу в беклог. Таке рішення варто зафіксувати письмово: який саме ризик приймається, чому, хто його прийняв, які захисні заходи його врівноважують і до якої дати це рішення діє. Під час аудиту чи перевірки на відповідність вимогам позиція «ми знали про ризик і свідомо його прийняли» кардинально відрізняється від «ми побачили його у звіті, але нічого не зробили».
2. Remediation. Хто виправляє вразливості, у якому темпі і де ламається процес?
Коли пріоритети розставлені, звіт потрібно перетворити на робочий процес, а не залишати окремим PDF-файлом поруч із таск-трекером.
Практика, яка працює: кожна вразливість зі звіту стає окремою задачею в тому самому трекері, де команда вже керує розробкою та операційними задачами, — наприклад, у Jira чи іншій системі, яку використовує компанія. У тікеті мають бути щонайменше опис проблеми, якого актива вона стосується, рівень ризику, рекомендація щодо виправлення, відповідальний та очікуваний термін усунення.
Для критичних і високих (Critical, High) вразливостей зазвичай встановлюють стислі строки на усунення (SLA), а середні й низькі (Medium, Low) можна планувати в межах звичайного циклу розробки. Конкретні строки залежать від того, скільки ризику організація готова прийняти, від типу активу, вимог регуляторів та внутрішніх процесів. Важлива не кількість днів, а те, щоб для кожного рівня ризику був зрозумілий дедлайн і відповідальна за нього людина.
За кожною вразливістю має стояти конкретний відповідальний за задачу (owner), а не абстрактна «команда розробки». Саме він має підтвердити, що вразливість виправлено і її можна відправляти на перевірку.
На цьому етапі виникають дві типові помилки.
Перша — виправили симптом, а не причину. Класичний приклад: пентестер знаходить XSS (вразливість, коли на сторінку можна впровадити шкідливий скрипт) на одній сторінці, розробник додає потрібний захист саме для цього поля, а той самий небезпечний спосіб роботи з даними від користувача залишається ще в десятках інших місць коду. Формально конкретну задачу можна вважати закритою. Але архітектурно проблема нікуди не зникла.
Друга — виправили не всю вразливу систему, а лише її частину. Наприклад, вразливість знайшли на одному з п'яти однакових серверів, між якими розподіляється навантаження. Оновлення встановили на перевірений сервер, а решта чотири залишилися зі старою версією. Якщо потім перевірити тільки той сервер, який уже виправили, усе виглядатиме добре, хоча насправді на інших чотирьох вразливість нікуди не зникла і зловмисник досі може нею скористатися.
Обидві проблеми стають помітними саме під час повторної перевірки — ретесту. Це, звісно, добре, що вони виявляються. Але краще виправляти все одразу, бо під час ретесту можуть виявитися й інші проблеми, і буде прикро витрачати повторну перевірку на те, що мало бути закрито ще з першого разу.
3. Ретест. Чому усунення вразливостей недостатньо?
Статус done у таск-трекері означає, що команда вважає роботу виконаною. Проте він не доводить, що початкова вразливість більше не експлуатується.
Саме тому після усунення вразливостей потрібен ретест – повторна перевірка, яка підтверджує результат виправлення.
Під час ретесту пентестер повторює сценарій експлуатації, зафіксований під час первинного тестування, і перевіряє, чи зберігається початковий вектор атаки. Якщо експлуатація більше не працює, а remediation відповідає очікуваному результату, вразливість можна переводити у статус вирішених відповідно до процесу компанії.
Важливо, щоб ретест перевіряв не лише факт зміни конфігурації або появи нового коду, а саме результат з погляду атакуючого. Розробник може показати коміт, зміну конфігурації або встановлену версію бібліотеки. Для фахівця з кібербезпеки цього недостатньо: важливо підтвердити, що початковий ланцюжок атаки більше не працює.
І тут є нюанс, який часто випускають із уваги: обсяг ретесту не обов'язково має обмежуватися одним закритим пунктом зі звіту. Якщо виправлення зачіпає спільний компонент, механізм авторизації, обробку вводу або іншу частину поверхні атаки, варто перевірити пов'язану функціональність і потенційні побічні наслідки змін. Наприклад, новий механізм валідації може вплинути на інші точки обробки вводу, зміни в авторизації — на суміжні кінцеві точки API, а оновлення компонента — на його конфігурацію або залежності.
Тому точковий ретест відповідає на питання: «Чи закрили ми конкретну вразливість?». Розширена повторна перевірка відповідає на ширше питання: «Чи залишилися в перевіреному середовищі інші шляхи експлуатації після внесених змін?», а також: «Чи не виникло нових вразливостей у результаті виправлення знайденої?».
Саме тому формат ретесту варто визначати з урахуванням характеру виправлення вразливостей, масштабу змін, критичності системи та погодженого скоупу. Для значних змін повна повторна перевірка погодженого скоупу дає більше впевненості, ніж перевірка лише одного виправленого пункту.
Наступний крок – не чекати на наступний річний цикл
Якщо після remediation все одно потрібно повертатися до системи й перевіряти, що зміни справді усунули ризик, логічне питання: чому робити це лише раз на рік?
Річний пентест показує стан системи на конкретний момент часу. Але між двома тестами продукт змінюється: виходять нові релізи, з'являються нові кінцеві точки API, оновлюються залежності, змінюється інфраструктура та конфігурація.
Continuous-модель тестування вирішує саме цю проблему: тестування безпеки стає регулярним процесом, синхронізованим із темпом змін у продукті. Замість підходу «протестували → отримали звіт → виправили → забули до наступного року» формується цикл testing → remediation → retest → наступна перевірка.
AI Pentest від A42 дозволяє зробити цей цикл практичнішим уже на етапі повторного тестування. Замість повторної перевірки лише окремих закритих пунктів A42 проводить повний retest усього скоупу за 50% вартості первинного пентесту. Завдяки спеціалізованим AI-агентам такий повторний тест займає прогнозований короткий термін.
Це дозволяє не відкладати повторну перевірку через її вартість або тривалість і зробити ретест регулярною частиною процесу виправлення вразливостей, а не формальністю перед наступним щорічним пентестом.
Якщо після отримання звіту незрозуміло, з чого почати пріоритизацію, як організувати виправлення вразливостей або коли і в якому форматі проводити ретест, можна забронювати безкоштовний дзвінок із технічною командою A42.
