• Содержание
  • Зачем это бизнесу
  • Что такое цепочка поставки ПО коротко
  • Минимально достаточный набор практик
  • План внедрения за 2–3 недели (пошагово)
  • Примеры готовых конфигураций (CI, SBOM, сканер, политика в Kubernetes)
  • Метрики успеха и контроль качества
  • Частые ошибки и как их избежать
  • Стоимость и окупаемость
  • Чек‑лист для запуска

Зачем это бизнесу

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

• простоям и недоступности сервисов;
• компрометации данных клиентов и штрафам регуляторов;
• блокировке релизов, росту стоимости аудита и сертификаций;
• потере доверия партнёров и маркетинговых каналов.

Хорошая новость: базовая защита цепочки поставки внедряется постепенно и без радикальной перестройки. Достаточно трёх вещей:

• подписывать артефакты (контейнеры, двоичные файлы) проверяемым способом;
• собирать SBOM — «список ингредиентов» ПО с версиями библиотек;
• не пускать в продакшен то, что не подписано или содержит критичные уязвимости.

Этого уже достаточно, чтобы:

• снизить вероятность поставки заражённого образа;
• сократить время аудита (есть доказательства происхождения артефакта);
• быстрее реагировать на новые CVE: по SBOM сразу видно, где уязвимая библиотека.

Что такое цепочка поставки ПО коротко

Цепочка поставки — путь от исходного кода до запуска в продакшене:

1. код и зависимости;
2. сборка (CI) и упаковка в артефакт (контейнер, бинарник);
3. хранение артефактов в реестре;
4. развертывание в окружениях.

Уязвимости и подмены могут произойти на каждом шаге. Наша задача — «привязать» артефакт к прозрачной истории происхождения и отсеивать все неизвестные и небезопасные варианты на этапе деплоя.

Минимально достаточный набор практик

• Подпись образов контейнеров ключом или «без ключей» через доверенного поставщика удостоверений (OIDC) — например, GitHub Actions. Проверка подписи в кластере.
• Генерация SBOM на этапе сборки и публикация рядом с образом.
• Сканирование образов на уязвимости и блокирование релизов при критичных находках.
• Политики в Kubernetes (Kyverno/OPA), запрещающие неподписанные образы и образы без SBOM.
• Фиксация зависимостей (lock‑файлы) и воспроизводимая сборка.

Эта связка даёт быструю отдачу: повышает контроль без удлинения пайплайна релизов на недели.

План внедрения за 2–3 недели (пошагово)

Шаг 1. Зафиксируйте зависимости

• JavaScript/TypeScript: используйте package-lock.json или yarn.lock, включите npm ci в CI.
• Python: requirements.txt или poetry.lock, устанавливайте только из lock‑файла.
• Go: go.mod + go.sum, модульная сборка.
• Java: maven/gradle с checksum‑верификацией и зеркалом доверенного репозитория.

Это резко снижает риск «тихой» подмены зависимости.

Шаг 2. Подписывайте контейнеры при сборке (Cosign)

Cosign позволяет подписывать образы и хранить подписи прямо в реестре. Можно использовать «keyless» режим через OIDC — без ручного управления ключами.

Пример GitHub Actions для сборки, подписи и публикации образа в ghcr.io:

name: build-sign-and-push

on:
  push:
    branches: ["main"]

permissions:
  contents: read
  id-token: write         # нужно для keyless-подписи Cosign
  packages: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push image
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ghcr.io/${{ github.repository }}/app:sha-${{ github.sha }}

      - name: Install Cosign
        uses: sigstore/cosign-installer@v3.5.0

      - name: Sign image with Cosign (keyless)
        env:
          COSIGN_EXPERIMENTAL: "1"
        run: |
          cosign sign --yes ghcr.io/${{ github.repository }}/app:sha-${{ github.sha }}

Подпись будет связана с вашим репозиторием и коммитом через OIDC GitHub.

Шаг 3. Генерируйте SBOM при сборке

SBOM — это машинночитаемый перечень компонентов и версий, из которых состоит образ. Рекомендуемые форматы: SPDX или CycloneDX. Пример с Syft:

      - name: Generate SBOM (SPDX) with Syft
        uses: anchore/sbom-action@v0
        with:
          image: ghcr.io/${{ github.repository }}/app:sha-${{ github.sha }}
          format: spdx-json
          output-file: sbom.spdx.json

      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.spdx.json

Рекомендуется также положить SBOM в тот же реестр, как аттестацию cosign:

cosign attest \
  --yes \
  --predicate sbom.spdx.json \
  --type spdx \
  ghcr.io/OWNER/REPO/app:sha-COMMIT_SHA

Шаг 4. Сканируйте уязвимости и ставьте «красный светофор»

Можно использовать Trivy или Grype. Пример с Trivy в CI:

      - name: Scan image with Trivy
        uses: aquasecurity/trivy-action@0.20.0
        with:
          image-ref: ghcr.io/${{ github.repository }}/app:sha-${{ github.sha }}
          format: 'table'
          exit-code: '1'
          vuln-type: 'os,library'
          severity: 'CRITICAL,HIGH'

При наличии критичных или высоких уязвимостей задача завершится с ошибкой — деплой не пойдёт дальше.

Шаг 5. Включите проверку подписи в Kubernetes (Kyverno)

Kyverno — политик‑движок для Kubernetes. Он умеет проверять подписи cosign и блокировать неподписанные образы. Устанавливаем Kyverno и включаем политику валидации.

