Пентест по изменениям: как определить объём дельта-проверки

В пятницу вечером в релиз-ноуте SaaS-сервиса для бухгалтерии появляются две скромные строки: «вход через корпоративный SSO» и «ускорили загрузку личного кабинета». За первой стоит новый провайдер удостоверений, код, который разбирает его ответы, и логика связывания внешних учётных записей с локальными. За второй — слой кэширования на CDN перед страницами, которые раньше всегда отдавались напрямую с сервера приложения. Автотесты зелёные, пользователи довольны, регрессий нет. Годовой пентест прошёл два месяца назад, следующий запланирован через десять.

Это условный пример, но вопрос в нём вполне практический. Что будет, если кэш по ошибке начнёт отдавать одному клиенту страницу, собранную для другого? Можно ли привязать чужой корпоративный аккаунт к своей учётной записи, подменив параметр в ответе провайдера? Не изменилось ли поведение сброса пароля для тех, кто теперь входит через SSO? Ни одна из этих проблем не обязана ломать заявленную функцию. Функциональные тесты могут их поймать, если в них есть явные проверки изоляции арендаторов, связывания учётных записей и восстановления доступа; обычный happy path способен их пропустить. А отчёт двухмесячной давности описывает систему, которой уже нет.

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

Почему календарного пентеста бывает недостаточно

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

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

Дальше речь пойдёт о веб-приложениях, API и инфраструктуре, которая непосредственно их обслуживает. Любое описанное тестирование предполагает письменное разрешение тех, кто вправе дать его для конкретных систем, согласованный объём и оформленные правила проведения. Статья не даёт и не подразумевает разрешения тестировать что-либо.

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

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

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

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

Аутентификация, сессии и авторизация

Сам HTTP не хранит состояние между запросами, но это не значит, что сессий в нём нет. Состояние добавляют cookie, токены и серверное хранилище сессий, и обычное веб-приложение вполне может держать сессии на сервере. Поэтому любое изменение того, как это состояние создаётся, передаётся, продлевается и отзывается, — кандидат в триггеры. Сюда относятся новый провайдер удостоверений, переход на SSO, изменение потока MFA, смена формата токенов, новые атрибуты cookie, другое время жизни сессии и изменённая логика выхода.

Отдельно стоит смотреть на авторизацию: новая роль, новый тип объекта с собственными правами доступа, переписанная проверка владельца ресурса. Такие дефекты сканер замечает плохо, потому что запрос формально корректен, просто выполнен не тем пользователем. Как проверять подобные сценарии системно, мы разбирали в материале о тестировании бизнес-логики.

Не стоит смешивать человеческую аутентификацию и учётные данные сервисов. Изменение MFA для сотрудников и замена ключа, с которым один микросервис обращается к другому, — разные изменения с разными рисками и разными тестами, даже если в заявке оба названы «доработкой аутентификации».

Заголовки безопасности и браузерные политики

Content Security Policy, CORS, Cross-Origin Resource Policy и Permissions Policy — механизмы, которыми приложение сообщает браузеру, чему доверять. Меняют их чаще всего ради интеграции: добавили платёжный виджет, подключили аналитику, открыли API для нового фронтенда на другом домене. Разрешить «временно» любой источник или отражать в ответе любой присланный Origin проще, чем разбираться, почему не проходит запрос, — и такие решения имеют свойство оставаться надолго.

Инфраструктура на пути запроса

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

Код, который собирает команды, пути и разметку

Код, который из пользовательского ввода собирает команды ОС, запросы к базе данных, пути к файлам или HTML, — естественный кандидат на ручную проверку. Эти классы слабостей выделены в рейтинге CWE Top 25, а CISA в серии материалов Secure by Design отдельно призывала производителей устранять межсайтовый скриптинг, внедрение команд ОС и обход каталогов как целые классы дефектов. Новая функция загрузки и выгрузки файлов, генерация отчётов по шаблонам, импорт данных из внешнего формата — всё это места, где такие дефекты появляются.

Зависимости, платформы, интеграции и тенанты

