Ретест после пентеста: как доказать, что уязвимости действительно устранены

Условная ситуация. SaaS-сервис для бухгалтерии получает отчёт о пентесте с двенадцатью находками. Самая серьёзная — небезопасная прямая ссылка на объект: подставив чужой идентификатор в запрос к /api/invoices/{id}, авторизованный пользователь одной компании видит счета другой. Через две недели разработчики добавляют проверку владельца в обработчик этого эндпоинта, тестировщик повторяет исходный запрос, получает отказ, и тикет закрывается. На квартальном слайде для руководства появляется строчка «критические находки устранены: 1 из 1».

Через месяц выясняется, что те же счета отдаются через экспорт в PDF и мобильный API без проверки владельца. Исходный запрос действительно не срабатывает, но исправили одну точку входа, а не правило доступа.

Пример вымышленный, но механизм узнаваем. Дело не в качестве работы разработчиков: просто «исходный запрос больше не воспроизводится» и «уязвимость устранена» — разные утверждения. Проверка устранения уязвимостей после пентеста нужна, чтобы отличать одно от другого и оставлять после себя доказательства, а не впечатление.

Ниже — как выстроить ретест, результат которого можно защитить перед руководством, аудитором и собственными инженерами.

Что на самом деле проверяет ретест

Повторное тестирование после пентеста — это санкционированный повторный анализ уже найденных проблем в заранее согласованных рамках. Его задача узкая и практичная: установить, устраняют ли внесённые изменения саму слабость, а не только внешний симптом, который был виден в исходном отчёте. Результат ретеста питает одно из трёх управленческих решений: закрыть находку, осознанно принять остаточный риск или вернуть задачу в разработку.

Ретест — не новый пентест: он ограничен согласованными находками и не даёт картину защищённости в целом. Вариантные и регрессионные проверки могут попутно обнаружить новую проблему; её фиксируют отдельно, но это не превращает ретест в полную новую оценку. Это не сертификация, не аттестация и не заключение аудитора. И не гарантия, что риск исчез навсегда: следующий релиз может вернуть дефект или открыть новый путь к тем же данным.

Где проходят границы ретеста

Все действия ретеста требуют письменной авторизации, и здесь есть подвох. Разрешение на исходный проект нередко покрывает конкретное окно дат, конкретные хосты и сборки. К моменту повторной проверки всё это могло измениться: появился новый домен, сервис переехал в другой кластер, тестовую среду пересобрали. Правила проведения работ должны явно охватывать окно ретеста и актуальный список целей, иначе даже добросовестная проверка выйдет за пределы разрешённого.

Вторая граница — содержательная: согласованный перечень находок и разумная окрестность вокруг них, то есть варианты того же дефекта и затронутая исправлением функциональность. Если архитектура изменилась настолько, что прежние находки потеряли смысл, нужно не расширять ретест молча, а договориться о новой оценке изменений. Разработку эксплойтов и проверку систем без документированной авторизации всех сторон, уполномоченных разрешить работы в затрагиваемых активах и среде, эта статья не рассматривает.

Почему «исправлено» в тикете ещё не доказательство

NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, описывает назначение технического тестирования шире, чем поиск дефектов: помочь организациям планировать и проводить проверки, анализировать находки и вырабатывать стратегии их устранения. Формально документ делит оценку на три фазы — планирование, выполнение и пост-выполнение; в последнюю входят анализ результатов и рекомендации по устранению. Цикл «нашли — исправили — перепроверили — закрыли», о котором пойдёт речь дальше, — это авторская практическая схема поверх этой структуры, а не отдельная фаза стандарта. Но логика у них общая: тест, который заканчивается на обнаружении, оставляет вопрос об эффективности исправлений открытым.

SP 800-115 опубликован в сентябре 2008 года, заменил SP 800-42 и позиционирует себя как обзор ключевых элементов технического тестирования, их преимуществ и ограничений, а не как исчерпывающую программу. Его разумно использовать как опору для планирования и процесса, а технические проверки приложений строить по профильным руководствам с явно указанной версией.

