Supply chain атаки в ВКР по кибербезопасности: разбор CanisterWorm и защита облачной инфраструктуры
Статья KrebsOnSecurity рассказала, как группировка TeamPCP использовала цепочку поставок и незащищённые облачные контроль-плоскости: скомпрометировала официальный репозиторий Trivy на GitHub Actions, затем запустила червя CanisterWorm, который стирал данные при обнаружении иранской локали. Для студента ИТ-специальности это не просто новость, а полноценный учебный кейс: здесь есть и supply chain атака, и эксплуатация Docker/Kubernetes, и криминалистический анализ с временными метками. Такой материал позволяет сделать ВКР современной, практической и защищаемой. Ниже — как именно превратить этот инцидент в тему диплома, не скатываясь в пересказ статьи.
ВКР по следам CanisterWorm: три актуальных направления
Выбирать тему стоит не «по красивой картинке», а по возможности провести самостоятельное исследование и получить измеримые результаты. Статья об атаке TeamPCP легко разворачивается в три разные работы. Сведём их в таблицу, чтобы вы могли прикинуть объём и структуру.
| Параметр | Тема 1. Обнаружение wiper-атак в Kubernetes | Тема 2. Защита цепочки поставок ПО | Тема 3. Анализ угроз для неструктурированных облачных конфигураций |
|---|---|---|---|
| Актуальность | CanisterWorm уничтожает данные на каждом узле кластера. Штатные средства не всегда отличают массовое удаление от штатной очистки. | Инцидент с Trivy показал: атакующие внедряют код в официальные артефакты. Нужны методы верификации и контроля целостности. | TeamPCP промышленно сканирует Docker API, Redis, Kubernetes. Тема закрывает пробел между найденной уязвимостью и реальной компрометацией. |
| Цель ВКР | Разработать систему раннего детектирования признаков wiper-нагрузки на основе поведения подов. | Спроектировать процесс безопасной публикации open-source компонентов с проверкой provenance. | Создать инструмент оценки Cloud Security Posture для типовых конфигураций. |
| Задачи | 1) Изучить артефакты CanisterWorm и похожих семейств. 2) Спроектировать механизм сбора событий из Kubernetes API. 3) Реализовать алгоритм аномалий на основе частоты delete-операций. 4) Оценить точность на синтетических нагрузках. |
1) Классифицировать атаки на GitHub Actions. 2) Внедрить подпись артефактов cosign. 3) Разработать политику сканирования образов до публикации. 4) Провести ретроспективу инцидента с Trivy. |
1) Описать модель нарушителя по MITRE ATT&CK. 2) Собрать датасет небезопасных конфигураций. 3) Разработать правила для OPA/Gatekeeper. 4) Сравнить с OWASP Kubernetes Top 10. |
| Структура работы | Глава 1 — анализ wiper-атак; Глава 2 — проектирование модуля детекта; Глава 3 — эксперимент и метрики. | Глава 1 — обзор supply chain инцидентов; Глава 2 — реализация пайплайна с cosign и SLSA; Глава 3 — оценка стоимости внедрения. | Глава 1 — теория и стандарты ISO/IEC 25010; Глава 2 — архитектура сканера; Глава 3 — тестирование на стенде. |
Обратите внимание: в любой из тем вы не просто «изучаете статью», а опираетесь на фактуру из неё как на один из источников, дополняя её официальными отчётами Flare, Wiz, Aikido и собственными экспериментами.
Глава 1: кладите инцидент в основу аналитики
В первой главе нужно показать, что вы понимаете ландшафт угроз, а не пересказываете Википедию. Возьмите за отправную точку цепочку атаки TeamPCP:
- первичное проникновение через неаутентифицированный Docker API или устаревший React2Shell;
- горизонтальное перемещение с кражей креденшелов и токенов Kubernetes;
- компрометация GitHub Actions официального проекта Trivy;
- деплой wiper-нагрузки только для жертв с иранской локалью.
Такая последовательность превращается в формализованную модель нарушителя. Используйте фреймворки ATT&CK и OWASP Application Security Verification Standard — это поднимет уровень работы и покажет навык применения стандартов. Для схемы хорошо подойдёт C4 или обычная UML-диаграмма последовательности. Не рисуйте общую картинку из интернета: постройте свою, с actor’ом “TeamPCP” и компонентами “Docker API”, “Trivy repository”.
Глава 2: проектируйте защиту, а не набор скриптов
Когда дойдёте до проектирования, имейте в виду: одна из причин успеха TeamPCP — автоматизация поиска暴露的控制平面. Значит, ваша работа должна включать компонент постоянного аудита. Если тема связана с Kubernetes, можно предложить набор политик на основе Open Policy Agent. Вот фрагмент правила, которое блокирует контейнер с привилегированным режимом — это прямо относится к защите от компрометации узла.
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "Pod"
some c in input.request.object.spec.containers
c.securityContext.privileged == true
msg := sprintf("Privileged container '%s' is not allowed", [c.name])
}
deny[msg] {
input.request.kind.kind == "Pod"
some c in input.request.object.spec.containers
c.image starts with "docker.io/library/redis"
not c.securityContext.readOnlyRootFilesystem
msg := sprintf("Redis container '%s' must have read-only root filesystem", [c.name])
}
Этот код легко вставить в главу 2 в качестве экспериментальной части реализации. Но обязательно дополните его пояснением: как именно он противодействует технике TeamPCP? Например, запрет privileged-контейнеров снижает риск вертикальной эскалации, а read-only root filesystem мешает перезаписать бинарные файлы.
Глава 3: метрики и воспроизводимый эксперимент
Чтобы защита не была голословной, нужно сравнить «до/после» и посчитать метрики. Для системы детектирования аномалий используйте:
- полноту (recall) — сколько реальных атак нашлось;
- точность (precision) — сколько срабатываний не ложные;
- задержку детектирования — от начала массового delete до алерта;
- стоимость на 1000 подов — насколько решение дорого в эксплуатации.
В качестве стенда можно взять Kind или minikube, сгенерировать синтетический «wiper-под», который вызывает RemovePod, RemoveDeployment и удаляет PVC. Замерьте, как быстро ваш модуль среагирует. Затем постройте графики. Такой раздел выглядит сильно на защите, потому что демонстрирует инженерную, а не только литературную работу.
Чему вы научитесь в таком проекте
Работа над ВКР по мотивам CanisterWorm принесёт конкретные навыки, которые потом можно показать на собеседовании:
- анализировать цепочки атак с помощью MITRE ATT&CK;
- настраивать политики безопасности Kubernetes через OPA/Gatekeeper;
- сканировать образы и проверять подписи артефактов cosign;
- готовить тестовый стенд и оценивать эффективность защиты по метрикам Precision/Recall;
- оформлять результаты в соответствие с требованиями вуза и ГОСТ 7.32-2017.
Частые вопросы перед сдачей
Не слишком ли сложная тема для бакалаврской работы?
Если разделить на задачи, то проект становится выполнимым: один модуль — анализ логов, второй — реакция на аномалию. Бакалавр может сделать прототип без производственного развёртывания. Для магистерской уже уместна полноценная система с нагрузочным тестированием.
Где брать данные для анализа?
Используйте публичные отчёты Flare, Wiz, Aikido, дампы IOC от исследователей. Важно сослаться на них, а не переписывать текст. Для эксперимента данные можно сгенерировать самим — это даже плюс: работа становится воспроизводимой.
Как оформить схемы, чтобы не потерять баллы на нормоконтроле?
Делайте схемы в UML и называйте элементы по стандарту. Если в вузе требуют IDEF0 или BPMN — уточните на кафедре, но для ИТ-специальности обычно подходит UML. Подпишите каждую стрелку и движение данных.
Какие стандарты упоминать?
Если это безопасность — корректно ссылаться на ISO/IEC 27001, OWASP ASVS, NIST SP 800-53. Если говорите о качестве архитектуры — ISO/IEC 25010. Не выдумывайте номера и не применяйте стандарты «для красоты»; каждый должен соответствовать цели раздела.
Типичные ошибки студентов
Ошибка 1. Пересказ статьи вместо аналитики. «CanisterWorm распространяется через Docker API, атака началась 19 марта…» — это компиляция, а не исследование. Как избежать: выделите сценарий атаки, постройте свою классификацию, сравните с другими семействами.
Ошибка 2. Отсутствие эксперимента. Работа о защите Kubernetes, но нет ни одного кода, ни одного замера. В результате это реферат. Даже простой скрипт имитации атаки и замер времени реакции добавят практической ценности.
Ошибка 3. Игнорирование поставщика облачной услуги. TeamPCP атаковал Azure и AWS — значит, в работе должны быть учтены native-инструменты: GuardDuty, Defender for Cloud, а также кроссплатформенные решения. Не ограничивайтесь только open-source.
Что проверить перед сдачей
- Поставлена ли цель, и коррелирует ли она с каждой главой?
- Закрыты ли все задачи из введения выводами по главам?
- Есть ли собственная схема архитектуры (UML/C4), а не скриншот из статьи?
- Соответствуют ли метрики того, что вы обещали измерить?
- Проверены ли ссылки на источники и по стандарту вашего вуза?
- Есть ли приложение с листингом кода и результатами тестов?
- Уникальность текста действительно ваша, а не пересказ аналитики?
История с CanisterWorm — отличный повод показать преподавателю, что вы ориентируетесь в актуальных угрозах, умеете проектировать защитные механизмы и доводите их до измерения. Берите одну из трёх тем или предложите кафедре свою — но обязательно с фокусом на практическую реализацию.
Если вы чувствуете, что не успеваете собрать стенд или оформить главу с метриками, помните: специалисты нашего сервиса помогают с дипломом в сжатые сроки. Мы разбираемся в Kubernetes, облачных провайдерах и стандартах. Первая консультация — бесплатно, а на проработку темы уходит от 120 часов. Напишите нам, чтобы согласовать план работ.
Источник: ‘CanisterWorm’ Springs Wiper Attack Targeting Iran (опубликовано 2026-03-23)