Крупное обновление фреймворка или платформы, переезд в другую среду размещения, объединение тенантов, хранилищ или доменов доверия, новая интеграция со сторонним сервисом — после таких изменений сдвигается не одна функция, а сразу несколько допущений, на которых держалась безопасность. Новые внешние эндпоинты и API, особенно административные, стоит рассматривать как отдельную поверхность атаки; о том, как проверять их методично, — в статье об оценке безопасности REST API.

Что можно не отдавать на ручной тест

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

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

Решения удобно свести в уровни. Ниже — рекомендуемая модель, которую стоит откалибровать на собственных данных.

Чувствительные данные, доступность из интернета и применимый класс слабостей, выделенный в CWE Top 25 или анализе MITRE на основе KEV, — полезные сигналы при решении о повышении уровня изменения. Место класса в рейтинге CWE — лишь один из входных факторов: глубина теста также зависит от достижимого пути атаки, возможного ущерба, действующих мер защиты и качества имеющихся доказательств. Понижать тип триггера стоит только тогда, когда достаточно широкие и репрезентативные прошлые проверки не выявляли релевантных проблем, качество и охват этих проверок понятны, а компенсирующие автоматические контроли доказуемо работают. Как превращать такие сигналы в очерёдность работ, мы описывали в материале о приоритизации уязвимостей по риску.

Как определить объём дельта-пентеста

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

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

Для кэша из того же примера объём будет другим: какие ответы кэшируются, из чего строится ключ кэша, как учитываются cookie и заголовок Authorization, что происходит с ответами на ошибки и перенаправлениями, можно ли заставить кэш сохранить ответ, предназначенный другому пользователю. Это не большой пентест всего приложения, но и не одна проверка заголовка Cache-Control.

Содержание тест-кейсов удобно брать из OWASP Web Security Testing Guide: дельта-тест выбирает только те категории, которые соответствуют изменению. При изменении работы с cookie — тесты управления сессиями, при изменении CSP — клиентские тесты, при новом провайдере удостоверений — тесты аутентификации и авторизации. Прогонять всё руководство ради одного изменения нет смысла.

Требования удобно размечать по OWASP ASVS. У них есть версионированные идентификаторы вида v5.0.0-1.2.5, и OWASP прямо предупреждает, что идентификаторы могут меняться между версиями, поэтому в отчёте нужно указывать, по какой версии велась разметка. Списки требований публикуются в машиночитаемых форматах CSV и JSON, так что связку «изменение — требование — проверка» можно частично автоматизировать. Помните, что такая разметка показывает, какие требования проверялись, но сама по себе не доказывает соответствие стандарту.

Если в организации практикуется оценка в модели assume breach, у дельта-теста может быть согласованная стартовая точка — например, учётная запись обычного пользователя в одном из тенантов. Но в отчёте нужно явно зафиксировать: тест начинался с заранее согласованного скомпрометированного состояния и не доказывает, что такой первоначальный доступ можно было получить на практике.

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

Стандарты как общий язык, а не как ритуал

NIST SP 800-115 — технический руководящий документ по тестированию безопасности, опубликованный в 2008 году. Он охватывает планирование тестов, их проведение, анализ находок и выработку мер по снижению риска, а формально делит оценку на фазы планирования, выполнения и пост-выполнения. Документ появился задолго до современных конвейеров CI/CD, но его логика хорошо ложится на модель по изменениям: планирование превращается в определение дельты, выполнение сосредоточено на изменённых компонентах, пост-выполнение включает анализ и рекомендации. Отдельно от этих фаз многие команды ведут собственный рабочий цикл «нашли — исправили — перепроверили — закрыли»; это практика, а не формулировка самого NIST. Документ также подчёркивает, что у каждой техники есть преимущества и ограничения, — полезное напоминание выбирать техники под конкретную среду и избегать действий, способных нарушить доступность.

OWASP Top 10 и CWE Top 25 могут служить одним из входов при приоритизации: они выделяют классы слабостей, которые стоит рассмотреть, когда изменение их затрагивает. Само место в рейтинге не определяет требуемую глубину теста. Отнесение находки к классу CWE описывает природу дефекта, но не означает, что конкретная уязвимость кем-то эксплуатировалась, — для этого нужны отдельные данные.