NIST Cybersecurity Framework 2.0 добавляет управленческий угол: фреймворк призван помогать организациям понимать и улучшать управление киберрисками. В этих терминах подтверждённое исправление — надёжный вход в картину рисков. Тикет со статусом «готово», который никто не перепроверял, — допущение, и решения на его основе управляют не риском, а отчётностью.

Исходная находка как точка отсчёта

Ретест не может быть лучше исходной записи о находке. Чтобы отличить устранённую слабость от проверки, которая просто до неё не дотянулась, нужна база: затронутый актив и его версия, предусловия (какая роль, какой аккаунт, какое состояние данных), тест-кейс, который продемонстрировал проблему, наблюдавшиеся доказательства и требование, которое было нарушено.

Если в отчёте о внедрении команд ОС написано лишь «в функции проверки доступности хоста возможна инъекция», ретестер не знает, какой параметр, метод и права были задействованы. Достаточные для воспроизведения части запроса и ответа, роль учётной записи и описание того, как ввод попадал в командную строку, делают повторную проверку воспроизводимой. Секреты и посторонние персональные данные минимизируют или маскируют; если защищённый оригинал нужен, для него задают ограниченный доступ и срок хранения.

Предусловия особенно важны для авторизационных находок. Уязвимость, которая проявлялась только у пользователя с ролью «менеджер филиала» при наличии счетов в двух филиалах, не воспроизведётся на пустом тестовом аккаунте — и это ничего не скажет об исправлении. Если исходный отчёт их не содержит, первая задача ретеста — восстановить их вместе с командой.

Как проводить повторное тестирование: от воспроизведения к вариантам

Каждую находку удобно сопоставить с процедурой тестирования. OWASP Web Security Testing Guide — широко используемый публичный сборник процедур тестирования веб-приложений, и его категории хорошо подходят как воспроизводимая основа. В этой статье WSTG 4.2 используется как выбранный пример. В отчёте о ретесте нужно указывать версию, которой действительно следовали, а не просто писать «по WSTG».

1. База находкиАктив, версия, предусловия, исходный запрос и нарушенное требование. Без этой базы повторная проверка неотличима от промаха
2. ВоспроизведениеИсходный тест-кейс на исправленной сборке в тех же предусловиях; сохраняются достаточные воспроизводимые и минимизированные доказательства, а доступ и срок хранения защищённого оригинала ограничиваются
3. Варианты и регрессияДругие параметры, методы и представления тех же данных, плюс проверка смежной функциональности, которую затронуло исправление
4. Среда и сборкаСверка среды, идентификатора сборки и заголовков кэширования с продуктивом. Если среды различаются, статус остаётся условным
5. Статус закрытияЭкземпляр, шаблон, класс, смягчено или условно — с доказательствами и ссылками на версии стандартов

Воспроизведение исходного случая

Первый шаг — повторить исходный тест-кейс на исправленной сборке в тех же предусловиях и сохранить полный ответ, а не только итоговый экран. Если исходная атака больше не проходит, это необходимое, но не достаточное условие закрытия. Если проходит, находка остаётся открытой и дальше можно не идти.

Вариантные тесты и регрессия

Затем — вариации вокруг того же класса слабости. Для IDOR это другие объекты, другие методы (не только GET, но и PUT и DELETE), другие представления тех же данных: экспорт, поиск, мобильный API, вебхуки. Для инъекции — другие параметры той же функции, другие кодировки и разделители, другие функции, которые, судя по коду или поведению, используют тот же небезопасный вызов. Для XSS — другие контексты вывода: атрибут, строка JavaScript, URL.

Параллельно стоит проверить смежную функциональность, которую затронуло исправление. Переписанная проверка прав может открыть новую дыру в соседнем методе. Регрессия, найденная на ретесте, оформляется отдельной находкой, а не растворяется в комментариях к старой.

Что нельзя вывести из неудачного воспроизведения

