Атаки на цепочку поставок в ВКР: от кейсов 2025 года к защищаемой архитектуре
Материал, который вы читаете, — не просто дайджест инцидентов. Это фактически готовое сырьё для аналитической главы вашего диплома. За 2025 год произошло минимум восемь крупных атак на цепочку поставок: компрометация npm-пакетов с суммарным охватом в 2,6 млрд загрузок в неделю, червь Shai-Hulud, сливший около 400 000 секретов разработчиков, и кража $1,5 млрд у Bybit через подмену прошивки холодного кошелька. Для выпускника ИТ-направления это означает одно: тема «безопасность цепочки поставок» перестала быть абстракцией из ISO 27001 и превратилась в измеримую инженерную задачу с реальными метриками, логами и открытыми источниками данных.
Три темы ВКР, которых хватит на защиту
Тема 1. «Разработка системы контроля целостности зависимостей на основе SBOM и SLSA»
Актуальность: инциденты с пакетами gluestack (июнь, 17 пакетов), chalk/debug (сентябрь, 2,6 млрд загрузок) и IndonesianFoods (ноябрь, 150 000 спам-пакетов) показали, что классического SCA уже недостаточно.
- Цель: спроектировать сервис, автоматически генерирующий SBOM и проверяющий артефакты на соответствие уровням SLSA.
- Задачи: анализ существующих форматов (CycloneDX, SPDX); построение интеграции с CI/CD; реализация проверки подписей Sigstore/cosign; оценка накладных расходов.
- Структура: Глава 1 — обзор атак 2024–2025 и стандартов; Глава 2 — архитектура сервиса и схемы интеграции в пайплайн; Глава 3 — нагрузочное тестирование, метрики задержек, расчёт экономии.
Тема 2. «Анализ самораспространяющихся зловредов в экосистеме npm и методы противодействия»
Актуальность: Shai-Hulud 2.0 (декабрь) и GlassWorm (октябрь) использовали украденные токены для автоматического распространения. Это принципиально новая модель угрозы, плохо покрытая в существующих методичках.
- Цель: построить имитационную модель распространения червя на графе зависимостей.
- Задачи: формализация графа зависимостей; выбор симулятора (NetworkX, Gephi); оценка скорости распространения при разных политиках 2FA; выработка рекомендаций.
- Структура: Глава 1 — классификация атак на цепочку поставок; Глава 2 — математическая модель и симуляция; Глава 3 — верификация на данных реального инцидента.
Тема 3. «Проектирование защищённого CI/CD-пайплайна с изоляцией секретов»
Актуальность: атаки s1ngularity (август) и tj-actions/changed-files (март) эксплуатировали ровно одну слабость — секреты, доступные вредоносному коду в момент сборки.
- Цель: реализовать референсный пайплайн с OIDC-аутентификацией и эфемерными токенами.
- Задачи: сравнение подходов (GitHub OIDC, HashiCorp Vault, короткоживущие токены); реализация PoC на выбранном стеке; пентест собственной конфигурации; документация.
- Структура: Глава 1 — угрозы и требования; Глава 2 — архитектура и диаграммы последовательностей; Глава 3 — результаты пентеста и экономическое обоснование.
Аналитическая глава: как превратить инцидент в обоснование выбора
Не пишите «атаки стали чаще» — это вода. Возьмите конкретный кейс из статьи и разложите его на атакуемую поверхность. Например, разбор tj-actions/changed-files даёт готовую матрицу угроз:
| Этап атаки | Слабость в архитектуре | Контрмера для ВКР | Стандарт |
|---|---|---|---|
| Угон PAT мейнтейнера | Долгоживущий токен без scope | OIDC + эфемерные токены | SLSA Level 3 |
| Публикация вредоносного действия | Отсутствие подписи артефактов | Sigstore, cosign | SLSA Level 2 |
| Чтение секретов сборки | Секреты доступны в env | Vault + динамические секреты | NIST SP 800-204D |
| Запись данных в публичные логи | Маскирование отключено | DLP на уровне runner | ISO/IEC 27001 A.12.3 |
Такая таблица закрывает сразу два требования комиссии: показывает понимание предметной области и даёт формальную привязку к стандартам.
Проектная часть: что рисовать и как обосновывать
Как минимум понадобятся три диаграммы: контекстная (C4 Level 1), диаграмма развёртывания и sequence-диаграмма обработки pull request с проверкой зависимостей. Обязательно отразите поток данных от реестра пакетов до вашего валидатора — это показывает, что вы умеете мыслить не только кодом, но и архитектурой.
Стек обосновывайте через сравнение, а не через «мне нравится Python»:
| Компонент | Вариант А | Вариант Б | Критерий выбора |
|---|---|---|---|
| Сканер SBOM | Syft | Trivy | Поддержка CycloneDX + скорость |
| Хранилище секретов | Vault | SOPS+age | Динамические секреты vs простота |
| Мониторинг | OpenTelemetry | Prometheus + Loki | Единый формат трейсов |
Тестирование и метрики: где брать цифры для защиты
Самая частая проблема — «нет данных для расчётов». Решение: тестируйте на открытых зеркалах npm (например, реестр содержит исторические версии пакетов с реальными метаданными). Метрики, которые уместно посчитать:
- MTTD (mean time to detect) компрометации пакета вашим валидатором — сравните с реальным временем Shai-Hulud (часы).
- Накладные расходы на пайплайн: добавленное время сборки после интеграции проверок. Цель — не более 15 %.
- RTO/RPO для сценария «токен утёк»: как быстро вы отзываете доступы.
- Покрытие графа зависимостей вашим анализатором — процент пакетов в транзитивном дереве.
Для сбора метрик используйте OpenTelemetry — это сейчас фактически отраслевой стандарт, упоминание в ВКР плюсует к актуальности.
Чему вы реально научитесь
- Формализовать угрозу по MITRE ATT&CK и NIST SSDF — навык, который HR ищут в вакансиях AppSec.
- Строить архитектурные схемы по C4 и описывать их согласно ГОСТ 34.602-89.
- Писать техническое задание на систему, которую вы сами же спроектировали.
- Обосновывать выбор стека через измеримые критерии, а не вкусовщину.
- Работать с реальными данными инцидентов из открытых источников.
- Путаница SCA и SBOM. SCA — это анализ уязвимостей, SBOM — формат описания состава. Их не подменяют друг другом и уж точно не пишут «SaaS-сканер SBOM». Определите каждое понятие в глоссарии.
- Отсутствие количественных метрик. Фраза «система повышает безопасность» защиту не выдержит. Нужны MTTD, накладные расходы, покрытие.
- Игнорирование ГОСТ. ТЗ оформляется по ГОСТ 34.602-89, схемы — по ГОСТ 19.701-90. Это не формальность, а первое, за что снимут балл.
Насколько сложно реализовать PoC за семестр?
Реально уложиться в 8–10 недель при 10–12 часах в неделю, если взять готовые библиотеки (syft, cosign, OpenTelemetry SDK) и не изобретать формат SBOM с нуля. Основные затраты времени — интеграция с CI, а не сам код проверки.
Обязательно ли писать действующий код?
Зависит от кафедры. Формально многие программы допускают «проектный» диплом без полноценного прототипа, но практика такова: наличие работающего PoC на защите почти всегда повышает оценку. Минимум — скрипт, демонстрирующий ключевой механизм.
Как оформлять UML-диаграммы?
Генерация через PlantUML или Mermaid удобнее, чем рисование в редакторах: диаграмма хранится в виде кода, легко правится, а код можно приложить к диплому. Экспорт в PNG/SVG вставляйте по ГОСТ 19.701-90.
Где брать тестовые данные?
Зеркала npm и PyPI содержат историю версий с метаданными. Публичные отчёты (BleepingComputer, Securelist, TheHackerNews) по инцидентам 2025 года дают количественные оценки — они честно цитируются в аналитической главе.
- ☑ Каждая задача из введения повторяется в выводах соответствующей главы.
- ☑ Все ссылки на источники оформлены по ГОСТ Р 7.0.5-2008.
- ☑ Названия сущностей (SBOM, SCA, SLSA) определены один раз и далее используются в одном написании.
- ☑ Есть минимум три иллюстрации: контекстная схема, диаграмма развёртывания, sequence.
- ☑ ТЗ оформлено по ГОСТ 34.602-89, схемы — по ГОСТ 19.701-90.
- ☑ Метрики в третьей главе связаны с критериями эффективности из первой.
- ☑ В списке литературы есть источники 2024–2025 годов, включая разобранные инциденты.
Источник: Самые примечательных атаки на цепочку поставок в 2025 году (опубликовано 2026-03-26)