Опубликовано: 26.09.2026 | Источник: TechCrunch

Безопасность AI-проектов в ВКР: разбор инцидента LiteLLM и применимые модели защиты

Поддомен: Cybersecurity × AI/ML. Роль автора: специалист по информационной безопасности.

Введение

В марте 2026 года в LiteLLM — открытом проекте-роутере для LLM, которым пользуются миллионы разработчиков, — обнаружили вредоносное ПО класса credential harvesting. Отдельного внимания заслуживает тот факт, что аудит соответствия (compliance) для проекта проводила компания Delve: то есть формально «безопасность была подтверждена», а вредонос всё равно проник в дистрибутив. Что это значит для выпускника ИТ-специальности? Ровно одно: классическая модель «прошли пентест один раз — успокоились» больше не работает. Для дипломной работы это готовый, свежий и очень «защищаемый» кейс — от него удобно отталкиваться, строя модели защиты цепочки поставок ПО (software supply chain), метрики контроля зависимостей и методики оценки риска для AI-пайплайнов. Ниже — как превратить эту новость в структуру, задачи и воспроизводимые артефакты ВКР, а не в пересказ пресс-релиза.

Частые вопросы студентов по этому кейсу

Темы ВКР, которые реально защитить (карточки)

• Модель контроля цепочки поставок для AI-инфраструктуры.
  Актуальность: кейс LiteLLM показал, что compliance-аудит ≠ иммунитет к малвари в зависимостях.
  Цель: разработать методику оценки доверия к зависимостям AI-проектов и прототип policy-движка.
  Задачи: 1) анализ supply chain-инцидентов 2021–2026; 2) формализация критериев доверия (SBOM, provenance, SLSA-уровни); 3) реализация проверок в CI; 4) оценка снижения риска.
  Структура: Гл.1 — теория и OWASP; Гл.2 — архитектура policy-движка (C4); Гл.3 — стенд и метрики.
• Обнаружение аномалий в ML-пайплайнах средствами OpenTelemetry.
  Актуальность: кража credentials в LLM-роутере проявляется как нехарактерный исходящий трафик и обращения к секретам.
  Цель: построить систему телеметрии и правила детекта для ML-сервиса.
  Задачи: сбор трейсов/метрик/логов, определение baseline, правила алертов, эксперимент.
  Структура: Гл.1 — observability + ISO/IEC 25010; Гл.2 — схема сбора данных; Гл.3 — precision/recall детектора.
• Методика оценки защищённости LLM-роутеров: чек-лист на базе OWASP LLM Top 10.
  Актуальность: роутеры — единая точка отказа и утечки ключей к нескольким провайдерам.
  Цель: адаптировать OWASP-перечень под задачу аудита self-hosted роутера.
  Задачи: маппинг угроз, разработка чек-листа, апробация на 2–3 open-source решениях, оценка применимости.
  Структура: Гл.1 — стандарты; Гл.2 — чек-лист и критерии; Гл.3 — апробация и выводы.
• Безопасность секретов в контейнерных AI-развёртываниях.
  Актуальность: credential harvesting целится именно в секреты окружений.
  Цель: сравнить подходы к хранению секретов (K8s Secrets, Vault, sealed-secrets) и предложить модель разграничения доступа.
  Задачи: анализ угроз, схема RBAC, прототип, тест на утечку.
  Структура: Гл.1 — теория; Гл.2 — проектирование; Гл.3 — сценарии отказа и метрики.

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

Глава 1. Аналитическая часть: где живёт угроза

Не пересказывайте новость — стройте таксономию. Опишите цепочку: контрибьютор → зависимость → CI-сборка → публикация артефакта → развёртывание у пользователя. Для каждой стадии укажите класс атак и контрмеры. Удобная диаграмма — C4-контейнер: сам LiteLLM, его зависимости, хранилище секретов, внешние LLM-провайдеры. Рядом — таблица «угроза → источник (OWASP LLM Top 10 / MITRE ATT&CK) → контроль». Именно это делает глава 1 защищаемой: видно, что вы работали с признанными стандартами, а не с блог-постами.

Глава 2. Проектирование: политики и pipeline

Здесь вы проектируете механизм. Пример минимального policy-скрипта для CI, который блокирует сборку при несоответствии требованиям доверия к зависимостям:

# policy/check-supply-chain.py
import json, sys, subprocess

ALLOWED_UNSIGNED = 0          # запрещаем любые неподписанные артефакты
REQUIRED_SLSA    = "SLSA_BUILD_LEVEL_3"

def scan(image: str):
    result = subprocess.run(
        ["trivy", "image", "--format", "json", image],
        capture_output=True, text=True, check=True
    )
    report = json.loads(result.stdout)
    critical = [v for v in report.get("Results", [])
                for v in v.get("Vulnerabilities", [])
                if v["Severity"] == "CRITICAL"]
    return critical

def verify_signature(artifact: str) -> bool:
    r = subprocess.run(["cosign", "verify", artifact],
                       capture_output=True, text=True)
    return r.returncode == 0

if __name__ == "__main__":
    target = sys.argv[1]
    critical = scan(target)
    if critical or not verify_signature(target):
        print("BLOCKED:", target)
        sys.exit(1)
    print("OK:", target)

Такая заготовка отлично защищается: её можно запустить на защите, показать вывод и объяснить, почему правило ALLOWED_UNSIGNED = 0 — не паранойя, а прямая реакция на инцидент с LiteLLM.

Глава 3. Эксперимент и метрики

Ниже — набор показателей, который вы будете представлять на защите. Считайте их до и после внедрения политик, тогда получите честный «эффект»:

Практические выводы: чему вы научитесь

• Строить модель угроз для AI-инфраструктуры, а не «рисовать страшилки».
• Настраивать CI-политики (Trivy, cosign, SBOM-генерация через Syft).
• Собирать телеметрию сервиса по OpenTelemetry и превращать её в метрики ИБ.
• Оформлять схемы (C4, BPMN) и результаты измерений в соответствии с ГОСТ 34 и ISO/IEC 25010.
• Обосновывать экономический результат: снижение риска через MTTD и FP-ratio, а не «стало безопаснее».

Источник: Delve did the security compliance on LiteLLM, an AI project hit by malware (опубликовано 2026-03-26)