Опубликовано: 21.09.2026 | Источник: Kaspersky Daily

Безопасность цепочки поставок в ВКР: троянизация Trivy, Checkmarx и LiteLLM как кейс для диплома

Введение: почему атака TeamPCP — идеальный материал для диплома по ИБ

19 марта 2026 года группировка TeamPCP провернула то, чего десятилетиями опасались архитекторы безопасных конвейеров: они внедрили вредоносный код прямо в подписанные релизы Trivy и GitHub Actions. Каждый запуск сканера в CI/CD превращался в кражу SSH-ключей, облачных токенов и криптокошельков. Через несколько дней аналогичная участь постигла Checkmarx KICS и LiteLLM AI Gateway на PyPI — под видом версий 1.82.7 и 1.82.8.

Для выпускника ИТ-направления это не просто новость из мира ИБ. Это готовый полигон для ВКР: живой инцидент с идентификатором CVE-2026-33634, публичной хронологией, доменами эксфильтрации (scan.aquasecurtiy[.]org, checkmarx[.]zone, models.litellm[.]cloud) и понятными мерами противодействия. Если вы ищете тему, где теория мгновенно превращается в практику, — вы по адресу.

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

Можно ли взять одну статью и растянуть её на всю ВКР?

Нет, и это первая ошибка. Инцидент TeamPCP — это кейс, а не источник теории. Он отлично ложится в главу 1 как «Анализ актуальных угроз» и в главу 3 как «Валидация предложенных мер на реальном сценарии». Но каркас работы должен строиться на OWASP CI/CD Top 10, SLSA-уровнях и требованиях ГОСТ 34.601-90 к стадиям разработки.

Где брать статистику и первоисточники, кроме блога Касперского?

Ориентируйтесь на три типа источников: (1) официальные advisory — NVD, GitHub Security Advisories, Aqua Security discussion 10425; (2) отчёты вендоров — Sysdig, Aikido, StepSecurity (по червю CanisterWorm); (3) нормативные документы — NIST SP 800-218 (SSDF), OWASP Top 10 CI/CD Security Risks. Минимум 25 источников, из них 8+ — peer-reviewed или нормативные.

Как считать эффективность предлагаемых мер защиты?

Через измеримые метрики, а не «стало безопаснее». Классический набор: MTTR (mean time to remediate), доля зависимостей с pinning по SHA-хешу, процент workflow с OIDC вместо PAT, количество сработавших зизморов на 100 репозиториев, покрытие SBOM. В главе 3 покажите замеры «до/после» внедрения — с таблицами и графиками.

Нужно ли писать собственный сканер или достатчно конфигурации?

Достаточно конфигурации + обёртки. Тема ВКР по DevSecOps не требует изобретения нового сканера — она требует архитектуры безопасного пайплайна. C4-диаграмма, threat-модель по STRIDE, набор policy-as-code (например, на OPA/Conftest) и демонстрация отказа пайплайна при нарушении политики — этого хватит с запасом.

Три темы ВКР, которые защитить проще всего

• Тема 1. Разработка методики защиты CI/CD-конвейеров от атак на цепочку поставок

  Актуальность: 20 000+ репозиториев потенциально уязвимы по данным TeamPCP, а подписанные артефакты Trivy обошли сигнатурные проверки.

  Цель: снизить вероятность компрометации через доверенные build-инструменты.

  Задачи: классифицировать векторы атак на CI/CD; спроектировать эталонный защищённый пайплайн; реализовать policy-as-code; оценить метрики до/после.

  Структура: Гл.1 — анализ OWASP CI/CD Top 10 и кейса TeamPCP. Гл.2 — проектирование архитектуры (C4 + STRIDE). Гл.3 — реализация и замеры MTTR/coverage.

