Защита от атак на цепочку поставок ПО: пошаговый план внедрения

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

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

1. Определите границы цепочки и модель риска

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

Проверка должна охватывать как минимум четыре зоны:

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

NIST SP 800-161 Rev. 1 рассматривает управление рисками цепочки поставок как часть общего управления киберрисками. В числе угроз — вредоносная функциональность, поддельные компоненты, уязвимости из-за небезопасных практик разработки и недостаточная видимость того, как технология создаётся и интегрируется. Это важное архитектурное уточнение: поставщик или библиотека не становятся безопасными только потому, что давно присутствуют в стеке.

Сначала определите, что защищаете. Для внутреннего инструмента с ограниченными полномочиями и для SaaS-сервиса, который обрабатывает персональные данные, цена одинакового дефекта различается. Оцените последствия компрометации: доступ к данным, возможность выполнить код в инфраструктуре, влияние на клиентов, критичность сервиса. Затем назначьте владельцев рисков. Если за репозиторий отвечает разработка, за CI — платформа, а за сторонние пакеты никто, контроль будет формальным.

Цепочка поставок начинается там, где организация теряет видимость происхождения кода или артефакта.

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

2. Соберите инвентарь компонентов и начните с SBOM

Без актуального перечня компонентов нельзя оценить, какие продукты затронуты новой уязвимостью. Для этого используют SBOM — машинно-читаемый перечень программных компонентов и их связей. Но файл SBOM сам по себе ничего не доказывает. Его ценность зависит от полноты, точности и привязки к конкретной версии продукта.

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

Автоматизация здесь практичнее ручного учёта. Формирование SBOM можно встроить в CI/CD и сохранять рядом с артефактом релиза. При изменении состава компонентов инвентарь должен обновляться в рамках того же процесса, а не по отдельному запросу в таблицу. Для старых продуктов, где автоматическая генерация пока недоступна, зафиксируйте ограничение и назначьте владельца перехода.

При проверке SBOM задайте команде конкретные вопросы:

• Можно ли получить список компонентов для любой поддерживаемой версии?
• Сопоставляется ли он с точным артефактом, который развёрнут в рабочей среде?
• Видны ли транзитивные зависимости и версии пакетов?
• Обновляется ли запись при изменении состава сборки?
• Есть ли ответственный за устранение расхождений между SBOM, репозиторием и фактическим релизом?

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

OWASP рекомендует автоматизировать создание и обработку SBOM, интегрировать их в CI/CD, где это возможно, и регулярно проверять зависимости по базам уязвимостей. Среди упомянутых источников — NVD, OSV и каталог CISA KEV. Подключение нескольких баз не отменяет триаж: совпадение по названию пакета ещё нужно сопоставить с используемой версией и условиями эксплуатации.

3. Закройте риски сборочной среды и CI/CD

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

Проверьте инфраструктуру сборки по отдельным слоям:

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

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

3. Агенты и раннеры. Зафиксируйте, какие версии образов и инструментов используются. Изолируйте среды выполнения, особенно если в одном агенте запускаются задания с разным уровнем доверия.

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

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

Повторяемая сборка повышает проверяемость: для одинаковых исходных данных и спецификации окружения процесс должен давать ожидаемый результат. OWASP SCVS включает повторяемые сборки через CI в примеры базовых практик. Это не гарантия отсутствия вредоносного кода. Это способ уменьшить неопределённость и выявлять необъяснимые расхождения между сборками.

Учитывайте и сценарии с внешними компонентами CI/CD. Расширение или действие, подключённое к пайплайну, может исполнять код с доступом к секретам и репозиторию. Зафиксируйте используемые версии и источники таких компонентов. Обновление «до последней версии» без проверки тоже несёт риск: процесс должен позволять оценить изменение, а не автоматически переносить доверие на новый код.

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

4. Проверьте сторонние зависимости и поставщиков

Управление зависимостями начинается с воспроизводимого описания того, что именно приложение использует. Закрепляйте проверенные версии в lock-файлах. Это снижает риск, что одинаковый коммит при повторной сборке незаметно получит иной набор пакетов. Lock-файл также облегчает разбор инцидента: состав дерева зависимостей можно восстановить точнее.

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

• Используется ли уязвимый компонент в затронутой версии?
• Достижим ли уязвимый участок кода в вашей конфигурации?
• Есть ли исправленная версия или временная мера?
• В каких продуктах и выпусках присутствует компонент?
• Кто отвечает за обновление и в какой момент риск будет пересмотрен?

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

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

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

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

5. Внедряйте контроль по уровням риска

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

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

Рабочая схема внедрения может выглядеть так:

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

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

3. Назначьте уровень проверки по последствиям компрометации. Учитывайте назначение ПО и чувствительность данных, а не только его название или размер команды.

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

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

NIST SP 800-161 Rev. 1 и SSDF дают ориентиры для управления рисками и практик безопасной разработки. OWASP SCVS помогает разложить оценку на проверяемые области. Эти материалы можно адаптировать к внутренним процессам. Они не задают одинаковые сроки внедрения, обязательные пороги риска или единую последовательность для каждой организации.

Что должно остаться после внедрения

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

Перед утверждением плана проверьте, что в нём:

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

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