Безопасность цепочки поставки за 7 минут

Цепочка поставки ПО это всё, что превращает исходники в работающий сервис: зависимости, базовые образы, инструменты сборки, CI, реестры, деплой. Атака на любое звено даёт злоумышленнику код в вашем проде, даже если ваш собственный код безупречен.

Громкие примеры

• SolarWinds (2020): взломали сборочную систему, вредоносный код попал в подписанные обновления продукта.
• Codecov (2021): подменили скрипт загрузки отчётов, который тысячи пайплайнов скачивали через curl | bash, и он отправлял наружу переменные окружения CI.
• xz-utils (2024): мейнтейнер, годами набиравший доверие, встроил бэкдор в сборочные скрипты библиотеки сжатия; его поймали случайно по замедлению SSH.
• Подмена тегов GitHub Actions (2025): в популярном action перезаписали теги на вредоносный коммит, и пайплайны, ссылавшиеся на тег, печатали свои секреты в логи.

Вывод: доверять «по имени и тегу» нельзя, нужно фиксировать, проверять и ограничивать.

Зависимости

• Lock-файлы (package-lock.json, poetry.lock, go.sum) в git: каждая сборка ставит ровно проверенные версии и хеши.
• Обновления через Dependabot или Renovate маленькими MR с прогоном тестов, а не «раз в год всё сразу».
• Typosquatting: пакет reqeusts вместо requests. Внимательность при добавлении и проверка новых зависимостей на ревью.
• Dependency confusion: если внутренний пакет acme-utils ищется и во внутреннем, и в публичном реестре, злоумышленник публикует в публичный пакет с тем же именем и большей версией. Защита: scoped-пакеты (@acme/utils), один прокси-реестр (Nexus, Artifactory) с явными правилами, откуда брать какие имена.
• Скрипты установки (postinstall в npm) выполняются при установке. В CI их можно отключить (--ignore-scripts), где это не ломает сборку.

Образы

• Базовый образ минимальный: distroless, alpine, -slim. Меньше пакетов, меньше уязвимостей.
• Ссылка по digest: FROM python:3.13-slim@sha256:.... Тег могут перезаписать, digest нет. Обновлять digest помогает тот же Renovate.
• Свой реестр (Harbor, GitLab Registry, облачный) как прокси для внешних образов: меньше зависимость от Docker Hub и его лимитов, плюс сканирование.

Сканирование

• SCA (анализ состава): Trivy, Grype, OWASP Dependency-Check ищут известные CVE в зависимостях и пакетах образа.
• SAST: анализ своего кода (Semgrep, CodeQL, SonarQube).
• Сканирование секретов: gitleaks, trufflehog.
• IaC-сканеры: Checkov, tfsec (вошёл в Trivy), kube-linter.

Сканер находит десятки CVE, большинство в неиспользуемом коде. Нужна политика: блокировать сборку на критических с доступным исправлением, остальное в бэклог со сроками. VEX-документы фиксируют «уязвимость есть, но не эксплуатируется у нас».

SBOM

SBOM (Software Bill of Materials): машиночитаемый список всех компонентов артефакта с версиями. Форматы SPDX и CycloneDX, генераторы Syft, Trivy. Когда выходит новая критическая уязвимость, SBOM за минуты отвечает, какие сервисы её содержат, вместо недели ручного поиска.

Подпись и происхождение

• Подпись образа: cosign из проекта Sigstore. В режиме keyless CI подписывает образ короткоживущим сертификатом, выданным по OIDC-удостоверению джобы, а запись о подписи попадает в публичный журнал прозрачности (Rekor).
• Provenance (аттестация происхождения): подписанное утверждение «этот образ собран из такого-то коммита таким-то пайплайном».
• Проверка при деплое: admission-контроллер в Kubernetes (Kyverno, Sigstore policy-controller) пускает только подписанные образы из своего реестра.

SLSA

SLSA (Supply-chain Levels for Software Artifacts): фреймворк уровней зрелости сборки. В версии 1.0 уровни Build L1-L3: L1 происхождение задокументировано, L2 подписанное происхождение от размещённой сборочной платформы, L3 сборка изолирована и защищена от вмешательства даже владельцев проекта. Полезен как чек-лист, куда двигаться.

Защита самого пайплайна

• Минимальные права токенов, OIDC вместо статических ключей.
• Сторонние actions и образы по SHA и digest.
• Защищённые ветки, обязательное ревью, CODEOWNERS для пайплайнов.
• Одноразовые раннеры для недоверенного кода.
• Никаких curl | bash без проверки хеша.

В России для критичных систем есть требования к безопасной разработке (ГОСТ Р 56939 и требования ФСТЭК): анализ кода, контроль заимствованных компонентов, их и спрашивают в банках и госсекторе.

Частые ошибки

• Сканер стоит, но его отчёты никто не читает.
• Зависимости обновляют раз в год, поэтому каждое обновление страшное.
• Подпись образов есть, а проверки при деплое нет.
• Внутренние пакеты без scope в общем реестре.

Что спросят на собесе

• Что такое атака на цепочку поставки, приведите пример.
• Зачем SBOM и чем он поможет при новой критичной CVE.
• Как подписывать образы и где проверять подпись.
• Что такое dependency confusion и как защититься.
• Как организовать работу с уязвимостями, чтобы сканер не стал шумом.