Оценка безопасности DevSecOps: проверка доверительных связей конвейера, доказательства и повторное тестирование

Представим гипотетическую ситуацию в команде разработки. Разработчик отправляет небольшое и вполне легитимное изменение. Коммит подписан, второй инженер проверяет и одобряет pull request, все обязательные проверки проходят. С кодом всё в порядке. Однако CI-сценарий подключает стороннее действие по изменяемому тегу, а не по закреплённой ссылке. Задача попадает на постоянный self-hosted раннер, общий для нескольких репозиториев, и в каталоге кэша там остался изменённый инструмент сборки от предыдущей задачи. Раннер выдаёт задаче долгоживущие облачные учётные данные с правами гораздо шире, чем нужно для сборки. Получившийся образ публикуется под переиспользуемым тегом, продвигается из staging в production по этому же тегу и разворачивается идентичностью, у которой есть права записи во все окружения. Экран согласования для production показывает утверждающему сводку по конвейеру, а не дайджест артефакта. Каждый отдельный контроль был «зелёным», но доказать, что в эксплуатации работает именно проверенный код, никто не может.

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

Что охватывает оценка безопасности DevSecOps

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

Процессный аудит и техническая оценка

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

Чем оценка не является

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

Стандарты и доказательная база

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

NIST SP 800-115: планирование, выполнение и этап после выполнения

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

NIST SP 800-204D: безопасность цепочки поставок внутри CI/CD

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

OWASP, CWE и CSF 2.0: роли, а не чек-листы

OWASP Application Security Verification Standard (ASVS) даёт проверяемые требования с версионированными идентификаторами вида v5.0.0-1.2.5, а списки требований доступны в машиночитаемых форматах, например CSV и JSON. Проект предупреждает, что идентификаторы могут меняться между версиями, поэтому версию нужно фиксировать. OWASP Web Security Testing Guide (WSTG) задаёт общий словарь для описания выполненных веб-проверок; в отчёте стоит указать используемый выпуск и то, опирались ли вы на черновые материалы. OWASP Top 10 — документ осведомлённости, и сам OWASP называет его первым шагом к культуре безопасного кода, поэтому «проверка по Top 10» не даёт глубины верификации. CWE Top 25 от MITRE ранжирует серьёзные и распространённые слабости на основе публичных записей CVE, а сопутствующий список Top 10 KEV Weaknesses ранжирует слабости, замеченные в активной эксплуатации, по каталогу Known Exploited Vulnerabilities агентства CISA. NIST CSF 2.0 переводит технические результаты в результаты управления рисками, а профили описывают текущее и целевое состояние.

Карта доверительных связей конвейера

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

Идентичность коммита и ревью

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

Определения CI и сторонние действия

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

Облачные и self-hosted раннеры

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

Выдача секретов и их область действия

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

Входные данные сборки, артефакты и продвижение в реестре

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

Зависимости и входные данные сборки

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

Происхождение и неизменяемость артефактов

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

Продвижение в реестре

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

Идентичности развёртывания, окружения и инфраструктура как код

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

Идентичности развёртывания

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

Согласования окружений

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

Что статический анализ IaC может и не может доказать

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

Безопасные негативные тесты и повторная проверка

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

Как проектировать безопасные негативные тесты

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

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

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

1. ПланированиеСогласовать рамки, доверительные связи, тестовые ресурсы и письменное разрешение
2. ВыполнениеПроверить конфигурацию; провести негативные тесты для разрешённых и пригодных связей
3. АнализЗафиксировать поведение, последствия, применимый CWE или категорию контроля и владельца
4. УстранениеИзменить сам контроль, а не только найденный единичный случай
5. Повторная проверкаПовторить исходный тест и зафиксировать отказ как доказательство закрытия

Находки, доказательства и приёмка

Оценка конвейера полезна, только если её находки можно проследить, сравнить во времени и принять или отклонить по ясным критериям. Матрица ниже показывает, каких доказательств стоит ожидать и что не следует принимать вместо них.

Гигиена находок и прослеживаемость

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

Линзы приоритизации: CWE Top 25 и KEV

CWE Top 25 отражает тяжесть и распространённость по публичным записям CVE, а список слабостей на основе KEV — наблюдаемую эксплуатацию. Вместе они дают внешнюю отправную точку для приоритизации. Ни один из них не описывает код или конвейер конкретной организации, поэтому окончательный порядок должны определять собственные находки, экспозиция и бизнес-контекст.

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

