Материал

Threat Modeling для AI-фич: два сценария, два разных уровня риска

Опубликовано: 06 мая 2026 Время чтения: 22 мин

Продукт использует AI — и команда пишет код с AI. Почему это разные threat model'и, и как выстроить защиту в каждом случае.

Почему нельзя мерить одной меркой

Когда в команде появляется AI, SecurityChampion или AppSec-специалист сталкивается с вопросом: где именно проводить threat modeling? Что защищать? Откуда угроза?

На практике встречаются две ситуации, которые часто смешивают в одну.

Первая — продукт использует AI: чат-бот, рекомендательный движок, функция автодополнения, агент для бронирования, RAG-поиск по базе знаний. Пользователи взаимодействуют с моделью напрямую или через API, а данные проходят через LLM-слой.

Вторая — команда пишет код с помощью AI: разработчики используют GitHub Copilot, Cursor, ChatGPT или Claude, чтобы генерировать функции, рефакторить, предлагать зависимости. AI-ассистент находится внутри процесса разработки, а не в продукте.

Это разные поверхности атаки, разные акторы угроз и разные меры защиты. По данным Stack Overflow Developer Survey 2024, 76% разработчиков уже используют или планируют использовать AI-инструменты в работе [1]. При этом большинство security-команд оценивают эти два сценария в рамках одного threat model — и получают пробелы в обоих направлениях.

Часть I. Threat model для продукта, который использует AI

1.1 Поверхность атаки: что принципиально меняет LLM-слой

В классическом веб-приложении атакующий работает с предсказуемым интерфейсом: форма, API-эндпоинт, база данных. Модель угроз строится на STRIDE — и этого чаще всего хватает.

Когда в продукте появляется LLM, возникают новые активы и новые процессы, которые STRIDE не покрывает в чистом виде [2]. Модель стала полноправным компонентом архитектуры, и каждое из её взаимодействий является потенциальной поверхностью для атаки:

входящий пользовательский промпт;
системный промпт (system prompt) с инструкциями для модели;
RAG-база данных, из которой модель получает контекст;
инструменты и плагины, к которым у модели есть доступ;
история диалога (context window);
исходящий ответ, который поступает в downstream-системы.

Исследователи из ASTRIDE (расширение STRIDE для agentic AI) фиксируют: традиционная методология теряет нюанс в трёх местах — intent misalignment (модель делает не то, что задумал разработчик), autonomous scope creep (агент постепенно расширяет свои полномочия) и multi-agent trust dynamics (агенты в сети слепо доверяют друг другу) [3].

1.2 OWASP LLM Top 10 2025: карта угроз для продукта

OWASP Gen AI Security Project публикует и обновляет список из десяти наиболее критичных рисков для LLM-приложений. Версия 2025 существенно переработана с учётом реальной практики атак [4].

Рассмотрим ключевые угрозы через призму продукта.

LLM01 — Prompt Injection остаётся угрозой №1. Разделяют два вида. Прямая инъекция: пользователь вводит инструкцию, которая переопределяет системный промпт и меняет поведение модели. Косвенная (indirect) инъекция: вредоносный контент встроен во внешний источник данных — страницу, документ, письмо, — которые LLM обрабатывает в рамках RAG или агентского поиска. Атакующий не взаимодействует с системой напрямую, но его инструкция исполняется через модель [5]. MITRE ATLAS (версия 5.1.0) документирует этот вектор как AML.T0051 и указывает, что реальные эксплойты против LLM в production уже зафиксированы: в частности, CVE-2025-32711 (EchoLeak) демонстрирует возможность утечки данных через косвенную инъекцию [6].

LLM02 — Sensitive Information Disclosure. LLM может раскрыть обучающие данные (training data memorization), системные промпты или данные других пользователей через context window. Уязвимость усиливается в RAG-системах: если вектор-база плохо изолирована, атакующий может получить данные, предназначенные для другого пользователя [4].

