Как организовать эффективный процесс безопасной разработки с подрядчиком

Как организовать эффективный процесс безопасной разработки с подрядчиком

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

Вы можете заключить с контрагентом строгий NDA (соглашение о неразглашении информации) и понадеяться на его благонадежность, но это не спасет вас от рисков компрометации его системы или рабочих станций. С таким доступом злоумышленники способны проникнуть внутрь сетевого периметра вашей компании или подменить объект поставки: добавить закладку в исходный код или зависимый компонент ПО.

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

В первую очередь необходимо выделить несколько сетевых контуров в порядке повышения их значимости:

1. Контур подрядчика — ​внешний сегмент разработки в инфраструктуре компании-исполнителя.
2. Контур вноса — ​демилитаризованная зона (DMZ), в которую загружаются результаты работы подрядчика.
3. Контур конвейера безопасной разработки — ​изолированный контур, в котором находятся средства проверки защищенности цифрового продукта.
4. Продуктивный контур — ​изолированная зона, в которой размещаются релизные версии ПО.

Чтобы свести к минимуму риски компрометации, необходимо ограничить сетевой доступ между контурами на уровне правил межсетевого экранирования. Должна быть запрещена инициация сетевых соединений из менее безопасных контуров к более безопасным, то есть доставка ПО должна осуществляться в итерационной последовательности, не «перескакивая» через уровни (рис. 1):

• на второй уровень через обращение к первому;
• на третий уровень через обращение ко второму;
• на четвертый уровень через обращение к третьему.

Рисунок 1. Должна быть запрещена инициация сетевых соединений из менее безопасных контуров к более безопасным, то есть доставка ПО должна осуществляться в итерационной последовательности

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

• ППК (перечень программных компонент) — ​специальный файл с описанием элементов поставляемого ПО, который позволяет на ранних этапах оценить безопасность зависимых компонент;
• Отчет о триаже — ​размеченные результаты тестирования SAST, SCA, DAST и других ИБ-проверок;
• Цифровая подпись — ​файл подписи архива, который обеспечивает защиту от подмены при передаче.

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

Подрядчик уведомляет заказчика о готовности релиза, после чего специалист со стороны клиента запускает процесс вноса дистрибутива в контуре DMZ. В этот момент выполняется проверка подписи архива поставки и его отправка на сканирование решением класса «песочница» (sandbox). Если подпись верна и поведенческий анализ подтверждает чистоту архива, он перемещается в специальное файловое хранилище. В ином случае процесс завершается.

Рассмотрим контур конвейера безопасной разработки. Он включает следующие ключевые элементы:

• хранилище артефактов (например, Nexus Repository);
• система хранения кода, сборки и доставки ПО (например, GitLab);
• инструменты DevSecOps: анализаторы SAST, SCA, DAST и другие (подробнее об этих решениях можно прочитать в статье «Построение контура разработки безопасного ПО» в выпуске BIS Journal №1 2025).

Процесс работы в контуре безопасной разработки начинается с получения объекта поставки из файлового хранилища в контуре DMZ. Это реализуется за счет автоматической проверки наличия новых архивов в заданном каталоге, выполняемой по расписанию.

После этого запускаются проверки инструментами DevSecOps с целью подтверждения отсутствия недекларированных возможностей (НДВ) и вредоносных зависимостей. На данном этапе AppSec-инженер рассматривает отчеты о триаже подрядчика и переносит разметку о ложноположительных срабатываниях в проведенные сканирования. Если анализаторы подрядчика и заказчика совпадают, этот процесс можно автоматизировать, однако участие специалиста все равно является обязательным для предотвращения случаев некорректной разметки.

По каждой из применяемых практик DevSecOps проводится оценка прохождения политик ИБ. Если они не пройдены, отчет с обнаруженными уязвимостями возвращается в файловое хранилище контура вноса. Для предотвращения утечки конфиденциальной информации рекомендуется встроить в этот процесс DLP-систему. После исправления найденных уязвимостей цикл повторяется.

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

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

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

1. Администратор запускает сценарий обновления на новую версию ПО.
2. Скрипт обращается к хранилищу артефактов ПО, расположенному в контуре конвейера, для получения дистрибутива.
3. Перед загрузкой дистрибутива производится проверка скачиваемого артефакта на наличие меток об успешных ИБ-проверках. Если меток нет, процесс завершается.
4. После загрузки дистрибутива выполняется проверка его подписи. Если проверка не проходит, процедура прерывается.

Таким образом, в продуктивный контур попадают только те приложения, которые успешно прошли ИБ-сканирования и имеют корректную подпись.

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