Опубликовано: 07.10.2026 | Источник: Xakep.ru

Анализ supply chain атак для ВКР: защита CI/CD от компрометации сканеров уязвимостей

Поддомен: Cybersecurity / DevSecOps. Роль: специалист по информационной безопасности.

Введение: почему кейс Trivy — это ваша готовая «актуальность»

В марте 2026 года группировка TeamPCP использовала сканер уязвимостей Trivy как вектор атаки на цепочку поставок. Результат — по данным Mandiant, более 1000 заражённых облачных сред и сговор с вымогателями из Lapsus$ для монетизации украденных данных. Инструмент, который вы ставите в пайплайн, чтобы находить уязвимости, сам стал точкой входа. Для выпускника ИТ-направления это не просто новость: это конкретный, датированный и подтверждённый кейс, которым можно обосновать актуальность ВКР по защите артефактов сборки. И одновременно — напоминание: если вы в дипломе описываете CI/CD, но игнорируете SBOM, подписывание образов и политики допуска в кластер, комиссия справедливо спросит «а где защита?».

FAQ: что чаще всего спрашивают студенты по этой теме

Мне разрешат тему, если это «свежая» атака из новостей?

Да, и даже поощряют — если в главе 1 вы покажете анализ угрозы по MITRE ATT&CK (техники T1195 Supply Chain Compromise, T1552 Unsecured Credentials), а в главе 2 предложите контур защиты. Ссылка на первоисточник обязательна.

Где брать данные для исследования, если собственного кластера нет?

Разворачивайте локально: kind или minikube, репозиторий-«жертва» на GitHub, уязвимый образ (например, из проекта vulnerable-apps). Генерируйте метрики через OpenTelemetry и Prometheus. Это валидный стенд.

Какие метрики считать, чтобы доказать эффективность решения?

Время до обнаружения подменённого артефакта (MTTD), доля образов с валидной подписью, количество заблокированных admission-политик, процент сервисов, для которых сгенерирован SBOM. Связка с ISO/IEC 25010 (security, reliability).

Как оформить архитектурные схемы по нормоконтролю?

C4 (Context + Container) в главе 2, диаграмму последовательности UML — для потока «разработчик → CI → реестр → кластер». Подписи, рамки и экспликация по ГОСТ 19.701-90, приложения — по ГОСТ 34.601.

Три темы ВКР, которые «вырастают» из кейса Trivy

• Тема 1. Методика верификации артефактов CI/CD на основе подписей и SBOM

  Актуальность: компрометация Trivy доказала, что доверие к сборке нельзя строить только на антивирусе сканера.

  Цель: снизить вероятность запуска неподписанного артефакта в кластере.

  • Обзор атак на цепочку поставок (MITRE T1195).
  • Сравнение Sigstore/cosign, in-toto, SLSA-уровней.
  • Проектирование gate-политики (Kyverno / OPA Gatekeeper).
  • Стенд в kind + замер MTTD и доли заблокированных развёртываний.

• Тема 2. Контроль зависимостей и образов на основе SBOM (CycloneDX/SPDX)

  Актуальность: инфистилер TeamPCP распространялся через доверенный инструмент — значит, нужен инвентарь компонентов.

  Цель: построить пайплайн генерации и валидации SBOM с автоматическим отказом сборки.

  • Анализ форматов SBOM и практик обмена (NTIA, CISA).
  • Интеграция Syft + Grype + Trivy в GitHub Actions.
  • Контур политик: запрет критичных CVE и неподписанных баз.
  • Оценка покрытия и времени сборки по метрикам OpenTelemetry.

• Тема 3. Модель угроз для CI/CD-пайплайна облачного сервиса

  Актуальность: Lapsus$ монетизирует кражу секретов, а токены CI — приоритетная цель.

  Цель: разработать STRIDE-модель и оценить остаточный риск по OWASP CI/CD Top 10.

  • Каталог угроз и активов (токены, раннеры, реестры).
  • Проектирование сегментации раннеров и short-lived credentials.
  • Сравнение с ISO/IEC 27001:2022 (A.8.28, A.5.21).
  • Экспериментальная проверка на тестовом пайплайне.

Как встроить кейс Trivy в главы ВКР

Глава 1. Аналитика: разбираем атаку по тактикам

Возьмите цепочку «компрометация обновления сканера → выполнение полезной нагрузки на раннере → выдача токенов → доступ к облаку». Нанесите её на модель kill chain и сопоставьте с техниками MITRE ATT&CK. Здесь же — сравнительная таблица реальных инцидентов (SolarWinds, xz-utils, Trivy) по столбцам: вектор, время обнаружения, ущерб, применённые контрмеры. Всё это ложится в подраздел «Анализ угроз» и закрывает требование новизны.

Глава 2. Проектирование: подпись и политика допуска

Ниже — минимальный рабочий пример верификации образа в GitHub Actions. Он ложится в листинг главы 2 как реализация «точки контроля подписи».

# .github/workflows/verify.yml
- name: Verify signed image
  run: |
    cosign verify \
      --certificate-identity-regexp '^https://github.com/org/repo/' \
      --certificate-oidc-issuer https://token.actions.githubusercontent.com \
      ghcr.io/org/app:${{ github.sha }}

- name: Generate SBOM
  run: syft ghcr.io/org/app:${{ github.sha }} -o cyclonedx-json > sbom.json

Далее — Kyverno-политика, которая отклоняет любой Pod с образом без валидной подписи cosign. Это конкретный архитектурный элемент, который на защите вы покажете как «защиту на этапе runtime».

Глава 3. Эксперимент: метрики и сравнение

Соберите стенд из двух контуров — до внедрения политик и после. Замерьте: долю успешных «инъекций» подменённого образа, MTTD, оверхед на время сборки. Оформите как графики в приложениях и таблицу «baseline vs hardened» с привязкой к ISO/IEC 25010.

Диаграммы, которые ожидает комиссия

C4 Level 2 (контейнеры: Git, CI-раннер, реестр, кластер, admission-контроллер), sequence для потока верификации и BPMN-схему пайплайна с точками отказов. Схемы подпишите, разместите в главе 2, детали — в приложение.

Чему вы научитесь в процессе

• Строить модель угроз для CI/CD по OWASP и STRIDE.
• Настраивать подпись артефактов через Sigstore/cosign и SLSA-уровни.
• Генерировать и валидировать SBOM (CycloneDX/SPDX) в пайплайне.
• Проектировать admission-политики в Kubernetes и измерять их эффект.
• Оформлять результаты эксперимента в терминах измеримых метрик, а не «стало безопаснее».

Источник: Из-за атаки на цепочку поставок Trivy заражено более 1000 облачных сред (опубликовано 2026-03-27)