Анализ атак на цепочку поставок для ВКР: защита репозиториев от компрометации
Мартовская новость всколыхнула ИБ-сообщество: исследователи Aikido, Socket, Step Security и OpenSourceMalware обнаружили 433 скомпрометированных компонента GlassWorm — от GitHub-репозиториев до расширений для VS Code. Для студента это не просто сводка инцидентов, а готовая исследовательская база. На таком кейсе можно построить дипломную работу уровня «хорошо» и «отлично»: он свежий, конкретный и требует практической проработки. Разберём, как превратить статью о GlassWorm в полноценное исследование, какие темы выбрать, как оформить главы и защититься перед комиссией без скучных фраз «актуальность обусловлена...».
Как статья GlassWorm превращается в главы ВКР
Начнём с главного: статью нельзя просто вставить в диплом как «обзор литературы». Её нужно переработать в объект исследования и предложить архитектуру решения. Ниже — три темы ВКР, которые органично используют кейс GlassWorm и выводят на защищаемый результат.
| Тема ВКР | Актуальность | Цель | Задачи | Структура |
|---|---|---|---|---|
| 1. Методика обнаружения скомпрометированных компонентов в цепочке поставок ПО | Атака GlassWorm показала: вредоносные пакеты могут находиться в публичных реестрах месяцами и маскироваться под полезные библиотеки. | Разработать методику выявления подозрительных компонентов на основе анализа поведения и метаданных пакетов. | 1) Классифицировать векторы атаки GlassWorm; 2) Сравнить существующие инструменты; 3) Разработать алгоритм детектирования; 4) Оценить точность и полноту. | Гл.1 — анализ угроз и существующих подходов; Гл.2 — проектирование алгоритма; Гл.3 — эксперимент и метрики. |
| 2. Система мониторинга целостности артефактов в CI/CD с применением SBOM | GlassWorm скомпрометировал репозитории и расширения через подмену компонентов. SBOM (Software Bill of Materials) позволяет отслеживать состав каждого артефакта и вовремя замечать изменения. | Спроектировать конвейер автоматических проверок SBOM в CI/CD. | 1) Изучить структуру SBOM и стандарты CycloneDX/SPDX; 2) Настроить генерацию SBOM в GitHub Actions; 3) Интегрировать сканер уязвимостей; 4) проверить работу на модели атаки GlassWorm. | Гл.1 — теория цепочек поставок и форматов SBOM; Гл.2 — реализация конвейера; Гл.3 — тестирование и эффективность. |
| 3. Модель защищённой публикации расширений для VS Code | GlassWorm затронул Open VSX и расширения, которыми пользуются миллионы разработчиков. Проблема доверия к расширениям до сих пор не решена полностью. | Разработать модель безопасной публикации и верификации расширений, снижающую риск компрометации. | 1) Проанализировать схему атаки на расширения; 2) Сформировать требования безопасности; 3) Спроектировать архитектуру подписывания и проверки; 4) Реализовать прототип. | Гл.1 — обзор угроз и стандартов безопасности; Гл.2 — моделирование и проектирование; Гл.3 — внедрение и оценка. |
Что брать из статьи для главы 1 и главы 2
Глава 1 (анализ). Опишите инцидент как типовую модель атаки на цепочку поставок: злоумышленник получает доступ к репозиторию, публикует обновление с вредоносным кодом, пользователи автоматически скачивают его. Постройте диаграмму прецедентов UML (акторы: разработчик, пакетный менеджер, конечный пользователь) или C4-контекстную схему, где показано, как компоненты взаимодействуют и где именно целесообразно ставить систему защиты.
Глава 2 (проектирование). Предложите решение: например, пайплайн анализа зависимостей с генерацией SBOM и проверкой по базам известных уязвимостей и вредоносных сигнатур. Для этого потребуется настроить CI/CD — вот пример конфигурации GitHub Actions для генерации SBOM и сканирования:
name: sbom-check
on: [push, pull_request]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Generate SBOM
run: |
pip install cyclonedx-bom
cyclonedx-py -e -o sbom.json
- name: Run OSV-Scanner
run: |
osv-scanner --sbom sbom.json
- name: Run Socket CLI
run: |
npx @socketsecurity/cli sbom
Такой код показывает членам комиссии, что вы умеете применять современные инструменты, а не только теоретические модели.
Метрики и инструменты для подтверждения эффективности
Комиссия почти всегда задаёт вопрос: «А почему ваше решение лучше?» Ответ нужно подкреплять цифрами. Используйте метрики, отражающие именно защиту цепочки поставок:
| Метрика | Что показывает | Как рассчитать | Инструменты |
|---|---|---|---|
| Precision (точность) | Доля верно обнаруженных вредоносных компонентов среди всех срабатываний | TP / (TP + FP) | Тестовая выборка из репозиториев с индикаторами GlassWorm |
| Recall (полнота) | Способность находить реальные угрозы | TP / (TP + FN) | Размеченный набор данных, созданный на основе утечек |
| MTTD (Mean Time to Detect) | Скорость реакции на новую вредоносную публикацию | Среднее время от публикации до детектирования | Журналы CI/CD, архивы реестров |
| Покрытие зависимостей | Доля проанализированных компонентов в SBOM | Проанализированные / общее число зависимостей | CycloneDX, Trivy, OWASP Dependency-Check |
Эксперимент можно провести на собственном учебном проекте: симулируйте внедрение «подозрительного» пакета и замерьте время детектирования и полноту.
Чему вы научитесь: практические навыки для защиты
Помимо текста ВКР, вы прокачаете конкретные компетенции, которые легко показать в докладе:
- анализировать цепочку поставок и строить модели угроз;
- генерировать SBOM в форматах CycloneDX и SPDX;
- автоматизировать проверки зависимостей в GitHub Actions;
- обосновывать эффективность через метрики Precision, Recall, MTTD;
- оформлять результаты по ГОСТ 19 и ГОСТ 34 — это закроет нормоконтроль.
FAQ — частые вопросы студентов
Какую тему ВКР по этой статье выбрать, чтобы защититься без вопросов?
Лучше всего работает тема с очевидной прикладной частью: «Разработка методики обнаружения» или «Модель защищённой публикации». Не берите общий обзор «Кибербезопасность в современном мире» — это провал на защите. Конкретный алгоритм, код и метрики дают комиссии повод поставить «отлично».
Где брать данные для анализа, если статья одна?
Используйте официальные отчёты OpenSourceMalware, публичные индикаторы компрометации из GitHub Advisory Database, базы npm-пакетов. Можно собрать собственную выборку из NPM и Open VSX, проверив их по множеству антивирусных движков через VirusTotal API.
Как написать ВКР по кибербезопасности, чтобы пройти нормоконтроль?
Следуйте ГОСТ 7.32-2017 для структуры, ГОСТ 19.402 для описания программы (если есть код), упоминайте ISO/IEC 25010 для оценки качества. Сверяйте названия глав с целями и задачами — это типичная ошибка, из-за которой работа отправляют на доработку.
Можно ли заказать диплом, если не успеваю к дедлайну?
Если сроки действительно горят, можно заказать диплом у исполнителей. Но честный подход — использовать такую помощь точечно: например, консультацию по методологии или проверку расчётов. Так вы сохраните понимание темы и сможете уверенно отвечать на защите.
- Названия глав точно соответствуют цели и задачам — проверьте на перекрёстное соответствие.
- Хотя бы одна диаграмма (UML, C4, BPMN) описывает процесс вашей защиты цепочки поставок.
- Есть скриншот или лог работы созданного инструмента — без этого практическая часть слабая.
- Посчитаны метрики: точность, полнота, время детекции.
- Ссылки на источники оформлены по ГОСТ 7.0.100-2018.
- Каждый негативный вывод сопровождается объяснением, а каждый положительный — результатом эксперимента.
- Приложение содержит код, SBOM-файл и снимок интерфейса или CI-пайплайна.
- Копирование статьи в главу «Обзор литературы». Пересказывать новость — не исследование. Нужно выделить тактики, построить классификацию, сравнить с другими атаками (SolarWinds, event-stream).
- Размытая тема. «Защита веб-приложений» — могила для ВКР. Пусть тема будет узкой: «Обнаружение вредоносных npm-пакетов на основе анализа метаданных».
- Нет оценки эффективности. Если вы написали систему, но не показали, сколько реальных вредоносных пакетов она находит, комиссия сочтёт работу бесполезной. Обязательно считайте Precision/Recall даже на маленькой выборке.
Источник: GlassWorm скомпрометировал более 400 репозиториев и расширений на GitHub, npm и Open VSX (опубликовано 2026-03-19)
```