Атакувальники дедалі частіше оминають сам застосунок і цілять у те, що його збирає: скомпрометовану залежність, перехоплений CI-екшен, отруєний базовий образ. Нова категорія A03 в OWASP Top 10:2025 — Software Supply Chain Failures — відображає цей зсув, а в ЄС Cyber Resilience Act перетворює частину гігієни ланцюга постачання на закон: обов'язки повідомляти про вразливості діють з 11 вересня 2026 року. У гайді — практичний базовий рівень для команд, що постачають контейнери: мінімальні образи, сканування, SBOM, підписи, provenance і політики, що перевіряють усе це перед деплоєм.
Чому безпека ланцюга постачання важлива саме зараз
Типовий образ сервісу містить ваш код, сотні open-source пакетів і шар операційної системи. Кожен із них — і кожен інструмент у пайплайні, що їх збирає, — частина вашої поверхні атаки. Два уроки з недавніх інцидентів:
- CI — це продакшен-система. Компрометація GitHub Action
tj-actions/changed-filesу березні 2025 року злила секрети з логів workflow у тисячах репозиторіїв (CISA, 2025). - Не можна виправити те, чого не бачиш. Коли критична вразливість з'являється в популярній бібліотеці, команди з інвентарем компонентів за хвилини знають, які сервіси зачеплено; інші днями шукають grep'ом.
Регуляторний тиск: Cyber Resilience Act
EU Cyber Resilience Act — Регламент (ЄС) 2024/2847 — встановлює вимоги кібербезпеки до продуктів із цифровими елементами на ринку ЄС, зокрема до програмного забезпечення. Важливі дві дати (Європейська комісія: CRA):
- 11 вересня 2026: виробники мають повідомляти про вразливості, що активно експлуатуються, і серйозні інциденти — раннє попередження протягом 24 годин, повідомлення протягом 72 годин і фінальний звіт пізніше (обов'язки звітування за CRA).
- 11 грудня 2027: застосовуються основні обов'язки, зокрема вимоги secure-by-design, обробка вразливостей і документування компонентів, серед іншого через перелік компонентів ПЗ (SBOM).
Навіть якщо ваш продукт поза сферою дії регламенту, enterprise-клієнти дедалі частіше проситимуть SBOM і докази безпечних практик збірки.
Шар 1: мінімальні, зафіксовані базові образи
Менше пакетів — менше вразливостей і менше що патчити.
- Використовуйте мінімальні базові образи: distroless-образи містять лише рантайм, потрібний застосунку, без shell і пакетного менеджера (Distroless).
- Використовуйте multi-stage збірки, щоб компілятори й інструменти збірки ніколи не потрапляли в рантайм-образ.
- Фіксуйте базові образи за digest, а не за змінюваним тегом, і доручіть оновлення боту.
- Запускайте від імені не-root користувача і забезпечуйте це в Kubernetes через Pod Security Standards (Kubernetes: Pod Security Standards).
FROM eclipse-temurin:25-jdk@sha256:<digest> AS build
WORKDIR /src
COPY . .
RUN ./gradlew bootJar --no-daemon
FROM gcr.io/distroless/java25-debian13@sha256:<digest>
COPY --from=build /src/build/libs/app.jar /app/app.jar
USER nonroot
ENTRYPOINT ["java", "-jar", "/app/app.jar"]
Шар 2: скануйте залежності й образи
- Залежності в pull request'ах: перевірка залежностей і автоматичні оновлення, як у нашому шаблоні CI/CD.
- Образи в CI і реєстрах: сканери на кшталт Trivy чи Grype знаходять відомі вразливості в пакетах ОС і залежностях мов.
- Сортуйте, а не тоніть. Валіть збірки на критичних вразливостях, для яких є виправлення; решту відстежуйте з відповідальними та строками. Сканер із 400 знахідками, які ніхто не читає, гірший за сканер із чіткою політикою.
Шар 3: генеруйте SBOM
SBOM (software bill of materials) — перелік компонентів вашого артефакту: назви, версії, ліцензії, хеші. Два усталені формати — SPDX (стандарт ISO/IEC) і CycloneDX (ECMA-424) (SPDX; CycloneDX; ECMA-424). CISA веде рекомендації щодо мінімальних елементів і практик SBOM (CISA: SBOM).
Генеруйте SBOM під час збірки, прикріплюйте до образу і зберігайте так, щоб можна було запитати «які образи містять бібліотеку X версії Y?»:
# BuildKit може прикріпити до образу SBOM і атестацію provenance
docker buildx build --sbom=true --provenance=mode=max \
-t registry.example.com/orders:1.4.2 --push .
# Або згенерувати SBOM окремо через Syft
syft registry.example.com/orders:1.4.2 -o cyclonedx-json > orders-1.4.2.cdx.json
Деталі — у документації Docker про атестації збірки і Syft (Docker: build attestations).
Шар 4: підписуйте артефакти
Підпис доводить, що образ вийшов із вашого пайплайна і не був змінений. Cosign від Sigstore підтримує keyless-підписування: у CI OIDC-ідентичність workflow отримує короткоживучий сертифікат, а підпис записується в публічний журнал прозорості, тож немає довгоживучих ключів підпису, які можуть витекти (Sigstore; cosign signing).
# Фрагмент джоби GitHub Actions
permissions:
id-token: write # OIDC-токен для keyless-підпису
packages: write
attestations: write
steps:
- uses: sigstore/cosign-installer@<pinned-sha>
- run: cosign sign --yes registry.example.com/orders@${{ steps.build.outputs.digest }}
- uses: actions/attest-build-provenance@<pinned-sha>
with:
subject-name: registry.example.com/orders
subject-digest: ${{ steps.build.outputs.digest }}
push-to-registry: true
Artifact attestations у GitHub генерують підписаний provenance збірки для ваших артефактів (GitHub: artifact attestations).
Шар 5: provenance і SLSA
SLSA (Supply-chain Levels for Software Artifacts) — фреймворк, що описує дедалі сильніші гарантії щодо того, як зібрано артефакт (SLSA; рівні SLSA v1.0):
| Рівень збірки | Вимога | На практиці |
|---|---|---|
| L1 | Provenance існує | Збірка створює запис про те, як зібрано артефакт |
| L2 | Хостингова платформа збірки, підписаний provenance | Збірки виконуються на керованому CI, що підписує provenance |
| L3 | Захищена платформа збірки | Збірки ізольовані одна від одної; секрети підпису недоступні крокам збірки |
Більшість команд швидко досягають L2 з хостинговим CI і artifact attestations; L3 вимагає суворішої ізоляції платформи збірки.
Шар 6: перевіряйте перед деплоєм
Підписи нічого не варті, якщо їх ніхто не перевіряє. Застосовуйте політики на рівні кластера: запускатися можуть лише образи, підписані ідентичністю вашого CI, з вашого реєстру, без критичних вразливостей. Admission-контролери Kubernetes на кшталт policy-controller від Sigstore чи Kyverno перевіряють підписи й атестації під час деплою.
Практична дорожня карта
- Тижні 1–2: зафіксуйте екшени й базові образи, мінімізуйте права CI-токенів, увімкніть перевірку залежностей.
- Тижні 3–4: перейдіть на мінімальні базові образи й не-root контейнери; додайте сканування образів із чіткою політикою падіння збірки.
- Місяць 2: генеруйте і зберігайте SBOM для кожного релізу; налаштуйте спосіб робити по них запити.
- Місяць 3: підписуйте образи й додайте provenance збірки; перевіряйте підписи на admission спершу на staging, потім у продакшені.
- Постійно: процес реагування на вразливості з відповідальними та SLA — вимога CRA для продуктів у сфері його дії.
Інфраструктурний код належить до того самого ланцюга: фіксуйте версії провайдерів і переглядайте плани, як описано у статті Terraform чи OpenTofu. Про ризики на рівні застосунку — у статті OWASP Top 10:2025 для веброзробників.
FAQ
Чи потрібен SBOM, якщо ми не продаємо в ЄС? Дедалі частіше так: enterprise-клієнти й державні замовники в США просять їх, і вони значно пришвидшують реагування на вразливості.
SPDX чи CycloneDX? Обидва широко підтримуються. Обирайте той, що використовують ваші інструменти й клієнти; багато інструментів генерують обидва.
Чи достатньо сканування образів? Ні. Сканування знаходить відомі вразливості в компонентах; підписи і provenance доводять, що артефакт не підмінили. Потрібне і те, і інше.
Чи означає keyless-підпис, що підписати може будь-хто? Ні. Підпис прив'язаний до конкретної ідентичності — наприклад, CI-workflow вашого репозиторію, — і політики перевірки перевіряють саме її.
Джерела
- Європейський Союз. Регламент (ЄС) 2024/2847 (Cyber Resilience Act); Європейська комісія: CRA, обов'язки звітування.
- CISA. Software Bill of Materials і компрометація tj-actions/changed-files.
- SLSA і рівні SLSA v1.0.
- Sigstore і cosign signing overview.
- SPDX, CycloneDX, ECMA-424.
- Docker. Build attestations; GitHub. Artifact attestations.
- Distroless images, Syft, Trivy.