Отказ сервера на исходный запрос допускает несколько объяснений. Дефект действительно исправлен. Или изменился путь: эндпоинт переименовали, а старый код живёт под новым адресом. Или вмешался WAF, который блокирует именно эту полезную нагрузку, но не её вариации. Или тестовые данные не воспроизводят предусловий. Или исправление есть только в сборке, на которой шла проверка, и ещё не выкачено в продуктив.

Пока ретестер не исключил альтернативы, «не воспроизводится» означает лишь «не воспроизводится в этих условиях». Ретест проверяет конкретное исправление при указанных условиях — он не доказывает отсутствие риска вообще и не обещает, что дефект не вернётся в следующем релизе.

Версии стандартов в отчёте о ретесте

OWASP Application Security Verification Standard задуман как основа для проверки технических мер защиты и перечень требований для безопасной разработки. Для ретеста важно, что ссылка на конкретное требование ASVS превращает расплывчатое «исправлено» в проверяемое утверждение «названное требование теперь выполняется».

У каждого требования ASVS есть составной идентификатор из номеров главы, раздела и требования. Поскольку нумерация меняется между версиями, проект рекомендует добавлять к идентификатору префикс с версией, например v5.0.0-1.2.5; в выпуске 5.0.0 этот идентификатор относится к защите от внедрения команд ОС. Передача аргументов без строки оболочки снижает риск метасимволов shell, но не исключает внедрение опасных аргументов: нужны фиксированная допустимая операция или безопасный API, валидация либо белый список недоверенных аргументов и запрет опасных опций. Идентификатор без версии по правилам проекта читается как ссылка на последнюю редакцию. Значит, через полгода он может указывать уже на другое требование.

Отчёт о ретесте, написанный спустя месяцы после исходного теста, без версий легко начинает ссылаться не на то, что проверяли. Списки требований ASVS 5.0.0 публикуются в машиночитаемых форматах, включая CSV и JSON, так что ссылки с версией удобно прикреплять прямо к тикетам.

Та же дисциплина нужна для OWASP Top 10. На момент подготовки этого текста существуют выпуски 2025, 2021 и 2017 годов. Top 10 — документ для повышения осведомлённости, он полезен как метка категории риска, но слишком груб для критерия «прошло или не прошло». Рабочее разделение ролей выглядит так: Top 10 — чтобы назвать категорию, ASVS — чтобы сформулировать проверяемое требование, WSTG — чтобы описать процедуру теста. Каждая ссылка — с версией.

Какие находки перепроверять глубже

Глубину ретеста стоит распределять осознанно, не смешивая сигналы, которые отвечают на разные вопросы. CVSS описывает техническую серьёзность уязвимости. EPSS, по описанию FIRST, оценивает вероятность эксплуатации в ближайшие 30 дней, но не измеряет ущерб для конкретной организации. Каталог CISA KEV фиксирует уже наблюдавшуюся эксплуатацию. Экспозиция актива — доступен ли он из интернета, какие данные обрабатывает, кто им пользуется — известна только вам. Ни одна из этих оценок не заменяет остальные, и универсального порога, правильного для всех, не существует.

У находок, выявленных пентестом в собственном коде, часто нет ни CVE, ни оценки EPSS. Здесь помогает классификация по CWE. Список 2025 CWE Top 25 Most Dangerous Software Weaknesses от MITRE ранжирует слабости по набору данных и методике, определённым для выпуска 2025 года. По оценке MITRE, их часто легко найти и эксплуатировать, а последствия доходят до захвата системы и кражи данных. Рядом MITRE публикует 2025 CWE Top 10 KEV Weaknesses — рейтинг слабостей, связанных с уязвимостями, эксплуатацию которых зафиксировал каталог CISA KEV. Анализ первопричин MITRE рассматривает как способ устранять целые классы дефектов, например связанные с безопасностью памяти и внедрением.