Числовая оценка зрелости выглядит точной, но в оценке конвейера это обычно экспертное суждение, переведённое в число. Это руководство не представляет такую оценку как измеренный результат. Если подрядчик использует модель баллов, спросите, на чём основано каждое значение, сможет ли другой специалист его воспроизвести и какие находки его изменили бы. Ясный перечень проверенных доверительных связей, наблюдаемого поведения и открытых рисков полезнее для CISO, чем необъяснённая цифра.

Компромиссы и ограничения

Возраст и актуальность. SP 800-115 опубликован в 2008 году и описывает процесс, а не современные CI-платформы.

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

Широта и глубина. Документы осведомлённости вроде Top 10 задают неглубокую базу, а верификация на уровне требований и негативные тесты требуют больше времени и доступа.

Веб-фокус. Большинство источников OWASP сосредоточены на приложениях; раннеры, токены и реестры требуют рамки, специфичной для конвейера, и собственной документации платформы.

Границы данных. Списки CWE построены на публичных записях CVE и служат исходной гипотезой, а не профилем внутреннего кода.

Момент времени. Оценка отражает конфигурацию, наблюдавшуюся во время работ, а конвейеры меняются быстро.

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

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

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

Вопросы подрядчику

• Какие пути поставки, репозитории, раннеры и окружения входят в рамки, а какие исключены?
• Какие доверительные связи будут проверены безопасными негативными тестами, а какие — только по документам?
• Какие версии ASVS и WSTG используются и как находки сопоставляются с CWE?
• Как доказательства из живого окружения будут сопоставлены с инфраструктурой как кодом?
• Как оформляются письменное разрешение, правила работ, тестовые ресурсы и обращение с данными?
• Входит ли в услугу повторная проверка исправлений и какие доказательства закрытия будут переданы?
• Как результаты связываются с результатами CSF 2.0 или реестром рисков организации?

Тревожные признаки

Настораживать должны «соответствие Top 10» как единственный результат, источники без версий, сырые выгрузки сканеров без анализа, единая оценка зрелости без объяснений и любые намёки на то, что отчёт сертифицирует конвейер как безопасный. Заявления о сертификатах, опыте и прошлых результатах стоит проверять самостоятельно. Если изменение конвейера совпадает с релизом, вопросы сроков из нашего руководства по пентесту перед запуском продукта применимы и здесь. Чтобы подготовиться к разговору с Pentest.red, на странице контура пентеста можно заранее перечислить репозитории, раннеры, окружения и ограничения.

Практическая схема принятия решений

Шаги ниже превращают метод в решения, которые подходят и для внутренней самооценки, и для технического задания.

• Определить контекст рисков по CSF 2.0: какие результаты должна поддержать оценка и какие пути поставки важнее всего.
• Разделить процессный аудит и техническую оценку и назначить владельца каждой части.
• Нанести доверительные связи для каждого пути в рамках работ, от коммита до production.
• Зафиксировать версии источников: набор требований ASVS, выпуск WSTG и списки CWE.
• Спланировать методы по каждой связи, указав цель, преимущества и ограничения, и выбрать безопасные негативные тесты.
• Определить критерии приёмки и доказательства закрытия до начала тестирования.
• Выбрать модель — собственными силами, внешний подрядчик или гибрид, — исходя из того, какие связи внутренняя команда уже может подтвердить доказательствами.
• Проводить повторную проверку после исправлений и повторную оценку при изменении конвейера или версий источников.

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

Заключение: как сделать оценку воспроизводимой

Воспроизводимая оценка безопасности DevSecOps разделяет процессный аудит и техническое тестирование, опирает метод на SP 800-115 и SP 800-204D, использует OWASP, CWE и CSF 2.0 в тех ролях, которые они действительно играют, и применяет безопасные негативные тесты к явно разрешённым и пригодным для тестирования связям, а остальные проверяет по конфигурации и доказательствам. Зафиксированные версии, прослеживаемые находки и доказательства повторной проверки делают результаты сравнимыми от цикла к циклу. Гипотетический конвейер из начала статьи прошёл все проверки; хорошая оценка — та, что задала бы вопрос, можно ли доказать, что проверенный коммит и есть артефакт, работающий в production.