• Тема 2. Построение системы управления секретами в Kubernetes-кластере средствами OIDC и Vault

  Актуальность: вредонос из статьи читал /proc/*/mem и /run/secrets/kubernetes.io/serviceaccount в раннерах GitHub Actions.

  Цель: исключить долгоживущие секреты и минимизировать их инъекцию в окружение.

  Задачи: провести инвентаризацию секретов; интегрировать OIDC-провайдер с Vault; реализовать Kubernetes ServiceAccount Token Volume Projection; настроить ротацию; замерить окно жизни секрета.

  Структура: Гл.1 — обзор моделей секретов (ISO/IEC 27001, NIST SSDF). Гл.2 — архитектура Vault + OIDC. Гл.3 — тесты на проникновение и метрики TTL.

• Тема 3. Анализ и предотвращение атак через GitHub Actions: инструментальный подход

  Актуальность: атакующие перезаписали 76 из 77 тегов в aquasecurity/trivy-action и все 7 в setup-trivy без изменения метаданных.

  Цель: разработать регламент и инструментальную проверку pinning по SHA.

  Задачи: сравнить zizmor, gato/Gato-X и allstar; разработать чек-лист аудита workflow; автоматизировать проверку в pre-commit; описать реакцию на инцидент.

  Структура: Гл.1 — анализ тактик Shai-Hulud 2.0 и TeamPCP. Гл.2 — интеграция анализаторов в пайплайн. Гл.3 — оценка ложноположительных срабатываний.

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

Глава 1: теоретическая база через призму инцидента

Не пересказывайте статью — используйте её как иллюстрацию каждой теоретической модели. Например, разбирая OWASP CI/CD Top 10 (риск CICD-SEC-3: Dependency Chain Abuse), сразу покажите кейс LiteLLM 1.82.7/1.82.8. Разбирая NIST SSDF практику PS.1 «Protect All Forms of Code», приведите пример перезаписи тегов trivy-action. Такой подход демонстрирует комиссии умение связывать теорию с реальностью.

Схемы для первой главы: диаграмма последовательности UML — путь от коммита в upstream до эксфильтрации учётных данных; таблица соответствия «тактика ATT&CK → артефакт инцидента → контроль из ISO/IEC 27001».

Глава 2: проектирование защитной архитектуры

Здесь основной вес — на C4-диаграммы (контекст, контейнеры, компоненты) и BPMN-схему реагирования. Опишите пилотный контур: GitHub Enterprise → workflow validator → policy engine (OPA/Conftest) → SIEM с приёмом событий через OpenTelemetry. Отдельно опишите архитектуру threat-hunting на домены эксфильтрации — без этого статьи не хватит.

# Пример policy-as-code: запрет workflow без pinning по SHA
package github.workflow

deny[msg] {
    step := input.steps[_]
    uses := step.uses
    not re_match(`^[^@]+@[0-9a-f]{40}$`, uses)
    msg := sprintf("Шаг %s не закреплён по SHA-хешу", [uses])
}

deny[msg] {
    input.permissions.contents == "write"
    msg := "contents: write без обоснования — нарушение принципа наименьших привилегий"
}

Обязательно покажите, как этот policy встраивается в pre-commit hook и в required check на GitHub branch protection.

Глава 3: реализация и измерение эффективности

Разделите эксперимент на три сценария: (1) baseline без защит — воспроизведение атаки через подменённый tag; (2) с pinning по SHA — фиксируем блокировку; (3) с полным стеком (pinning + OIDC + policy engine + egress filter) — фиксируем блокировку на трёх уровнях. Для каждого — таблица метрик.

Кодирование — на Python (для парсеров workflow и статистики) или Go (для CLI-обёртки). Не забудьте про unit-тесты — их наличие добавляет баллов на защите.

Чему вы научитесь, пока будете это писать

• Строить threat-модели по STRIDE для CI/CD-конвейеров и облекать их в C4-диаграммы.
• Настраивать pinning зависимостей по криптографическим хешам и обосновывать это на защите через SLSA-уровни.
• Проектировать работу с короткоживущими секретами через OIDC и Kubernetes ServiceAccount Token Volume Projection.
• Считать метрики DevSecOps (MTTD, MTTR, secret TTL, coverage SBOM) и интерпретировать их для комиссии.
• Оформлять техническую документацию по ГОСТ 19.201-78 и ГОСТ 34.601-90, а также готовить SBOM в форматах SPDX/CycloneDX.

Источник: Троянизация решений Trivy, Checkmarx и LiteLLM | Блог Касперского (опубликовано 2026-03-25)