LLM06 — Excessive Agency. Когда LLM-агент получает права, которые шире, чем необходимо для задачи, одна удачная инъекция превращает его в вектор реального вреда. OWASP выделяет три причины избыточной agency: излишняя функциональность (агент умеет слишком много), излишние права (широкий IAM/RBAC) и излишняя автономия (агент действует без подтверждения пользователя) [4]. В agentic-системах этот риск масштабируется через цепочки агентов: один скомпрометированный агент может escalate привилегии и передать их соседнему [9].

LLM07 — System Prompt Leakage. Системный промпт нередко содержит внутреннюю логику, имена инструментов, форматы данных и даже учётные данные (connection strings, API keys). Даже без полного раскрытия атакующий может восстановить структуру системного промпта через паттерны взаимодействия [4].

LLM03 — Supply Chain для LLM. В отличие от традиционного supply chain, атаки на LLM-зависимости труднее обнаружить: модели распространяются как бинарные файлы. Риски включают отравлённые pre-trained модели, скомпрометированные LoRA-адаптеры, зависимости в Python/JS-окружении оркестратора [7].

LLM04 — Data and Model Poisoning. Если у атакующего есть возможность влиять на обучающие данные или RAG-базу, он может встроить скрытые инструкции или изменить поведение модели в определённых ситуациях. В корпоративных RAG-системах чаще встречается document poisoning: вредоносный документ, загруженный в базу знаний, начинает влиять на все запросы, которые его захватывают [5].

1.3 Применение STRIDE к LLM-компонентам: что меняется

Исследователи из Secureworks и Medium-аналитики зафиксировали сопоставление STRIDE с угрозами OWASP LLM [2, 8]. Это помогает встроить AI-специфичные угрозы в привычный язык:

Spoofing → подделка системного промпта, имперсонация агента в multi-agent архитектуре;
Tampering → LLM01 (Prompt Injection), LLM04 (Data Poisoning);
Repudiation → отсутствие логирования LLM-вызовов, невозможность трассировать решение;
Information Disclosure → LLM02, LLM07 (System Prompt Leakage);
Denial of Service → LLM10 (Unbounded Consumption, истощение токенов или бюджета);
Elevation of Privilege → LLM06 (Excessive Agency).

Где STRIDE теряет нюанс: он не описывает intent misalignment (когда модель делает формально правильное, но опасное действие), не покрывает agentic delegation chains и не захватывает emergent behavior в multi-agent системах [3].

1.4 MITRE ATLAS и MAESTRO: расширенный инструментарий

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems, v5.1.0, ноябрь 2025) — это структурированная база тактик и техник атак на AI-системы, аналог ATT&CK для ML [6]. Содержит 16 тактик, 84 техники, 32 mitigation и 42 задокументированных кейса. Около 70% митигаций из ATLAS соответствуют существующим security-контролям, что упрощает интеграцию в текущий SOC.

CSA MAESTRO (Multi-Agent Environment, Simulation, and Threat Reasoning Operations) — фреймворк для threat modeling именно agentic-систем [9]. Структурирует угрозы по слоям архитектуры: Foundation Model → Data Operations → Agent Framework → Deployment Infrastructure → Evaluation & Observability → Security & Compliance → Agent Ecosystem. Ключевые угрозы по классификации MAESTRO: Context Poisoning (T3), Privilege Compromise (T3), Rogue Agents (T13), Human Trust Manipulation (T15).

NIST AI RMF 1.0 (январь 2023) и его расширение для Generative AI — NIST AI 600-1 (июль 2024) — задают управленческий язык для AI-рисков: Govern, Map, Measure, Manage [10]. 600-1 выделяет 12 категорий рисков, специфичных для GenAI, включая Confabulation, Data Privacy, Information Security и Value Chain. Для agentic систем, развёртываемых в 2025–2026, этот документ уже устарел в части governance delegation chains — CSA разрабатывает Agentic Profile для AI RMF.

1.5 Практический checklist: что проверить до деплоя AI-фичи

Перед тем как AI-фича уходит в production, стоит пройти следующие точки:

