Заказчики ужесточают DevSecOps: подрядчиков проверяют на каждом шаге сборки

В декабре 2020 года троянизированное обновление SolarWinds Orion дошло примерно до 18 000 клиентов компании. Через эту историю индустрия заново поняла: уязвимым может оказаться не продукт, а сам путь, которым он попал к заказчику. Российский рынок приходит к тому же выводу. По материалу TAdviser, заказчики всё глубже уходят в нулевое доверие к ИТ-подрядчикам и требуют «стерильный конвейер» разработки с многократной проверкой кода. Основа подхода — DevSecOps, цикл создания ПО, где безопасность заложена в каждый этап, а не добавляется перед релизом.

Откуда берётся недоверие

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

Примеры известны. Уязвимость Log4Shell в конце 2021 года показала, как одна библиотека с логированием оказывается в тысячах продуктов, о которых их владельцы даже не подозревают. Бэкдор в архиваторе XZ Utils (CVE-2024-3094), обнаруженный в 2024 году, был внедрён через долгую социальную инженерию сопровождающего проекта. Принцип нулевого доверия, формализованный в NIST SP 800-207, предписывает проверять каждого участника и каждое действие. Теперь он применяется к разработке.

Как выглядит «стерильный конвейер»

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

• изолированная среда сборки без выхода в интернет и с ограниченным набором внешних зависимостей;
• статический анализ кода (SAST) на каждом коммите и динамический (DAST) на тестовых стендах;
• композиционный анализ (SCA): инвентаризация сторонних компонентов и поиск известных уязвимостей;
• SBOM, перечень всех компонентов сборки, как обязательный артефакт поставки;
• сканирование репозиториев на секреты: ключи, токены, пароли;
• обязательное ревью кода вторым человеком и подпись собранных артефактов;
• повторная проверка исходников и сборки на стороне заказчика.

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

Цена для подрядчика

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

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

С чего начать

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

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