Аудит DevSecOps-процессов: кто отвечает за контрольную точку, исключение и исправление

Представим гипотетическую продуктовую команду, которая выпускает B2B-платформу по нескольку раз в день. Конвейер выглядит зрелым: статический анализ на каждый merge request, сканирование зависимостей, проверка инфраструктурного кода, контроль образов контейнеров. Панель мониторинга зелёная. И вот крупный заказчик на этапе закупки задаёт простой вопрос: можете ли вы показать, что безопасность в процессе поставки действительно работает, а не просто что инструменты установлены?

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

Каждый инструмент в этой истории работает. Не работает процесс вокруг них. Именно этот разрыв и должен находить аудит DevSecOps-процессов.

Что на самом деле проверяет аудит DevSecOps-процессов

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

Владелец — настоящая единица аудита

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

Доказательства процесса и техническая оценка

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

NIST SP 800-204D посвящён интеграции безопасности цепочки поставок ПО в CI/CD-конвейеры DevSecOps, и это разумный ориентир, когда работа переходит к этим границам доверия. Он не заменяет процессный аудит, а процессный аудит не заменяет его. В хорошем плане прямо сказано, что из двух входит в границы работ, а если входит и то и другое, — какие выводы опираются на какую часть. Технической стороне подробнее посвящён наш материал об оценке безопасности DevSecOps.

Планирование: сначала границы, выборка и мерки

NIST SP 800-115 — техническое руководство по тестированию и оценке информационной безопасности — описывает оценку в три фазы: планирование, выполнение и этап после выполнения. Само руководство оговаривает, что это обзор техник с их преимуществами и ограничениями, а не полноценная программа тестирования. Эта статья тоже не является полной программой аудита DevSecOps. Три фазы дают структуру, которая не позволяет процессному аудиту выродиться в инвентаризацию инструментов.

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

Как выбрать выборку

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

Мерки фиксируются до начала проверки

Заранее решите, на какие документы будут ссылаться находки, и зафиксируйте их версии. OWASP ASVS — набор верифицируемых требований безопасности; для выбранной версии, например 5.0.0, проект рекомендует ссылаться на требования с префиксом версии: v5.0.0-1.2.5, поскольку идентификаторы меняются между версиями. OWASP Top 10 — документ для повышения осведомлённости, а не набор требований, а Web Security Testing Guide — методика тестирования. Это различие меняет формулировки: «команда обучена по Top 10, но в её задачах нет требований с привязкой к ASVS» — точный вывод, а «безопасность незрелая» — нет.

Если руководству нужно описать текущее и целевое состояние в терминах управления, один из вариантов — профиль NIST CSF 2.0 для функции разработки и поставки. Он оправдан только тогда, когда кто-то действительно будет расставлять приоритеты по целевому профилю.

Выполнение: прослеживать релизы, а не перечень инструментов

На этапе выполнения аудитор проводит каждый релиз из выборки через жизненный цикл и для каждого контроля фиксирует, какой техникой получено доказательство. SP 800-115 описывает группу техник анализа: изучение документации, анализ журналов, проверку наборов правил и проверку конфигурации систем; на них и держится процессный аудит. Если план это допускает, ограниченная санкционированная техническая проверка репрезентативного приложения показывает, обнаруживает ли контроль то, что должен. Зелёный статус сборки — артефакт конфигурации. Он не доказывает, что лежащий в основе тест покрывает значимый риск.

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

Требования и проектирование

Начинать стоит с самого начала. Руководство CISA Secure by Design исходит из того, что принципы безопасности нужно применять на этапе проектирования, чтобы сократить число эксплуатируемых дефектов ещё до того, как продукт попадёт к заказчикам. Вопрос аудита конкретен: откуда взялись требования безопасности для выбранного релиза? Уровень ASVS с зафиксированной версией, привязанный к задачам, можно проверить. Неформальная договорённость или вики-страница без ссылок дают слабое доказательство: их приходится подтверждать интервью, записями релизов и наблюдаемой практикой.

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

Для каждой контрольной точки зафиксируйте режим (блокирующий или рекомендательный), классы слабостей, которые она должна ловить, кто может менять режим или пороги и когда это делалось в последний раз. Блокирующие точки повышают уверенность, но усиливают давление на обход; рекомендательные сохраняют скорость, но рискуют превратиться в шум. Аудит не должен оценивать выбор в отрыве от контекста. Он спрашивает, соответствует ли режим риску класса слабостей и были ли изменения решением владельца, а не постепенным дрейфом.

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