Определить trust boundary между пользовательским вводом, системным промптом и model output — и убедиться, что каждый слой валидируется независимо.
Проверить, может ли пользователь через prompt injection добраться до системного промпта или вызвать инструменты за пределами своей роли.
Провести indirect injection test: загрузить в RAG-базу документ с инструкцией "ignore previous instructions" и проверить, выполняет ли её модель при обращении.
Ревью scope агентских инструментов: нет ли там доступа к write-операциям, отправке email, внешним API без подтверждения.
Проверить system prompt на наличие credentials, connection strings, internal role names.
Убедиться, что LLM-вызовы логируются и трассируются — как для безопасности, так и для compliance (Repudiation из STRIDE).
Оценить сценарий unbounded consumption: есть ли rate limiting и бюджет на токены.
Для RAG-системы: проверить изоляцию векторного пространства между пользователями и tenant'ами.

Часть II. Threat model для команды, которая пишет код с AI

2.1 Почему это другой сценарий

В первом сценарии AI-ассистент находится снаружи команды — он обслуживает пользователей. Во втором он находится внутри: сидит рядом с разработчиком, читает файлы проекта, предлагает код, импортирует зависимости.

Ключевое отличие threat model: теперь злоумышленник атакует не через пользователя продукта, а через разработчика. Цель — скомпрометировать код до того, как он попадёт в production. Это принципиально новая точка во supply chain.

По данным GitHub AI in Software Development Survey 2024, около 97% разработчиков, участвовавших в опросе, использовали AI-инструменты для написания кода в рабочем или личном контексте [46]. По данным Checkmarx, 68% разработчиков говорят, что стали тратить больше времени на исправление security-уязвимостей с момента начала использования AI-ассистентов [26].

2.2 Поверхность атаки: где возникают риски AI-кодинга

Package hallucinations (slopsquatting). Исследование USENIX Security 2025, проведённое на 576 000 сгенерированных фрагментов кода от 16 моделей, показало: в среднем 19,7% пакетных зависимостей, предложенных LLM, не существует [11]. Для open source моделей этот показатель достигает 22%, для коммерческих — около 5%. Критичный момент: 43% hallucinated-пакетов повторяются при повторных запросах с той же формулировкой [12]. Это делает их предсказуемыми для атакующего. Схема атаки (slopsquatting, термин введён Сетом Ларсоном и Эндрю Несбиттом в апреле 2025): атакующий публикует вредоносный пакет с тем именем, которое модель регулярно галлюцинирует, и ждёт установки у следующего разработчика [13].

Secrets в AI-сгенерированном коде. Исследование 2024 года показало, что AI-assisted коммиты содержат hardcoded secrets более чем в два раза чаще, чем коммиты, написанные вручную (3,2% против 1,5%), а на публичном GitHub за год зафиксирован 34-процентный рост hardcoded credentials [43]. По отдельным данным, одно исследование обнаружило, что Copilot выдал 2702 credential-подобные строки, из которых ≥200 соответствовали реальным GitHub-секретам [11].

Rules File Backdoor. В марте 2025 Pillar Security опубликовала исследование нового вектора атаки: в конфигурационные файлы AI-ассистентов (.cursor/rules, GitHub Copilot workspace settings) встраиваются невидимые Unicode-символы — zero-width joiners, bidirectional text markers, — которые несут скрытые инструкции для AI-ассистента [44]. Ассистент читает эти инструкции и тихо генерирует бэкдорный или уязвимый код, не упоминая об этом в своих ответах. GitHub классифицировал проблему не как уязвимость вендора, а как ответственность пользователя, и лишь 1 мая 2025 добавил предупреждение о скрытом Unicode [44]. CVE-2025-53773 присвоен для GitHub Copilot. Ключевая опасность: правило сохраняется при форкинге репозитория и распространяется на все будущие сессии генерации кода в команде [49].

IDEsaster: массовые уязвимости в AI IDE. В конце 2025 года исследователь Ари Марзук (MaccariTA) опубликовал анализ 30+ уязвимостей в популярных AI-ориентированных IDE и расширениях: Cursor, Windsurf, GitHub Copilot, Roo Code, JetBrains Junie, Zed.dev, Cline [48]. Атаки используют prompt injection через файлы проекта для чтения приватных данных, редактирования IDE-настроек и достижения RCE без взаимодействия с пользователем. 24 уязвимости получили CVE-идентификаторы. Общий вывод: большинство AI IDE не включали базовый IDE (редактор) в свою threat model и считали его функции изначально безопасными.