Скрытое требование всей схемы — дисциплина версий. Ориентиры обновляются: у OWASP Top 10 есть редакции 2017, 2021 и 2025 годов, у ASVS меняются идентификаторы, у WSTG выходят новые версии. Если вы хотите сравнивать дельта-тест этого квартала с прошлогодним, в каждом отчёте должно быть указано, какие версии ориентиров использовались, — например, WSTG 4.2, ASVS 5.0.0 и OWASP Top 10 2025 на момент конкретной проверки. При выходе новой редакции любого из них стоит пересмотреть и модель уровней, и привязку тестов к требованиям.

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

Главное преимущество подхода по изменениям — релевантность. Специалисты тратят время на то, что действительно изменилось, а находки появляются, пока у инженеров, которые вносили изменение, ещё свеж контекст. Второе преимущество — доказательность: значимый релиз сопровождается собственной записью о проверке.

Главные риски — слепые зоны и перегрузка. Чисто дельта-подход может пропустить уязвимости в компонентах, которые никто не трогал, взаимодействие нескольких изменений, каждое из которых по отдельности выглядело безобидно, и дрейф конфигурации, вообще не проходивший через формальный процесс изменений: кто-то поправил правило на балансировщике вручную. Быстрая команда к тому же может порождать больше триггеров, чем способен покрыть бюджет.

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

Стоит честно признать и ограничение: изученный для этой статьи набор источников не содержит количественного сравнения эффективности или стоимости тестов по изменениям и плановых тестов. Это обоснованная гипотеза, которую стоит проверить на собственной программе, например отслеживая, сколько находок даёт каждый дельта-тест по изменённым компонентам.

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

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

1. Отметка в заявкеАвтор изменения отвечает, затрагивает ли оно права, сессии, ввод, заголовки, внешние интерфейсы или путь запроса.
2. Триаж и уровеньОтветственный за безопасность смотрит дифф, присваивает уровень от 0 до 3 и фиксирует решение вместе с причиной.
3. Объём и правилаДля уровней 2 и 3 согласуются дельта, соседние механизмы, среда, сроки, контакты и условия остановки.
4. Тест и анализСпециалисты проверяют изменённые компоненты и их связи, находки размечаются по затронутым требованиям.
5. Перепроверка и связьИсправление перепроверяется в согласованной среде, находка связывается с изменением, которое её внесло.

Триаж — это решение, которое должно оставлять след. Если изменение отнесли к уровню 0, в заявке должна остаться отметка, кто и почему так решил.

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

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

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

Перепроверка и доказательства закрытия

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

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

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

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

Закупка работает лучше, когда внутренняя модель триггеров и уровней уже сложилась. Без неё в первой работе придётся также определить, как изменения попадают в объём, а результаты будет труднее сопоставлять между релизами. Подрядчики называют такие услуги по-разному: непрерывный пентест, pentest-as-a-service, повторное тестирование по запросу. Название важно меньше, чем способность проверять заданную дельту единообразно, по прослеживаемой методике и в сроки, которые стороны действительно согласовали.

Руководство CISA Secure by Demand написано для заказчиков ПО, ведущих закупочные переговоры, и его основная позиция применима и к закупке тестирования: требуйте доказательств, а не обещаний. На практике это несколько вопросов. К каким версиям WSTG и ASVS привязаны тесты и ссылаются ли отчёты на версионированные идентификаторы? Как подрядчик определяет дельту и как учитывает взаимодействия с неизменёнными компонентами? Какой срок от триггера до теста можно согласовать и как проводятся срочные предрелизные проверки? Входит ли перепроверка исправлений и чем подтверждается закрытие находок? Как для каждого проекта оформляются правила проведения, утверждение объёма и условия остановки? Как используются CWE Top 25, список слабостей на основе KEV или OWASP Top 10, чтобы сфокусировать усилия? Можно ли выгрузить результаты в структурированном виде и связать их с записями об изменениях? Что автоматизировано, что делают специалисты и какие ограничения подрядчик называет сам?

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

Если вы выстраиваете гибридную модель, с Pentest.red можно обсудить, как может выглядеть базовая оценка и какие изменения разумно вынести в дельта-проверки: какие доказательства нужны вашим внутренним процессам, какие среды доступны для тестирования и кто в вашей организации подписывает разрешение. Подготовиться к такому разговору помогут описание услуги тестирования на проникновение и форма описания объёма.

Заключение

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

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