Для ретеста принадлежность CWE к этим спискам служит одним из сигналов глубины, но не заменяет EPSS и не определяет приоритет конкретной находки. Уровень проверки выбирают вместе с достижимостью, внешней доступностью, требуемыми привилегиями, влиянием на услугу и признаками эксплуатации; при высоком совокупном риске проверяют шаблон, а не только исходный случай. Как сочетать технические и бизнес-сигналы при расстановке приоритетов, подробно разобрано в материале о приоритизации уязвимостей на основе риска.

Экземпляр, шаблон или класс: три уровня закрытия

Инициатива CISA Secure by Design призывает производителей закладывать безопасность на этапе проектирования, чтобы существенно сократить число эксплуатируемых дефектов ещё до выхода продукта. Отдельные оповещения Secure by Design посвящены устранению межсайтового скриптинга, внедрения команд ОС и обхода каталогов. Ключевое слово здесь — «устранение»: это более высокая планка, чем исправление отдельного случая.

Для отчёта о ретесте из этого следует простая градация. «Исправлен экземпляр» — заявленный случай больше не воспроизводится. «Исправлен шаблон» — варианты в том же компоненте тоже не срабатывают. «Класс структурно исключён в указанном компоненте» — внедрена структурная мера и проанализированы все релевантные пути и возможные обходы в согласованном охвате. Для команд это означает по возможности отказаться от оболочки, зафиксировать допустимую операцию или использовать безопасный API, валидировать либо разрешать только ожидаемые аргументы и запрещать опасные опции. Для доступа к объектам нужно доказать, что каждый релевантный путь проходит через единый контроль авторизации и что обходные пути проверены. Отчёт должен явно называть достигнутый уровень: для руководства слово «исправлено» звучит одинаково во всех трёх случаях, а риск за ним разный.

Вернёмся к примеру со счетами. Проверка владельца в одном обработчике — исправленный экземпляр. Та же проверка во всех обработчиках модуля счетов — исправленный шаблон. Общий слой авторизации, через который доказуемо проходят все релевантные пути к счетам в проверенном компоненте, включая API, экспорт и мобильный клиент, а анализ обходов не нашёл другого пути в согласованном охвате, — класс, структурно исключённый в этом компоненте. Все три состояния прошли бы повтор исходного запроса.

Меры эшелонированной защиты усложняют картину. MDN описывает Content Security Policy как заголовок ответа, с помощью которого администратор задаёт, какие ресурсы может загружать клиент; это помогает обнаруживать и смягчать некоторые атаки, включая XSS и внедрение данных. Новый заголовок CSP может заметно снизить эксплуатируемость XSS, но это слой смягчения. Ретестер должен отдельно установить, исправлена ли сама обработка вывода. Если нет, честный статус — «смягчено», а исходный дефект остаётся в плане работ: стоит ослабить политику ради нового стороннего скрипта, и уязвимость снова станет эксплуатируемой.

Среда, кэш и сессии: почему результат на стенде не переносится на продуктив

Протокол HTTP сам по себе не хранит состояние между запросами, но приложения строят поверх него сессии с помощью cookies, токенов и серверного хранилища сессий. Для ретеста это значит, что результат зависит от конкретного состояния: какая сессия, какие права у пользователя в этот момент, не отдан ли ответ из кэша. Кэши, CDN и перенаправления меняют то, что фактически получает клиент, поэтому исправление, подтверждённое на тестовой сборке или за кэшем, может не совпадать с поведением в продуктиве.

Отсюда практическое правило: результат на стенде — это результат на стенде. Если ретест проводился не на продуктиве и не на сборке, эквивалентность которой продуктиву подтверждена, статус находки должен оставаться условным до проверки в эквивалентной среде. В записи о ретесте нужно указывать среду, идентификатор сборки или коммита и значимые заголовки ответа, включая заголовки кэширования.

Отдельная ловушка — несколько узлов за балансировщиком: если исправление выкачено не везде, запросы попадают то на новый, то на старый код. Один успешный отказ этого не исключает; помогают серия запросов и сверка версий развёртывания с эксплуатацией.

Ручной ретест или повторное сканирование

