Supply chain: защита цепочки поставки зависимостей

Прямой ответ

Атака на цепочку поставки (supply chain) направлена не на ваше приложение, а на то, из чего оно собирается: зависимости, образы, инструменты сборки. Код приложения при этом не меняется, а вредоносное поведение попадает в продукт через доверенный компонент.

Основные векторы:

Первая мера — фиксация версий. Диапазон версий позволяет получить новую сборку без изменения кода:

# небезопасно: версия определяется в момент установки
requests>=2.28

# безопасно: точная версия и контрольная сумма
requests==2.32.3

Файл блокировки (lock file) фиксирует полное дерево зависимостей с контрольными суммами. Установка без него каждый раз разрешает версии заново, и результат может отличаться от проверенного.

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

Третья мера — проверка подписей. Образ, подписанный при публикации, проверяется при развёртывании:

cosign verify --certificate-identity-regexp='example\.com' \
    registry.example.com/app:v1.2.3

Проверка подтверждает, что образ создан доверенным конвейером, а не подменён в реестре; о настройке — в статье про SBOM и подпись образов.

Четвёртая мера — наименьшие права в CI. Конвейер сборки не должен иметь прав на запись в продуктивный реестр или доступа к секретам, не нужным для сборки. Компрометация конвейера с широкими правами даёт доступ ко всей цепочке.

SBOM (спецификация состава) перечисляет компоненты продукта и позволяет быстро определить, затронут ли сервис уязвимостью в конкретной библиотеке; о составе — в статье про SBOM.

Практика: защита цепочки поставки

1. Фиксируйте версии с контрольными суммами. Установка из файла блокировки гарантирует, что собирается проверенный набор компонентов.

2. Используйте зеркало реестра. Частный реестр с одобренными пакетами исключает подмену и путаницу зависимостей.

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

4. Проверяйте подписи базовых образов. Развёртывание неподписанного образа из публичного источника не подтверждает его происхождение.

5. Ограничьте права конвейера сборки. Токен с доступом только к нужному репозиторию и без права записи в продуктовый реестр.

6. Ведите SBOM и проверяйте его. Перечень компонентов позволяет за минуты определить затронутые сервисы при публикации уязвимости; о проверках — в статье про аудит зависимостей.

7. Контролируйте обновления автоматически. Автоматические запросы на обновление сокращают время между публикацией исправления и его применением; о настройке — в статье про Dependabot.

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

Рекомендации:

1. Не добавляйте зависимости из непроверенных источников. Пакет с десятком загрузок и недельной историей — высокий риск.
2. Фиксируйте версии базовых образов. Тег latest меняется без вашего ведома и делает сборку невоспроизводимой.
3. Разделяйте секреты по этапам конвейера. Секрет публикации недоступен на этапе тестов.
4. Проверяйте журнал изменений при крупных обновлениях. Смена сопровождающего или лицензии — повод для проверки.
5. Тестируйте обновление до слияния. Автоматический запрос на обновление должен проходить полный набор проверок.

Практический сценарий: остановка сборки после подмены внутреннего пакета

Контекст: сборка сервиса начала устанавливать пакет из публичного реестра вместо внутреннего. Имена совпадали, содержимое отличалось.

1. Диагностика. В журнале сборки установка шла из публичного источника. Внутренний реестр не был указан как приоритетный, поэтому разрешение имени выполнилось по внешнему источнику.
2. Причина. Отсутствие зеркала реестра: зависимости разрешались напрямую из публичного источника, а внутренний пакет с тем же именем был опубликован злоумышленником.
3. Действия. (а) Развернули зеркало реестра с приоритетом внутренних пакетов и запретом внешнего разрешения для внутренних имён; (б) включили установку строго из файла блокировки с проверкой контрольных сумм; (в) добавили проверку подписи базовых образов при развёртывании; (г) ограничили токен конвейера: доступ только на чтение к репозиторию и запись в отдельный реестр сборки; (д) сформировали SBOM и проверили, какие сервисы устанавливали подменённый пакет.
4. Результат. Сборка перестала обращаться к внешним источникам, а проверка подписи исключает развёртывание неподписанного образа. Инцидент не затронул продуктивную среду, поскольку сборка остановилась на этапе проверки контрольных сумм.

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

FAQ

Достаточно ли фиксировать версии в файле зависимостей? Нет. Нужен файл блокировки с контрольными суммами: без него дерево зависимостей разрешается заново и может измениться.

Что даёт SBOM на практике? Перечень компонентов позволяет быстро найти затронутые сервисы при публикации уязвимости вместо ручного поиска по репозиториям.

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

Почему нельзя давать конвейеру широкие права? Компрометация конвейера с доступом к продуктивному реестру позволяет опубликовать вредоносную версию от доверенного имени.

Источники: SLSA specification, Sigstore Cosign docs, OWASP Top 10 — ссылки в шапке.