CamoLeak (CVSS 9.6). В июне 2025 критическая уязвимость в GitHub Copilot Chat позволяла бесшумно эксфильтрировать секреты и исходный код из приватных репозиториев через Unicode-prompt injection в сочетании с обходом CSP через собственную инфраструктуру GitHub [50]. Уязвимость исправлена в августе 2025 путём отключения рендеринга изображений в Copilot Chat.

Уязвимости в AI-сгенерированном коде. По данным diffray.ai, 29–45% AI-генерированного кода содержит security-уязвимости [24]. Исследование ноября 2024 года показало, что не менее 48% фрагментов кода, сгенерированных пятью популярными моделями, содержали уязвимости [29]. Ранние версии LLM-кодогенераторов генерировали код с уязвимостями из MITRE CWE Top-25 в 40% случаев [30].

Prompt injection в контексте кодинга. Unit 42 (Palo Alto Networks) задокументировали, что вредоносный комментарий в файле, README или user story могут содержать инструкции вида "skip input validation", которые AI-ассистент интерпретирует как рабочие директивы [16]. OWASP относит это к supply chain атакам эпохи LLM.

2.3 Специфика threat model: чем отличается от сценария I

В сценарии "продукт с AI" злоумышленник взаимодействует с системой на этапе runtime через пользовательский интерфейс. Защитные меры действуют в production: input validation, output filtering, rate limiting, аудит-лог.

В сценарии "команда пишет код с AI" злоумышленник работает на этапе разработки: атакует developer environment, репозиторий, конфигурационные файлы и SDLC-pipeline. Вредоносный код попадает в production незаметно — он выглядит как обычный AI-suggested код, прошедший код-ревью.

Разница в том, что:

Атакующий вектор не виден в production-логах: он прошёл до деплоя.
Код-ревью перестаёт быть надёжным gate: reviewер видит то, что сгенерировал AI, но не видит скрытые инструкции в конфигах или отравленные зависимости.
Уязвимость распространяется через форки и downstream-зависимости: одна отравленная rules-файл влияет на весь проект и все его форки.
Разработчик испытывает ложное чувство безопасности: "AI написал, значит, вероятно, безопасно" — тогда как исследования показывают обратное.

2.4 Threat model для AI-кодинга: где проверять

Для этого сценария threat modeling разворачивается вокруг четырёх зон:

Зона 1: Контекст разработчика (developer environment). AI-ассистент имеет доступ к файлам проекта, включая .env, secrets, конфиги. Любая уязвимость в самом ассистенте или его интеграции превращается в вектор кражи данных. Это подтверждают CamoLeak и IDEsaster.

Зона 2: Зависимости и supply chain. Package hallucinations и slopsquatting — это новый класс dependency confusion attacks. Lock-файлы должны верифицироваться, предложенные пакеты — проверяться в реестрах до установки. Пакет с галлюцинированным именем при первой публикации attacker'а немедленно становится опасным для следующего запроса к той же LLM [11].

Зона 3: Конфигурационные файлы AI-ассистентов. .cursor/rules, .github/copilot/instructions.md и аналоги должны быть под integrity control — с той же строгостью, что и CI/CD-файлы. Rules File Backdoor показал: эти файлы теперь являются attack vector, требующим git blame, diff review и проверки на скрытые Unicode-символы [43].

Зона 4: Сгенерированный код. AI-код проходит code review, но у людей развивается automation bias: код, выглядящий правильно, принимают без глубокого анализа. Secrets, небезопасные паттерны, debug-флаги, чрезмерно широкий CORS, hardcoded endpoint'ы — всё это типичные паттерны AI-генерации, которые не бросаются в глаза при беглом ревью.

2.5 Практический checklist: что проверить до merge AI-сгенерированного кода