Пример политики, которая разрешает развертывание только образов, подписанных через OIDC GitHub Actions из вашего репозитория:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-signed-images
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: require-cosign-signature
      match:
        any:
          - resources:
              kinds: ["Pod", "Deployment", "StatefulSet", "DaemonSet", "Job", "CronJob"]
      verifyImages:
        - image: "ghcr.io/your-org/*"
          keyless:
            issuer: "https://token.actions.githubusercontent.com"
            subject: "repo:your-org/your-repo:ref:refs/heads/main"
          repository: "ghcr.io"

Теперь любые манифесты с неподписанными образами будут отклоняться сервером API кластера.

Шаг 6. Не пускайте образы без SBOM и с критичными CVE

Вариант 1: проверять в CI/CD и не применять манифесты при провале. Вариант 2: добавить ещё одну политику, проверяющую наличие аттестации SBOM (для продвинутых сценариев можно использовать Kyverno attestations или OPA с внешним валидатором). На первом этапе достаточно «красного светофора» в пайплайне и дашборда, показывающего статус SBOM/скана для каждого релиза.

Шаг 7. Уменьшите площадь атаки образа

• Используйте минимальные базовые образы (distroless, alpine c оговорками, ubuntu-minimal).
• Сбрасывайте права: USER nonroot, root‑файлы только там, где нужно.
• Multi‑stage сборка: всё, что нужно для компиляции, не попадает в финальный образ.

Примеры готовых конфигураций

Dockerfile (минимальный, многоступенчатый)

# этап сборки
FROM golang:1.22 as builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o /bin/app ./cmd/app

# финальный образ без лишнего
FROM gcr.io/distroless/base-debian12
USER 65532:65532
COPY --from=builder /bin/app /app
EXPOSE 8080
ENTRYPOINT ["/app"]

Проверка подписи вручную перед деплоем

cosign verify ghcr.io/your-org/your-repo/app:sha-<commit> \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity "repo:your-org/your-repo:ref:refs/heads/main"

Сканирование образа локально Trivy

trivy image --severity CRITICAL,HIGH --exit-code 1 ghcr.io/your-org/your-repo/app:sha-<commit>

Метрики успеха и контроль качества

• Доля подписанных образов, попавших в окружение (цель: 100%).
• Доля релизов с прикреплённым SBOM (цель: 100%).
• Время реагирования на критичные CVE в зависимостях (цель: часы, а не дни).
• MTTR уязвимости: от обнаружения до закрытия PR с обновлением зависимости.
• Количество отклонённых деплоев политикой (по месяцам). Рост в начале — норма, затем стабилизация.
• Время на аудит/сертификацию: сокращается за счёт прозрачно подтверждённого происхождения артефактов.

Частые ошибки и как их избежать

• Подписывают только latest. Нужны неизменяемые теги с digest (sha-…) и проверка именно по digest.
• Хранят приватные ключи подписи в репозитории. Лучше keyless через OIDC или аппаратные хранилища ключей.
• Нет отметки времени подписи. Используйте встроенную в cosign верификацию сертификата OIDC; для ключевых сценариев — timestamper.
• Политика слишком строгая с первого дня: блокирует всё. Внедряйте поэтапно: сначала Audit, затем Enforce по namespace’ам.
• SBOM есть, но его никто не читает. Включите автоматические «красные флаги» из сканера и отчёты в Slack/почту.
• Игнорируют базовые образы. Обновляйте их регулярно, иначе уязвимости будут возвращаться при каждом релизе.

Стоимость и окупаемость

• Инструменты с открытым исходным кодом (cosign, syft, trivy, kyverno) бесплатны. Затраты — человеко‑часы и, возможно, платные раннеры CI.
• Прямые затраты на внедрение: 1–2 недели инженера DevOps/платформенной команды.
• Выгода: снижение вероятности крупного инцидента, ускорение аудитов, упрощение соответствия требованиям (например, регуляторы и корпоративные клиенты часто требуют SBOM и доказуемое происхождение артефактов).
• Побочный бонус: дисциплина зависимостей и чистые образы уменьшают размер контейнеров и ускоряют доставку.

Грубая оценка: если инцидент обходится бизнесу в N млн, а вероятность снижается хотя бы на десятки процентов, окупаемость наступает после первого «несостоявшегося» инцидента. Плюс репутационный эффект и ускорение продаж в enterprise‑сегменте.

Чек‑лист для запуска

• Везде есть lock‑файлы зависимостей; сборка использует их строго.
• Контейнеры собираются многоступенчато; финальный образ минимален и запускается без root.
• Пайплайн CI публикует образы с неизменяемыми тегами (sha‑коммит).
• Образы подписываются cosign (keyless через OIDC или ключом из KMS).
• Генерируется SBOM (SPDX/CycloneDX) и прикрепляется к образу (attestation).
• Сканирование уязвимостей в CI: CRITICAL/HIGH блокируют релиз.
• В кластере включён Kyverno; политика запрещает неподписанные образы.
• Мониторинг метрик: покрытие подписью/SBOM, время реакции на CVE.
• Процедура регулярного обновления базовых образов и зависимостей.

Итог

Небольшой набор практик — подпись образов, SBOM и проверка на деплое — даёт бизнесу контролируемые релизы и предсказуемые риски. Это не «мода», а базовая гигиена поставки ПО. Внедрить можно поэтапно, не ломая процессы и не тормозя time‑to‑market: начните с одной команды и одного кластера — и за пару недель получите измеримый результат.