Создание безопасной цепочки поставок ПО: ключевые аспекты и технологии

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

Почему происходят подобного рода инциденты с цепочками поставок ПО Для ответа рассмотрим различные подходы внутри организации к политике применения прикладного ПО, необходимого для штатного функционирования ключевых бизнес-процессов. Существует три основных подхода:

• собственная разработка ПО;
• наемный коллектив разработчиков (т.н. заказная разработка);
• закупка готовых (вендорских) решений.

Более подробно процессы и требования, предъявляемые к различным подходам к проектированию, разработке и поддержке приложений, приводятся в ГОСТ Р ИСО/МЭК 27034-1. Каждый подход к поставке программного обеспечения имеет свои плюсы и минусы, и выбор подхода зависит от конкретных потребностей бизнеса, контекста и доступных ресурсов.

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

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

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

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

Жизненный цикл разработки ПО

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

Рассмотрим этапы типового процесса разработки ПО при непрерывной интеграции и непрерывном развертывании (для примера возьмем веб-приложение). Это поможет нам в дальнейшем выделить аспекты безопасности на каждом из этапов.

1. Анализ, планирование. На этом этапе определяются требования к проекту, цели и задачи, составляется план работы и распределяются ресурсы.
2. Написание кода. Программисты создают программный код, реализующий функционал по требованиям, используя выбранные языки программирования и технологии.
3. Сборка. На этапе сборки скомпилированный код объединяется в исполняемые файлы или пакеты, готовые для тестирования и развертывания.
4. Тестирование. Выполняются проверки работы программного продукта на наличие ошибок, багов и соответствие требованиям. Тестируются как функционал, так и производительность.
5. Развертывание. Программное обеспечение устанавливается в рабочую среду, проводятся финальные настройки и конфигурации для запуска.
6. Эксплуатация. Программный продукт переходит в стадию эксплуатации, и пользователи начинают активно работать с ним.
7. Мониторинг. На этом этапе осуществляется наблюдение за работой ПО, выявляются возможные проблемы, и собирается обратная связь для дальнейших улучшений.

На каждом этапе существуют свои сложившиеся ИТ-практики, а также риски и угрозы. 

Фреймворки защиты цепочки поставок ПО

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

• безопасная разработка ПО, охватывающая этапы с 1 по 4;
• безопасность среды эксплуатации, охватывающая этапы с 5 по 7.

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

Для начала обратимся к международному опыту. Национальный институт стандартов и технологий (NIST) в феврале 2022 года выпустил документ NIST SP 800-218 «Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities» («Фреймворк создания безопасного программного обеспечения: рекомендации по снижению рисков программных уязвимостей»). В документе приводится базовый набор способов и мер разработки безопасного программного обеспечения высокого уровня, которые могут быть интегрированы в каждый этап жизненного цикла разработки ПО, а также приводится маппинг на похожие меры безопасности в других стандартах безопасности, таких как BSIMM, IEC 62443, OWASP SAMM, PCI SSLC и другие. Следование такой практике должно помочь производителям программного обеспечения сократить количество уязвимостей в выпускаемом программном обеспечении, снизить потенциальное воздействие использования необнаруженных или неурегулированных уязвимостей и устранить коренные причины уязвимостей для предотвращения их повторения в будущем.

В России с 2016 года вступил в силу ГОСТ Р 56939 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». Стандарт устанавливает общие требования к содержанию и порядку выполнения работ, связанных с созданием безопасного ПО. В стандарте предусмотрены различные виды испытаний и проверок безопасности ПО: статический/динамический, экспертиза кода (code review), функциональное тестирование программы, тестирование на проникновение, фаззинг-тестирование и т.д. При этом, по состоянию на сентябрь 2024 года, данный ГОСТ находится в состоянии активной доработки в ТК 362. Например, в документ внесены требования к поставке ПО пользователям, среди которых:

• обеспечение безопасности сборочной среды;
• обеспечение безопасности секретов;
• проверка на предмет внедрения ВПО через цепочки поставок;
• обеспечение безопасности при выводе ПО из эксплуатации.

Также хочется отметить документы, разработанные компанией Cloud Native Computing Foundation (CNCF), которая является проектом Linux Foundation, а именно специализированный стандарт «Software Supply Chain Best Practices». Согласно данному документу, практика реализации процесса обеспечения безопасности цепочки поставок программного обеспечения основана на четырех основных принципах:

• эшелонированная защита (многоуровневый комплексный контроль безопасности);
• подписание ЭП и проверка;
• анализ артефактов и их метаданных;
• автоматизация процессов CI/CD.

Как защититься

Если обобщить практики из вышеуказанных стандартов и применить их к реалиям современной разработки, то можно сформировать условный чек-лист мер безопасности, которые стоит реализовать у себя в организации в зависимости от выбранной политики применения ПО. Постараемся заострить внимание прежде всего на неочевидных мерах, поскольку про техники SAST, DAST, fuzzing, формирование ASOC есть масса подробных материалов в печати.

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

Раскроем некоторые пункты таблицы более подробно:

I.2.1.1 Необходимо разработать ролевую модель доступа к исходному коду с учетом принципов «наименьших привилегий», «четырех глаз». С технической точки зрения доступ можно укрепить многофакторной аутентификацией (MFA).

I.2.1.2 Для поддержания гарантий достоверности применяем на данном этапе и далее в течение всего ЖЦ электронные подписи и контрольные суммы для подписания кода, артефактов и т.п.

I.2.2.2 Некоторые SCA-решения на рынке уже имеют в своем составе модуль предиктивной аналитики по рискам, связанным с репутацией разработчиков open source. Исходя из объема заимствований в вашем проекте, не лишним будет самостоятельно провести аналогичную проверку.

I.2.2.4 Важно управлять лицензионными рисками заимствованных компонентов, к примеру, копилефтные лицензии GPL v3, v2 могут не соответствовать коммерческим интересам вашего продукта. Тогда целесообразно обратить внимание на MIT, Apachе.

I.2.4 Под обеспечением базовой защиты среды разработки будем понимать применение следующего «джентельменского» набора средств: АВЗ, сканеров защищенности, многофункциональных шлюзов безопасности, СЗИ от НСД.

I.3.1 Рекомендуется проектировать архитектуру пайплайна CI/CD в виде микросервисов под управлением оркестратора, при этом для выполнения каждого job использовать свой отдельный контейнер, образ которого брать из репозитория. В репозитории рекомендуется использовать distroless-образы, которые необходимо сканировать на известные уязвимости.

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

II.2.1, II.2.2, III.2.1, III.2.2 В зависимости от ситуации мы можем получить/запросить имеющиеся свидетельства о проведении SAST, DAST у наемного коллектива разработки либо у вендора.

II.3.1 Для истории проекта, а также для целей форензики, не лишним будет иметь логи сборки. Важно обращать внимание на «сомнительные» сетевые обращения.

5.1 Под обеспечением расширенной защиты продовой среды будем понимать применение следующего дополнительного набора средств: EDR, NTA, anti-DDoS, deception, SIEM, DLP и т.д.

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

6.1 Основной функцией безопасности WAF в данном контексте будет виртуальный патчинг (слой политики безопасности, предназначенный для обнаружения и предотвращения эксплуатации эксплойта для известной уязвимости).

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

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