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

Атаки на цепочку поставок в дипломе: проектируем защищённый CI/CD-пайплайн

В марте 2026 года группировка TeamPCP провернула классическую, но от этого не менее болезненную атаку на цепочку поставок. Скомпрометированы Docker-образы сканера Trivy, дефейснуты внутренние репозитории Aqua Security, затем атака дошла до GitHub Actions компании Checkmarx и до библиотеки LiteLLM в PyPI. Обратите внимание на вектор: злоумышленник не ломал продукт напрямую — он вошёл через доверенный инструмент, который сам разработчик добровольно запускает в своём конвейере сборки.

Для выпускника ИТ-направления это не новость из мира больших корпораций, а готовая тема ВКР. Любой дипломный проект, где есть requirements.txt, Dockerfile и хотя бы один workflow в GitHub Actions, уже воспроизводит ту же архитектуру риска в миниатюре. Защитить такую работу проще, чем кажется: у темы есть измеримые метрики, понятная угроза и признанные стандарты — от NIST SSDF до ГОСТ Р 56939-2016.

Семантический разбор: что именно мы берём в работу

Три темы ВКР, которые вырастают из этой новости

Тема 1. Методика защиты CI/CD-пайплайна от компрометации сторонних зависимостей

Актуальность. Кейс Trivy → Checkmarx → LiteLLM показывает, что сканер уязвимостей сам стал вектором атаки. Классическая схема «поставили SCA-инструмент и успокоились» больше не работает.

Цель: разработать и обосновать методику контроля целостности артефактов на всех этапах конвейера сборки.

Задачи:

• проанализировать существующие модели угроз для цепочки поставок (NIST SSDF, SLSA);
• спроектировать схему подписи образов через Sigstore/cosign с привязкой к OIDC-идентичности;
• реализовать прототип пайплайна с генерацией SBOM и проверкой подписей перед деплоем;
• оценить накладные расходы и сформулировать рекомендации по внедрению.

Структура: Глава 1 — анализ угроз и обзор стандартов; Глава 2 — проектирование защищённого конвейера и схемы взаимодействия компонентов; Глава 3 — экспериментальная проверка, метрики, экономика внедрения.

Тема 2. Автоматизированный контроль политик безопасности в Kubernetes на основе SBOM

Актуальность. Даже легитимный образ, попавший в реестр из скомпрометированного источника, должен быть отсечён на входе в кластер — это ровно тот сценарий, который разворачивался вокруг Docker-образов Trivy.

Цель: спроектировать admission-контроллер, отклоняющий развёртывание компонентов с неподтверждённым происхождением.

Задачи:

• сравнить Kyverno, OPA Gatekeeper и встроенные механизмы Kubernetes;
• определить набор политик: подпись образа, наличие актуального SBOM, отсутствие критичных CVE;
• реализовать контроллер и интеграцию с реестром;
• провести нагрузочное тестирование на задержку admitted-запросов.

Структура: Глава 1 — обзор политик-движков и модели угроз; Глава 2 — архитектура решения и диаграммы последовательности; Глава 3 — тесты, замер latency, расчёт трудозатрат на сопровождение.

Тема 3. Мониторинг аномалий в конвейере сборки на базе OpenTelemetry

Актуальность. Дефейс внутренних репозиториев Aqua Security заметили не сразу — детекция постфактум. Значит, нужен наблюдаемый пайплайн, а не разрозненные логи.

Цель: построить систему сбора телеметрии CI/CD и выявления отклонений от нормального профиля сборок.

Задачи:

• определить набор метрик (длительность шагов, источники зависимостей, сетевые обращения сборщика);
• настроить экспорт через OpenTelemetry Collector в хранилище метрик;
• сформулировать правила алертинга и пороговые значения;
• проверить работу на смоделированной аномалии.

Структура: Глава 1 — теория наблюдаемости и метрики по ISO/IEC 25010; Глава 2 — архитектура сбора и хранения телеметрии; Глава 3 — эксперимент, точность детекции, ложноположительные срабатывания.

Аналитическая глава: чем наполнять сравнения