Есть ли в diff новые зависимости — и если да, существуют ли они в реестре, какова их история, нет ли CVE?
Не содержит ли код hardcoded secrets, API keys, default credentials, fallback-ключей?
Нет ли в коде debug-режимов, расширенного логирования, overly permissive CORS или open redirect?
Проверены ли конфигурационные файлы AI-ассистентов на скрытые Unicode-символы и посторонние инструкции?
Не галлюцинировал ли AI несуществующие пакеты — и не установлены ли они уже в lock-файл?
Проверен ли CI/CD-файл, если AI его менял: нет ли там новых permissions, внешних URL, изменений в environment variables?
Есть ли у команды правило: AI-код, меняющий security-чувствительные зоны (auth, crypto, IAM, конфиги), проходит дополнительный ревью?

Часть III. Где модели пересекаются и где расходятся

3.1 Общие принципы, работающие в обоих сценариях

Оба сценария разделяют несколько фундаментальных принципов:

Принцип минимальных привилегий применим как к агентским инструментам в продукте, так и к правам AI-ассистента в developer environment. Чем шире scope, тем разрушительнее компрометация.

Принцип defense in depth: один слой контроля не спасает ни в первом, ни во втором случае. В продукте нужны input validation + output filtering + rate limiting + audit log. В разработке — SAST + SCA + secrets detection + code review + dependency lock.

Принцип Zero Trust к AI-выводу: "AI предложил" не означает "безопасно". Ни в продукте (AI-ответ может содержать вредоносный контент), ни в разработке (AI-код может содержать уязвимость или отравленную зависимость).

3.2 Ключевые различия

Первое различие: точка вмешательства. В продукте угроза реализуется в runtime, и защита применяется до и после вызова модели. В разработке угроза реализуется до деплоя, и защита должна стоять в SDLC-pipeline.

Второе: профиль атакующего. В продукте атакующий — внешний пользователь или владелец вредоносного контента во внешнем источнике. В разработке — злоумышленник, который контролирует репозиторий (или форк), публичный пакет или конфигурационный файл.

Третье: что является активом. В продукте защищают данные пользователей, системный промпт, поведение модели. В разработке защищают исходный код, секреты, SDLC-pipeline и downstream-продукт.

Четвёртое: кто несёт ответственность. В продукте ответственность лежит на security/platform-команде, которая проектирует архитектуру AI-фичи. В разработке — разделённая: вендор AI-ассистента, команда разработки, DevSecOps.

Часть IV. Frameworks: какой применять когда

4.1 Для продукта с AI

OWASP LLM Top 10 (2025) — базовая карта угроз для LLM-приложений [4].
OWASP Agentic AI Threat Model (конец 2025) — для систем с автономными агентами [9].
MITRE ATLAS v5.1.0 — для структурированного threat modeling по тактикам/техникам [6].
NIST AI RMF + AI 600-1 — для governance и управления рисками на уровне организации [10].
CSA MAESTRO — для multi-agent архитектур [9].
STRIDE с AI-расширениями (ASTRIDE) — как базовый язык для интеграции в привычные security-процессы [3].

4.2 Для команды, использующей AI в разработке

OWASP Top 10 (классика) — по-прежнему применим для оценки качества AI-сгенерированного кода.
OWASP LLM03 (Supply Chain) — для оценки рисков зависимостей и пакетов [7].
CWE Top-25 — как benchmark для статического анализа AI-кода.
Slopsquatting / package hallucination guidance (USENIX 2025) — для политики управления зависимостями [11].
CSA AI Organizational Responsibilities (январь 2025) — RACI для безопасного AI-кодинга [43].
IDEsaster / Rules File Backdoor research — как threat intelligence для конфигурационных файлов AI-ассистентов [48, 44].

Часть V. Ошибки и слепые зоны

5.1 Типичные ошибки в threat modeling для продукта с AI

Первая ошибка — не включать модель в DFD (Data Flow Diagram). LLM является компонентом архитектуры наравне с базой данных или внешним API, и должна быть обозначена с trust boundaries.

Вторая — считать системный промпт "секретным" только потому, что пользователь его не видит. Через prompt injection или активный зондаж структура промпта восстанавливается. Credentials в системном промпте — не секрет, а риск.

