Защита цепочки поставок Python-пакетов в ВКР: от инцидента LiteLLM до работающего конвейера
Двадцать четвёртого марта 2026 года сообщество Python-разработчиков столкнулось с неприятной реальностью: в PyPI появились вредоносные выпуски 1.82.7 и 1.82.8 библиотеки LiteLLM — проекта с аудиторией 95 млн загрузок в месяц. Злоумышленник перехватил учётные данные сопровождающего и выложил код, крадущий ключи и пароли прямо из окружений пользователей. Пакеты уже удалены, проект заморожен, но осадок остался. Для выпускника ИТ-специальности это не просто новость, а готовый кейс для дипломной работы: компрометация supply chain — один из самых востребованных сценариев на собеседованиях в ИБ, а тема легко превращается в защищаемую ВКР с измеримыми метриками, схемами по ГОСТ и работающим прототипом.
Основная часть: три направления ВКР и как их наполнить
| Тема ВКР | Актуальность (отсылка к статье) | Цель | Задачи | Структура |
|---|---|---|---|---|
| Методика контроля целостности зависимостей Python-проекта | LiteLLM показал: доверять версии из индекса нельзя без проверки хеша и подписи. | Снизить вероятность подмены пакета на ≥90% за счёт hash-pinning и проверки подписей. | 1) Анализ векторов атак на PyPI; 2) проектирование схемы верификации; 3) реализация обёртки над pip; 4) замер ложноположительных срабатываний. | Гл.1 — обзор OWASP и MITRE ATT&CK; Гл.2 — архитектура валидатора (C4-диаграмма); Гл.3 — эксперимент на 50 популярных пакетах. |
| Автоматизированный pipeline SCA с подписью артефактов | Атаку можно было бы отсечь, если бы CI публиковал пакеты через SLSA-уровень и Sigstore. | Построить CI/CD, который отказывается собирать зависимость без проверки провенанса. | 1) Развернуть GitHub Actions + Cosign; 2) интегрировать pip-audit и CycloneDX SBOM; 3) настроить блокирующие гейты; 4) описать политику по ISO/IEC 25010 (защищённость). | Гл.1 — обзор SCA и SLSA; Гл.2 — схема pipeline (UML Activity); Гл.3 — метрики: время сборки, число отклонённых артефактов. |
| Модель угроз для аккаунтов сопровождающих OSS-проектов | Инцидент — это компрометация identity, а не уязвимость кода. | Формализовать угрозы и меры (2FA, trusted publishing, минимальные права) по OWASP. | 1) Построить дерево атак; 2) оценить риски методом качественных шкал; 3) предложить регламент; 4) смоделировать атаку в изолированном стенде. | Гл.1 — ГОСТ 34 и анализ инцидентов; Гл.2 — модель угроз и матрица рисков; Гл.3 — проверка регламента на столе и в лабе. |
1. Что взять из статьи в первую главу
Не пересказывайте новость целиком — это уже недостаточно для «анализа предметной области». Стройте цепочку атаки как формальную диаграмму: maintainer → компрометация учётных данных → публикация в PyPI → установка пользователем → эксфильтрация секретов. Такая последовательность отлично ложится на UML Activity или BPMN-диаграмму и легко читается комиссией. Дополните её таблицей существующих мер: PEP 458 (защита индекса), PEP 480 (доверие к пакетам), Trusted Publishing (OIDC), Sigstore. Не выдумывайте «новые стандарты» — ссылайтесь на реально существующие OWASP Top 10 A06:2021 (уязвимые и устаревшие компоненты) и OWASP Top 10 CI/CD Security Risks.
ASCII-схема для приложения к ВКР
[Разработчик] --(2FA/OIDC)--> [CI/CD]
| |
| build + SBOM
| |
v v
[Git-репозиторий] --tag--> [Артефакт + подпись Cosign]
|
publish (PyPI)
|
[Потребитель]
|
verify hash + signature --> install
2. Реализация: что положить во вторую главу
Вторая глава — место для вашего кода. Минимально защищаемый прототип можно собрать за 2–3 недели: скрипт-обёртка над pip, который принимает requirements.lock с зафиксированными хешами, сверяет подпись артефакта через Cosign и пишет журнал в формате OpenTelemetry Events. Вот фрагмент конфигурации, который стоит показать в работе — он демонстрирует понимание hash-pinning, а не просто «я написал парсер»:
# requirements.lock — строгий pin с хешами
litellm==1.82.6 \
--hash=sha256:0a1b2c...c9d0 \
--hash=sha256:ff12...88ab
# проверка провенанса в GitHub Actions
- name: Verify artifact provenance
run: |
cosign verify-blob \
--certificate-identity-regexp "https://github.com/myorg/.*" \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
--signature dist/litellm.sig dist/litellm.whl
# Сканер уязвимостей и генерация SBOM
- run: pip-audit --requirement requirements.lock --format cyclonedx
Для описания архитектуры используйте C4-диаграммы: контекст (разработчик, CI, индекс, потребитель), контейнер (сервис валидации, база результатов), компонент (парсер lock-файла, верификатор подписи, отчётность). Это закрывает и нормоконтроль (графическая часть), и критерий «практическая значимость».
3. Третья глава: как считать эффективность
Чтобы выводы не выглядели декларативными, введите метрики по ISO/IEC 25010 — «защищённость» и «производительность». Например: доля заблокированных подозрительных зависимостей, среднее время проверки одного пакета, число ложных срабатываний на 100 сборок, прирост времени CI по сравнению с базовым pipeline. Соберите статистику минимум на 50 реальных пакетах. Хорошо работает сравнение до и после внедрения: подмена тестового пакета должна обнаруживаться в 100% случаев при добавлении ≤8 секунд к сборке.
FAQ для тех, кто ещё выбирает направление
Мне не дадут доступ к корпоративной инфраструктуре — тему защитить реально?
Да. Инцидент LiteLLM воспроизводится в локальном Docker: поднимаете свой индекс (devpi или Artifactory Community), публикуете «вредоносный» пакет-эмулятор и проверяете, ловит ли ваш валидатор подмену. Комиссия ценит воспроизводимость, а не масштаб стенда.
Надо писать собственный сканер уязвимостей?
Нет. pip-audit, OSV-Scanner и OWASP Dependency-Check уже решают задачу. Ваш вклад — интеграционный слой, политика блокировок и метрики. Это осознанное инженерное решение, а не «лентяйство».
Где брать данные об инцидентах?
Открытые базы OSV.dev, GitHub Security Advisories, CVE/NVD, отчёты ReversingLabs и Sonatype. Не забудьте оформить ссылки по ГОСТ и зафиксировать дату выгрузки — данные быстро устаревают.
Что делать с расхождением англоязычных терминов в ГОСТ?
Давайте расшифровку при первом упоминании: «Software Composition Analysis (SCA) — анализ состава программного обеспечения». Дальше можете использовать аббревиатуру. Нормоконтроль такое принимает.
- Ссылки на все источники (включая оригинал про LiteLLM) оформлены по ГОСТ Р 7.0.5 и проверены на актуальность.
- Задачи во введении дословно совпадают с выводами по главам — комиссия любит это проверять.
- Есть минимум одна архитектурная и одна процессная схема (C4 + BPMN/UML), а не только скриншоты кода.
- Метрики эффективности описаны с формулами, единицами измерения и реальными замерами.
- Код в приложениях оформлен единообразно, с указанием окружения и версий.
- Раздел «заключение» содержит ограничения работы и направления развития.
- Проверка на заимствования пройдена, отчёт приложен.
- Сканер ради сканера. Студент подключает pip-audit и считает задачу закрытой, но не отвечает на вопрос «какая политика блокировки?». ВСЕГДА добавляйте матрицу «критичность → действие».
- Игнорирование подписи артефактов. Hash-pinning без проверки провенанса не спасает от компрометации CI — ровно как в кейсе LiteLLM, где валидная версия была заменена на вредоносную.
- Отсутствие воспроизводимости. «Работало у меня» — красная тряпка для комиссии. Приложите Dockerfile, lock-файл и скрипт запуска эксперимента.
Источник: В PyPI размещены вредоносные выпуски библиотеки LiteLLM, насчитывающей 95 млн загрузок в месяц (опубликовано 2026-03-24)