Узкий ретест, который только воспроизводит исходный случай, проходит быстрее, но рискует ложным закрытием. Широкий даёт больше уверенности, но занимает больше времени и может незаметно превратиться в новую оценку за пределами согласованных рамок. Разумный компромисс — масштабировать глубину по риску: выбирать исходный случай и варианты по совокупному риску, а для высокого риска проверять шаблон; само присутствие CWE в списке не задаёт глубину.

Второй компромисс — автоматика против ручной работы. Повторное сканирование даёт повторяемость и хорошо подходит для конфигураций, заголовков, версий ПО и параметров TLS. Без заданных ролей, объектов и правил процесса сканер может пропустить межфилиальный доступ к счетам или обход шага оплаты. Такие проверки требуют знания ожидаемого поведения; их может выполнить специалист или автоматизированный тест с явно заданными правилами — подробнее об этом в статье о тестировании бизнес-логики. NIST SP 800-115 подчёркивает, что у каждой техники свои преимущества и ограничения, и это поддерживает выбор метода под конкретную находку, а не один инструмент для всех.

Третий компромисс — разовость. Если ретест становится постоянной потребностью, потому что каждый релиз меняет затронутые компоненты, возможно, правильнее планировать не отдельные повторные проверки, а пентест по изменениям, рамки которого привязаны к дельте между версиями.

Какие доказательства принимать при закрытии

Решение о закрытии должно быть проверяемым и через полгода, когда авторов исправления уже может не быть в команде. Поэтому для каждой находки стоит хранить исходный идентификатор, среду и сборку, дату ретеста, достигнутый уровень закрытия и ссылки на доказательства. CWE, версионированное требование ASVS и процедуру WSTG добавляют там, где они применимы; иначе фиксируют подходящий критерий и причину неприменимости этих таксономий. Как выстроить такой учёт на уровне всего процесса, разобрано в материале о контроле устранения уязвимостей.

Доказательствами должны служить обезличенные записи запросов и ответов, а не только скриншоты финального состояния. MDN делит коды ответа HTTP на пять классов: информационные, успешные, перенаправления, ошибки клиента и ошибки сервера. Сам по себе код ничего не доказывает: ответ 403 вместо 200 выглядит как исправление, но если в теле ответа всё равно приходят чужие данные или ответ 500 вызван тем, что полезная нагрузка сломала обработчик, вывод обратный. Код нужно интерпретировать вместе с телом ответа и поведением приложения.

Часть исправлений, особенно на уровне заголовков, можно перепроверять простыми инструментами из тех, что MDN перечисляет для анализа и отладки HTTP, — например, HTTP Observatory и curl, разумеется, в пределах авторизованных рамок. Чувствительные данные в сохранённых ответах нужно маскировать до того, как доказательства попадут в тикет-систему с широким доступом.

Если вы готовите ретест и хотите заранее договориться о его рамках — какие находки перепроверяются, в какой среде, с какой глубиной и какими доказательствами, — это удобно обсудить с командой Pentest.red через страницу согласования рамок пентеста.

Решения по итогам ретеста: устранено, смягчено, условно, открыто заново

Правила ниже — практическая схема, выведенная из описанных подходов, а не норма какого-либо стандарта. Пороги стоит адаптировать к собственному аппетиту к риску, а каждое отклонение фиксировать письменно.

Находка получает статус «устранено», когда исходный случай и варианты не воспроизводятся в среде, эквивалентной продуктиву, и отчёт называет достигнутый уровень — шаблон или класс. При высоком совокупном риске разумно требовать не меньше чем исправленный шаблон в согласованном компоненте и отдельно оценивать структурное исключение класса в нём. CWE-списки — дополнительный сигнал; глубину по остальным факторам задаёт первая таблица.

«Смягчено» — когда эксплуатацию затрудняет компенсирующая мера (заголовок, правило WAF, сетевое ограничение), а исходный дефект остаётся. Статус полезен, только если к нему приложено плановое исправление первопричины с ответственным, иначе он быстро становится постоянным.

