Опубликовано: 03.10.2026 | Источник: SecurityLab (RSS)

Безопасность CI/CD-пайплайнов в дипломе: от разбора атаки на GitHub Actions до собственной системы защиты

В марте 2026 года атака на GitHub Action от Checkmarx за четыре часа заразила 35 тегов и разошлась по десяткам open-source проектов. Инструмент, который проектировался для защиты инфраструктуры, сам стал точкой входа. Звучит как сюжет для триллера, но для выпускника ИТ-специальности это идеальный кейс: он одновременно свежий, воспроизводимый и попадает в десяток валидных тем ВКР. Если вы выбираете направление «Информационная безопасность», «DevOps» или «Программная инженерия» — supply chain атаки сегодня это тот же уровень обязательной темы, каким в 2015-м были SQL-инъекции. Ниже — рабочие сценарии, как превратить новость из ленты в защищаемую главу диплома, какие метрики считать и где чаще всего валятся студенты.

Частые вопросы перед началом

Три темы ВКР, которые сейчас смотрятся выигрышно

• Тема 1. Обнаружение supply chain-атак в CI/CD на основе SBOM и поведенческого анализа раннеров.
  Актуальность: напрямую опирается на инцидент Checkmarx — теги подменили, а потребители узнали об этом через часы.
  Цель: разработать модуль, который фиксирует дрейф зависимостей и блокирует сборку при отклонении.
  Задачи: 1) систематизировать классы атак; 2) спроектировать архитектуру модуля; 3) реализовать прототип на Python + GitHub API; 4) оценить MTTD и число ложных срабатываний.
  Структура: Гл.1 — анализ угроз и обзор решений (SLSA, Sigstore, Syft/Grype). Гл.2 — проектирование, диаграмма C4 и модель STRIDE. Гл.3 — эксперимент на 30 репозиториях, метрики, выводы.
• Тема 2. Методика оценки защищённости конвейеров по OWASP Top 10 CI/CD Security Risks.
  Актуальность: единого «чек-листа» для pipeline-инженеров до сих пор нет, а инциденты идут волнами.
  Цель: формализовать чек-лист и автоматизировать его применение к репозиторию.
  Задачи: 1) сопоставить риски OWASP с классами атак; 2) построить матрицу «риск — контроль — метрика»; 3) реализовать CLI-аудит на базе OPA/Rego; 4) валидировать на открытых проектах.
  Структура: Гл.1 — стандарты и Best Practices. Гл.2 — проектирование правил политики. Гл.3 — прогон на выборке, отчёт по ложным срабатываниям.
• Тема 3. Защита CD-конвейера от подмены действий (actions) с помощью pinning и provenance-аттестации.
  Актуальность: повальная практика `uses: actions/checkout@v4` — ровно та дыра, через которую прошла атака Checkmarx.
  Цель: спроектировать и обкатать пайплайн с обязательным Zcheck по SHA и проверкой SLSA-provenance.
  Задачи: 1) анализ существующих схем аттестации; 2) проектирование защищённого workflow; 3) интеграция проверки provenance через Cosign; 4) сравнение времени сборки до/после.
  Структура: Гл.1 — угрозы цепочки поставок. Гл.2 — конфигурация workflow и политика. Гл.3 — эксперимент, метрики накладных расходов.

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

Глава 1. Разбор инцидента как аналитический материал

Не пересказывайте новость — декомпозируйте её. Постройте DFD: внешний актор (атакующий) → процесс (CI-раннер) → хранилище (реестр артефактов). Отметьте границы доверия и покажите, что в исходном кейсе они размыты: action подписан владельцем тега, но потребитель не проверяет provenance. Затем наложите STRIDE-модель: подмена (Tampering), повышение привилегий (Elevation), отказ (DoS-обновление до заражённого тега). Это даст естественный переход к формулировке задач.

Глава 2. Проектирование защищённого конвейера

Здесь уместны диаграмма C4 Level 2 (контейнеры: runner, secrets store, registry, policy engine) и таблица мер. Покажите «до/после» в одной картинке — комиссия оценит. Минимальный набор контролей:

name: secure-build
on: [push, pull_request]
permissions:
  contents: read      # принцип наименьших привилегий
  id-token: write     # для OIDC к облаку

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # 1. Пиннинг по SHA, не по тегу — тег можно перезаписать
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11  # v4.1.1
      # 2. Сканирование зависимостей до сборки
      - run: pip install pip-audit && pip-audit -r requirements.txt --strict
      # 3. Генерация SBOM и загрузка артефакта
      - uses: anchore/sbom-action@e11c54d47a4e2f6a5e8f1a4c7d3ef9b0d5e6c2a1
        with:
          format: spdx-json
      # 4. Подпись артефакта и публикация provenance
      - uses: sigstore/cosign-installer@11086d25041f77fe8fe7b9ea4e48e3b9192b8f19
      - run: cosign sign-blob --yes dist/app.tar.gz > dist/app.sig

Каждый блок — это подраздел главы 2. Не забудьте обосновать, почему выбран SBOM формата SPDX, а не CycloneDX, и почему Cosign, а не in-toto напрямую.

Глава 3. Метрики и эксперимент

Защита без чисел на защите ВКР не принимается. Сведите результаты в таблицу и приложите формулы. Пример метрик, которые считаются руками за один вечер:

Такую таблицу комиссия проверяет быстрее, чем 30 страниц текста. И да, MTTD в 240 минут взят не с потолка — это как раз «четыре часа» из инцидента Checkmarx.

Оформление схем и нормоконтроль

Схемы архитектуры — по ГОСТ 34.601-90 (стадии) или ГОСТ 19.701-90 (ЕСПД, если оформляете как программный документ). Диаграммы — C4 или UML 2.5, подписи обязательны на русском, легенда — в углу кадра. ISO/IEC 25010 пригодится, если обосновываете нефункциональные требования (security, reliability). OWASP CI/CD Top 10 — прямой источник для первой главы.

Источник: 35 заражённых тегов за четыре часа. Атака на GitHub Action от Checkmarx затронула десятки проектов по всему миру (опубликовано 2026-03-26)