Первая глава — место, где большинство работ скатывается в пересказ википедии. Сделайте иначе: привяжите каждый абзац к конкретной угрозе из кейса. Trivy скомпрометирован — значит, в таблице сравнения SCA-инструментов должен быть столбец «модель поставки самого инструмента: реестр, подпись, доверие к мейнтейнеру». Зависимость LiteLLM отравлена в PyPI — значит, отдельный пункт про политику источников пакетов и mirror-репозитории.

Проектная часть: схемы, которые ждёт комиссия

Здесь кейс даёт готовый каркас для «Главы 2». Минимальный набор диаграмм: контекстная схема пайплайна (коммит → сборка → сканирование → подпись → публикация → деплой), диаграмма последовательности проверки подписи при admission-запросе, и схема потоков данных телеметрии. Каждую стрелку подкрепляйте ссылкой на прецедент: «данный шаг предотвращает сценарий подмены образа, реализованный в атаке TeamPCP».

Если пишете про подпись артефактов, уместно показать фрагмент конфигурации. Такой минимум демонстрирует, что вы понимаете механику, а не только терминологию:

permissions:
  id-token: write      # OIDC вместо статичного PAT
  contents: read

steps:
  - uses: sigstore/cosign-installer@v3
  - run: cosign sign --yes ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
  - run: cosign verify --certificate-oidc-issuer https://token.actions.githubusercontent.com --certificate-identity-regexp "team" ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}

Обратите внимание: привязка подписи к OIDC-идентичности напрямую закрывает класс атак, где злоумышленник получает доступ к долгоживущему секрету CI-системы. Это сильный аргумент в разделе обоснования стека — не «так модно», а «это ликвидирует конкретный вектор».

Тестирование и метрики: где брать цифры

Самая частая претензия на защите — «где доказательства, что стало лучше». Метрики для этой темы добываются дешево и выглядят убедительно.

• Время сборки до и после добавления сканирования и подписи — рост на 15–40% это нормальный, честно объяснённый компромисс.
• Задержка admission-контроллера — перцентили p50 и p95 при 10, 50, 200 одновременных запросах.
• Полнота детекции — на смоделированном сценарии с отравленной зависимостью система должна заблокировать деплой; считайте долю обнаружений и ложных срабатываний.
• RTO/RPO при откате скомпрометированного релиза — реальные минуты, замеренные на стенде, а не из головы.

Стенд можно поднять полностью локально: kind или minikube, приватный реестр, локальный PyPI-прокси. Это снимает вопрос «а у нас не было доступа к промышленной среде».

Чему вы научитесь на такой теме

• читать стандарты NIST SSDF и ГОСТ Р 56939-2016 и превращать их пункты в требования к системе;
• проектировать модель угроз и связывать каждый технический контрмер с конкретным сценарием атаки;
• работать с Sigstore, SBOM-генераторами, движками политик и OpenTelemetry на уровне конфигурации, а не презентации;
• обосновывать выбор технологий через измеримые критерии — время, надёжность, стоимость сопровождения;
• оформлять ТЗ и проектную документацию по ГОСТ 34.602-89 без переписывания шаблона.

FAQ по теме

Насколько сложно реализовать такую систему в рамках диплома?

Прототип на 3–4 недели: локальный кластер, один сервис, один пайплайн, одна политика admission. Полноценная промышленная платформа не нужна — комиссия оценивает обоснованность решений, а не масштаб.

Обязательно ли писать код?

Да, но это преимущественно конфигурация: YAML пайплайна, манифесты Kubernetes, политики. Объём собственного кода небольшой, а вот объём обоснований — значительный.

Как оформить диаграммы?

Контекстную схему — в нотации C4 или IDEF0, взаимодействие компонентов — UML-диаграммой последовательности. Главное, чтобы каждая диаграмма упоминалась в тексте и обслуживала конкретный вывод.

Где взять данные для эксперимента?

Смоделируйте отравленный пакет в локальном прокси-репозитории либо используйте публичные датасеты уязвимостей. Легально, воспроизводимо и не требует разрешений от инфраструктурной команды.

Источник: Атака на сканер Trivy привела к взлому Checkmarx и LiteLLM (опубликовано 2026-03-25)