Третья — игнорировать indirect injection. Классический pentest проверяет прямые входы, но не проверяет, что происходит, когда в RAG-базу загружен документ с вредоносными инструкциями.

Четвёртая — проектировать агента с широкими правами "на вырост". Excessive agency в сочетании с prompt injection дают атакующему реальное действие: отправку данных, изменение конфигурации, вызов внешнего API.

5.2 Типичные ошибки при использовании AI в разработке

Первая — не включать конфигурационные файлы AI-ассистента в scope security-ревью. После IDEsaster и Rules File Backdoor эти файлы должны быть в scope наравне с .github/workflows.

Вторая — принимать lock-файл как истину, не проверяя происхождение зависимостей. AI может предложить пакет, которого не было в проекте. Если он появился в package.json без явного ревью — это риск.

Третья — полагаться на code review как единственный gate для AI-кода. Automation bias реален: проверенный с виду код принимается быстрее. Нужны автоматизированные слои: SAST, secrets detection, SCA — до merge.

Четвёртая — считать, что AI пишет "более безопасный" код, чем человек. Исследования показывают, что AI-assisted разработчики нередко испытывают false sense of security, принимая уязвимый код быстрее, чем написали бы его сами [30].

Часть VI. Что делать дальше: decision framework

Прежде чем начинать threat modeling, команде стоит ответить на три вопроса:

Вопрос 1: Где находится AI в нашем контексте? В продукте (пользователи взаимодействуют с моделью) → применяем Сценарий I + OWASP LLM Top 10 + MITRE ATLAS. В разработке (команда использует AI-ассистент) → применяем Сценарий II + supply chain focus + SDLC-контроли. Оба варианта → нужны две отдельные threat model'и с разными владельцами.

Вопрос 2: Какие активы защищаем? Данные пользователей, системный промпт, поведение модели → продуктовый threat model. Исходный код, секреты, зависимости, CI/CD → разработческий threat model.

Вопрос 3: Где наши gate'ы? Для продукта с AI — архитектурный ревью до запуска фичи, input/output фильтрация, регулярный pentest с AI-специфическими векторами. Для AI-кодинга — pre-commit secrets detection, SCA на каждый PR с новыми зависимостями, ревью конфигурационных файлов AI-ассистентов.

На практике risk-based подход — как формулирует OWASP AI Exchange — означает не проверять всё подряд, а сосредоточиться на том, что действительно критично для данного изменения [5].

Один рабочий pull request не обязательно безопасен. Дифы дочитывают не до конца. Новая транзитивная зависимость приезжает незаметно. Конфиги и служебные файлы читают хуже всего. А перед релизом времени мало — и последнее, что нужно команде, это ещё один длинный security-отчёт вместо чёткого ответа: "вот что блокирует этот merge, вот следующий шаг".

Именно в этой точке — между pull request и релизом — работает HighVibe: как дополнительный слой контроля, который смотрит на конкретное изменение в коде, конфигах, зависимостях и служебных файлах, объясняет риск простым языком и предлагает практический ответ — можно ли безопасно принять это изменение сейчас.

Заключение

Threat modeling для AI — это не отдельная дисциплина, которую нужно осваивать с нуля. Это расширение того, что команды и так делают: выявление активов, поверхностей атаки, акторов угроз и защитных мер. Но у AI есть специфика, которую классические фреймворки не захватывают.

Принципиально важно не смешивать два сценария. Продукт с AI и команда, пишущая код с AI, — это разные контексты, разные активы и разные векторы атаки. У каждого должны быть свои чеклисты, свои gate'ы и свои владельцы.

Хорошая новость: большинство рисков в обоих сценариях поддаются митигации практическими мерами, которые не требуют отказа от AI. Secrets detection, SCA, integrity check конфигурационных файлов, минимальные привилегии для агентов, валидация входов и выходов LLM — это операционные решения, которые можно внедрить итеративно.

Главное: "работает" и "безопасно" — не одно и то же. Ни для AI-фич в продукте, ни для AI-генерированного кода в репозитории.

Источники

[1] Stack Overflow — "2024 Developer Survey" — https://survey.stackoverflow.co/2024/