«Условно» — когда проверка проведена в среде, отличающейся от продуктива, или когда исправление развёрнуто не везде. Статус меняется после проверки на эквивалентной сборке.

Если исходный случай или его вариант воспроизводится, находка открывается заново. Если исправление сломало что-то ещё, регрессия оформляется отдельной находкой. Ни одну из них не стоит закрывать молча, даже под давлением сроков релиза.

Повторяющиеся классы — повод для разговора уже не с одним разработчиком, а с архитектурой. MITRE прямо описывает анализ первопричин по CWE как обратную связь для жизненного цикла разработки и архитектурного планирования. Если три ретеста подряд находят непараметризованные вызовы в разных модулях, нужна общая библиотека и правило код-ревью, а не четвёртый точечный фикс.

Наконец, результаты стоит поднимать на уровень руководства в терминах управления рисками, близких CSF 2.0: сколько находок подтверждённо устранено, сколько только смягчено, сколько остаются открытыми или условными. Такая сводка честнее одного процента «закрытых тикетов».

Как выбрать подрядчика для проверки исправлений

Оценивать предложения стоит после того, как вы определились, как выглядит качественный ретест. Руководство CISA Secure by Demand создано, чтобы помочь заказчикам ПО добиваться безопасности в переговорах с поставщиками. Ту же позицию полезно занять при закупке тестирования: требовать конкретные артефакты, а не общие заверения. Сравнить подрядчиков по более широкому набору критериев поможет разбор сравнения поставщиков пентеста.

Первый вопрос — включён ли ретест в исходный проект, на какое окно времени и на какие находки он распространяется. Это лучше выяснить до подписания договора, а не после отчёта. Второй — какие версии WSTG и ASVS будет цитировать отчёт для применимых веб-находок и будут ли технические слабости сопоставляться с CWE там, где это уместно; для остальных находок нужен иной явный критерий или объяснение неприменимости.

Третий вопрос — различает ли отчёт исправленный экземпляр, исправленный шаблон и устранённый класс и как отмечаются смягчённые и условные находки. Четвёртый — как обновляется письменная авторизация, если до ретеста поменялись хосты, сборки или рамки. Пятый — какие доказательства сохраняются, где они хранятся и как обезличиваются чувствительные данные.

Тревожные признаки обычно видны уже в образце отчёта: закрытие без доказательств, ссылки на требования без версии, закрытие авторизационных и логических находок только по выводу сканера. В источниках, на которые опирается статья, нет данных о ценах или рыночных сроках ретеста, поэтому сравнивайте предложения по рамкам, глубине и качеству доказательств, а не по итоговой сумме.

Отчёт о ретесте — техническое свидетельство, а не аттестация соответствия: для SOC 2, ISO 27001 или регуляторной оценки заключение выдают квалифицированные аудиторы в отдельной процедуре, и ретест лишь служит им входными данными. Если вам нужен подрядчик для самого пентеста и последующей верификации исправлений с перечисленными артефактами, общий формат работ описан на странице услуги тестирования на проникновение, а рамки конкретного проекта обсуждаются отдельно.

Заключение: ретест, который можно защитить

Проверка устранения — момент, когда пентест превращается в измеримое снижение риска или, наоборот, показывает, что снижения не произошло. Практика, которая из этого следует, не требует экзотики: опираться на подробную исходную находку, воспроизводить исходный случай и проверять варианты, фиксировать среду и сборку, ссылаться на версии WSTG и ASVS, распределять глубину по классу слабости и экспозиции актива, отличать исправленный экземпляр от устранённого класса, а смягчение — от устранения.

Ретест не доказывает, что риска больше нет, — он доказывает, что конкретное исправление работает в конкретных условиях. Этого достаточно, чтобы решения опирались на факты. Подрядчик, который выдаёт применимые ссылки с версиями и сопоставления с CWE, градуированные статусы, документированную авторизацию и обезличенные доказательства, даёт вам именно такой результат.