Инфраструктурный код и живая среда

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

Зависимости и сборочная цепочка

Процессные вопросы здесь касаются владения и контроля изменений: кто решает, что уязвимая зависимость может уйти в релиз, кто вправе править описания конвейера и проходят ли эти правки то же ревью, что и код приложения. Более глубокие технические вопросы, такие как происхождение артефактов и изоляция сборочных агентов, относятся к оценке безопасности цепочки поставок ПО, и именно там SP 800-204D применим наиболее непосредственно.

Исключения: где документированный процесс расходится с фактическим

Исключения — самая информативная часть аудита DevSecOps. Документированный процесс описывает нормальный путь, а исключения показывают, что происходит под давлением сроков. Срочные исправления, ручные переопределения и отложенные находки — именно там обычно становится виден разрыв между политикой и практикой.

Что должно быть в записи об исключении

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

Срочные изменения и ручные переопределения

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

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

Обратная связь и устранение: учится ли процесс

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

Приоритет по классу слабостей, а не по числу находок

MITRE CWE Top 25 выделяет наиболее опасные и распространённые классы слабостей, стоящие за недавними записями CVE, и MITRE подчёркивает, что понимание первопричин даёт обратную связь в жизненный цикл разработки и архитектурное планирование и помогает устранять целые классы дефектов, например связанные с безопасностью памяти и инъекциями. Наряду с Top 25 MITRE публикует список, ранжирующий слабости, которые стоят за активно эксплуатируемыми уязвимостями, по каталогу Known Exploited Vulnerabilities агентства CISA. Для аудита это меняет вопрос с «сколько находок выдал сканер» на «какие классы слабостей наш процесс предотвращает по замыслу и жёстче ли сроки для классов, которые встречаются в данных об эксплуатации».

Оповещения CISA Secure by Design указывают в ту же сторону: они посвящены устранению межсайтового скриптинга, внедрения команд ОС и обхода каталогов. В ASVS есть требование о защите от внедрения команд ОС, и это показывает, как класс слабостей превращается из повода для беспокойства в то, что команда может проверить.

Закрытая задача — ещё не исправление

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

Находки должны возвращаться в требования

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

После выполнения: превратить наблюдения в решения с владельцем

В SP 800-115 этап после выполнения охватывает анализ, рекомендации по снижению рисков и отчётность. Для процессного аудита главный риск здесь — длинный список технических задач, который не читает никто из тех, у кого есть полномочия. Каждая находка должна пройти один и тот же короткий путь от наблюдения к решению.

1. НаблюдениеЧто увидели в выборке: какой релиз, какой контроль и в чём отклонение от документированного процесса.
2. Доказательство и техникаКакой артефакт подтверждает вывод и как он получен (изучение документов, анализ журналов, проверка конфигурации или санкционированный тест), а также чего эта техника показать не может.
3. ВладелецНазванный человек или роль, способные изменить процесс, а не только команда, которая устранит симптом.
4. РешениеИсправить, принять со сроком действия и компенсирующей мерой или перепроектировать контроль; в каждом случае фиксируется, кто решил.
5. Повторная проверкаКак и когда следующий цикл проверит изменение по тем же ссылкам с зафиксированной версией.

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

Находки, которые переживут обновление стандартов

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

Почему здесь нет оценки зрелости в баллах

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

Чего такой аудит не скажет

Старое руководство, новые конвейеры

SP 800-115 выпущен в 2008 году и предшествует современным CI/CD-практикам. Его логика планирования и анализа сохраняет силу, но техники, специфичные для конвейеров, приходится брать из других источников, и это одна из причин, почему для технической стороны важен SP 800-204D. ASVS и WSTG ориентированы на веб-приложения, поэтому для других типов систем нужны дополнительные требования.

Выборка — не вся совокупность

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

Намерение — не результат

Принятие рамки или подписание обязательства вроде CISA Secure by Design Pledge — это заявление о намерениях, а не доказательство результата. Аудит опирается на наблюдаемые свидетельства. По той же логике ни процессный аудит, ни тест на проникновение не являются сертификацией, аттестацией или гарантией безопасности; каждый из них — обоснованный взгляд на то, как вели себя контроли в том, что было проверено.

Как подготовиться к внешнему процессному аудиту

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

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