[2] Secureworks — "Unravelling the Attack Surface of AI Systems" — https://www.secureworks.com/blog/unravelling-the-attack-surface-of-ai-systems

[3] arxiv — "ASTRIDE: A Security Threat Modeling Platform for Agentic-AI Applications" — https://arxiv.org/pdf/2512.04785

[4] OWASP Gen AI Security Project — "Top 10 for LLM Applications & Generative AI 2025" — https://genai.owasp.org/

[5] OWASP AI Exchange — "AI Security Overview" — https://owaspai.org/docs/ai_security_overview/

[6] Vectra AI / MITRE ATLAS — "MITRE ATLAS Framework Guide v5.1.0" — https://www.vectra.ai/topics/mitre-atlas

[7] Medium — "LLM03: Supply Chain Risks in AI and LLM Applications (2025)" — https://medium.com/@guptaseema578/llm03-supply-chain-risks-in-ai-and-llm-applications-2025-ba171994dc14

[8] Medium — "Threat Modeling for AI Systems: STRIDE, DREAD, and Beyond" — https://medium.com/@dave-patten/threat-modeling-for-ai-systems-stride-dread-and-beyond-8a3996a0ab43

[9] OWASP / aigl.blog — "Agentic AI Threats and Mitigations (OWASP ASI, v1.0, Feb 2025)" — https://www.aigl.blog/content/files/2025/04/Agentic-AI---Threats-and-Mitigations.pdf

[10] NIST — "AI Risk Management Framework (AI RMF 1.0 + AI 600-1)" — https://www.nist.gov/itl/ai-risk-management-framework

[11] USENIX — "We Have a Package for You! Package Hallucinations by Code Generating LLMs" — https://www.usenix.org/publications/loginonline/we-have-package-you-comprehensive-analysis-package-hallucinations-code

[12] DevOps.com — "AI-Generated Code Packages Can Lead to 'Slopsquatting' Threat" — https://devops.com/ai-generated-code-packages-can-lead-to-slopsquatting-threat-2/

[13] Snyk — "Slopsquatting: New AI Hallucination Threats & Mitigation Strategies" — https://snyk.io/articles/slopsquatting-mitigation-strategies/

[14] emergentmind.com — "LLM-Generated Code Security (survey)" — https://www.emergentmind.com/topics/security-of-llm-generated-code

[15] Straiker — "Comparing AI Security Frameworks: OWASP, CSA, NIST, and MITRE" — https://www.straiker.ai/blog/comparing-ai-security-frameworks-owasp-csa-nist-and-mitre

[16] Unit 42 / Palo Alto — "The Risks of Code Assistant LLMs" — https://unit42.paloaltonetworks.com/code-assistant-llms/

[17] Checkmarx — "Why AI-Generated Code May Be Less Secure" — https://checkmarx.com/learn/ai-security/why-ai-generated-code-may-be-less-secure-and-how-to-protect-it/

[18] diffray.ai — "LLM Hallucinations in AI Code Review" — https://diffray.ai/blog/llm-hallucinations-code-review/

[19] Pillar Security — "New Vulnerability in GitHub Copilot and Cursor: Rules File Backdoor" — https://www.pillar.security/blog/new-vulnerability-in-github-copilot-and-cursor-how-hackers-can-weaponize-code-agents

[20] The Hacker News — "New 'Rules File Backdoor' Attack" — https://thehackernews.com/2025/03/new-rules-file-backdoor-attack-lets.html

[21] The Hacker News — "Researcher Uncovers 30+ Flaws in AI Coding Tools (IDEsaster)" — https://thehackernews.com/2025/12/researchers-uncover-30-flaws-in-ai.html

[22] LegitSecurity — "CamoLeak: Critical GitHub Copilot Vulnerability" — https://www.legitsecurity.com/blog/camoleak-critical-github-copilot-vulnerability-leaks-private-source-code

[23] CSA Labs — "Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt" — https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-security-vibe-coding-202/

[24] Dark Reading — "Will AI Code Generators Overcome Their Insecurities in 2025?" — https://www.darkreading.com/application-security/will-ai-code-generators-overcome-their-insecurities-2025