Модель угроз для репозитория

Разбирает проект и составляет краткую модель угроз: границы доверия, активы, пути атаки и меры защиты.

СкиллOpenAICodexApache-2.0Нужен терминалПроверка не требуется

Скачать на русскомОригинал на английском (архив)Источник ↗

Что делает: Разбирает проект и составляет краткую модель угроз: границы доверия, активы, пути атаки и меры защиты.
Когда брать: Когда просят смоделировать угрозы для кодовой базы или её части, перечислить пути злоупотребления и приоритеты мер защиты.
Когда не брать: Для общих описаний архитектуры, разбора кода и проектных работ, не связанных с безопасностью.
Пример запроса: Составь модель угроз для папки api нашего репозитория и предложи приоритетные меры защиты.
Нужно подключить: репозиторий с кодом

Как включить

Скачайте архив и распакуйте его.
Положите папку security-threat-model в ~/.agents/skills/.
Вызовите скилл командой $security-threat-model или найдите его через /skills.

Текст

---
name: "security-threat-model"
description: "Моделирование угроз по материалам репозитория: перечисляет границы доверия, активы, возможности атакующего, пути злоупотребления и меры защиты и записывает краткую модель угроз в Markdown. Включай, только если пользователь прямо просит смоделировать угрозы для кодовой базы или пути, перечислить угрозы и пути злоупотребления либо выполнить моделирование угроз уровня AppSec. Не включай для общих описаний архитектуры, разбора кода и проектных работ, не связанных с безопасностью."
---

Модель угроз для репозитория с исходным кодом

Подготовь практичную модель угроз уровня AppSec, специфичную для репозитория или пути проекта, а не общий чек-лист. Каждое утверждение об архитектуре подкрепляй свидетельствами из репозитория и явно называй допущения. Приоритет отдавай реалистичным целям атакующего и конкретным последствиям, а не общим чек-листам.

Быстрый старт

Собери (или выведи) входные данные:
Путь к корню репозитория и любые пути в рамках задачи.
Предполагаемое использование, модель развёртывания, доступность из интернета и ожидания по аутентификации (если известны).
Любое существующее описание репозитория или спецификацию архитектуры.
Используй промты из references/prompt-template.md, чтобы составить описание репозитория.
Следуй обязательному формату результата из references/prompt-template.md. По возможности используй его дословно.

Рабочий процесс

1) Определи рамки и выдели модель системы

По описанию репозитория определи основные компоненты, хранилища данных и внешние интеграции.
Определи, как система работает (сервер, CLI, библиотека, воркер), и её точки входа.
Отдели поведение во время выполнения от инструментов CI, сборки и разработки и от тестов и примеров.
Сопоставь расположения в рамках задачи с этими компонентами и явно исключи то, что в рамки не входит.
Не заявляй о компонентах, потоках и средствах защиты без свидетельств.

2) Определи границы, активы и точки входа

Перечисли границы доверия как конкретные связи между компонентами, отмечая протокол, аутентификацию, шифрование, проверку данных и ограничение частоты запросов.
Перечисли активы, определяющие риск (данные, учётные данные, модели, конфигурация, вычислительные ресурсы, журналы аудита).
Определи точки входа (эндпоинты, места загрузки файлов, парсеры и декодеры, триггеры заданий, инструменты администрирования, приёмники журналов и ошибок).

3) Оцени активы и возможности атакующего

Перечисли активы, определяющие риск (учётные данные, персональные данные, состояние, критичное для целостности, компоненты, критичные для доступности, артефакты сборки).
Опиши реалистичные возможности атакующего, исходя из доступности системы и предполагаемого использования.
Явно отметь то, чего атакующий не может, чтобы не завышать серьёзность.

4) Перечисли угрозы как пути злоупотребления

Предпочитай цели атакующего, которые соответствуют активам и границам (кража данных, повышение привилегий, нарушение целостности, отказ в обслуживании).
Классифицируй каждую угрозу и свяжи её с затронутыми активами.
Держи число угроз небольшим, но качественным.

5) Расставь приоритеты с явным обоснованием вероятности и последствий

Используй качественные оценки вероятности и последствий (низкая/средняя/высокая) с краткими обоснованиями.
Задай общий приоритет (критический/высокий/средний/низкий) по произведению вероятности на последствия с поправкой на существующие меры защиты.
Укажи, какие допущения сильнее всего влияют на ранжирование.

6) Согласуй с пользователем контекст сервиса и допущения

Кратко изложи ключевые допущения, существенно влияющие на ранжирование угроз или рамки, и попроси пользователя подтвердить или исправить их.
Задай 1–3 точных вопроса, чтобы восполнить недостающий контекст (владелец сервиса и окружение, масштаб и пользователи, модель развёртывания, аутентификация и авторизация, доступность из интернета, чувствительность данных, мультиарендность).
Остановись и дождись ответа пользователя, прежде чем готовить итоговый отчёт.
Если пользователь отказывается или не может ответить, укажи, какие допущения остаются и как они влияют на приоритет.

7) Предложи меры защиты и направления для сосредоточения

Отделяй существующие меры (со свидетельствами) от рекомендуемых.
Привязывай меры к конкретным местам (компонент, граница или точка входа) и типам средств защиты (проверки авторизации, проверка входных данных, принудительное соблюдение схемы, изоляция в песочнице, ограничения частоты запросов, изоляция секретов, журналы аудита).
Предпочитай конкретные подсказки по реализации общим советам (например, «принудительно проверять схему на шлюзе для загружаемых данных», а не «проверять входные данные»).
Основывай рекомендации на подтверждённом контексте пользователя; если допущения остаются неразрешёнными, помечай рекомендации как условные.

8) Проведи проверку качества перед завершением

Убедись, что охвачены все обнаруженные точки входа.
Убедись, что каждая граница доверия представлена в угрозах.
Убедись, что поведение во время выполнения отделено от CI и разработки.
Убедись, что уточнения пользователя (или явное отсутствие ответов) учтены.
Убедись, что допущения и открытые вопросы названы явно.
Убедись, что формат отчёта близко соответствует обязательному формату результата, заданному в шаблоне промта: references/prompt-template.md
Запиши итоговый Markdown в файл с именем <repo-or-dir-name>-threat-model.md (используй имя корня репозитория или каталога в рамках задачи, если тебя просили смоделировать подпуть).

Справочные материалы

Обязательный формат результата и полный шаблон промта: references/prompt-template.md
Необязательный список мер защиты и активов: references/security-controls-and-assets.md

Загружай только те справочные файлы, которые тебе нужны. Итоговый результат должен быть кратким, обоснованным и пригодным для проверки.

Перевод: iiuniversitet. Оригинал: https://github.com/openai/skills/tree/main/skills/.curated/security-threat-model, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском

---
name: "security-threat-model"
description: "Repository-grounded threat modeling that enumerates trust boundaries, assets, attacker capabilities, abuse paths, and mitigations, and writes a concise Markdown threat model. Trigger only when the user explicitly asks to threat model a codebase or path, enumerate threats/abuse paths, or perform AppSec threat modeling. Do not trigger for general architecture summaries, code review, or non-security design work."
---

# Threat Model Source Code Repo

Deliver an actionable AppSec-grade threat model that is specific to the repository or a project path, not a generic checklist. Anchor every architectural claim to evidence in the repo and keep assumptions explicit. Prioritizing realistic attacker goals and concrete impacts over generic checklists.

## Quick start

1) Collect (or infer) inputs:
- Repo root path and any in-scope paths.
- Intended usage, deployment model, internet exposure, and auth expectations (if known).
- Any existing repository summary or architecture spec.
- Use prompts in `references/prompt-template.md` to generate a repository summary.
- Follow the required output contract in `references/prompt-template.md`. Use it verbatim when possible.

## Workflow

### 1) Scope and extract the system model
- Identify primary components, data stores, and external integrations from the repo summary.
- Identify how the system runs (server, CLI, library, worker) and its entrypoints.
- Separate runtime behavior from CI/build/dev tooling and from tests/examples.
- Map the in-scope locations to those components and exclude out-of-scope items explicitly.
- Do not claim components, flows, or controls without evidence.

### 2) Derive boundaries, assets, and entry points
- Enumerate trust boundaries as concrete edges between components, noting protocol, auth, encryption, validation, and rate limiting.
- List assets that drive risk (data, credentials, models, config, compute resources, audit logs).
- Identify entry points (endpoints, upload surfaces, parsers/decoders, job triggers, admin tooling, logging/error sinks).

### 3) Calibrate assets and attacker capabilities
- List the assets that drive risk (credentials, PII, integrity-critical state, availability-critical components, build artifacts).
- Describe realistic attacker capabilities based on exposure and intended usage.
- Explicitly note non-capabilities to avoid inflated severity.

### 4) Enumerate threats as abuse paths
- Prefer attacker goals that map to assets and boundaries (exfiltration, privilege escalation, integrity compromise, denial of service).
- Classify each threat and tie it to impacted assets.
- Keep the number of threats small but high quality.

### 5) Prioritize with explicit likelihood and impact reasoning
- Use qualitative likelihood and impact (low/medium/high) with short justifications.
- Set overall priority (critical/high/medium/low) using likelihood x impact, adjusted for existing controls.
- State which assumptions most influence the ranking.

### 6) Validate service context and assumptions with the user
- Summarize key assumptions that materially affect threat ranking or scope, then ask the user to confirm or correct them.
- Ask 1–3 targeted questions to resolve missing context (service owner and environment, scale/users, deployment model, authn/authz, internet exposure, data sensitivity, multi-tenancy).
- Pause and wait for user feedback before producing the final report.
- If the user declines or can’t answer, state which assumptions remain and how they influence priority.

### 7) Recommend mitigations and focus paths
- Distinguish existing mitigations (with evidence) from recommended mitigations.
- Tie mitigations to concrete locations (component, boundary, or entry point) and control types (authZ checks, input validation, schema enforcement, sandboxing, rate limits, secrets isolation, audit logging).
- Prefer specific implementation hints over generic advice (e.g., "enforce schema at gateway for upload payloads" vs "validate inputs").
- Base recommendations on validated user context; if assumptions remain unresolved, mark recommendations as conditional.

### 8) Run a quality check before finalizing
- Confirm all discovered entrypoints are covered.
- Confirm each trust boundary is represented in threats.
- Confirm runtime vs CI/dev separation.
- Confirm user clarifications (or explicit non-responses) are reflected.
- Confirm assumptions and open questions are explicit.
- Confirm that the format of the report matches closely the required output format defined in prompt template: `references/prompt-template.md`
- Write the final Markdown to a file named `<repo-or-dir-name>-threat-model.md` (use the basename of the repo root, or the in-scope directory if you were asked to model a subpath).

## Risk prioritization guidance (illustrative, not exhaustive)
- High: pre-auth RCE, auth bypass, cross-tenant access, sensitive data exfiltration, key or token theft, model or config integrity compromise, sandbox escape.
- Medium: targeted DoS of critical components, partial data exposure, rate-limit bypass with measurable impact, log/metrics poisoning that affects detection.
- Low: low-sensitivity info leaks, noisy DoS with easy mitigation, issues requiring unlikely preconditions.

## References

- Output contract and full prompt template: `references/prompt-template.md`
- Optional controls/asset list: `references/security-controls-and-assets.md`

Only load the reference files you need. Keep the final result concise, grounded, and reviewable.

Источник: openai/skills / security-threat-model ↗. Ссылка проверена 2026-10-10.

---
name: "security-threat-model"
description: "Моделирование угроз по материалам репозитория: перечисляет границы доверия, активы, возможности атакующего, пути злоупотребления и меры защиты и записывает краткую модель угроз в Markdown. Включай, только если пользователь прямо просит смоделировать угрозы для кодовой базы или пути, перечислить угрозы и пути злоупотребления либо выполнить моделирование угроз уровня AppSec. Не включай для общих описаний архитектуры, разбора кода и проектных работ, не связанных с безопасностью."
---

# Модель угроз для репозитория с исходным кодом

Подготовь практичную модель угроз уровня AppSec, специфичную для репозитория или пути проекта, а не общий чек-лист. Каждое утверждение об архитектуре подкрепляй свидетельствами из репозитория и явно называй допущения. Приоритет отдавай реалистичным целям атакующего и конкретным последствиям, а не общим чек-листам.

## Быстрый старт

1) Собери (или выведи) входные данные:
- Путь к корню репозитория и любые пути в рамках задачи.
- Предполагаемое использование, модель развёртывания, доступность из интернета и ожидания по аутентификации (если известны).
- Любое существующее описание репозитория или спецификацию архитектуры.
- Используй промты из `references/prompt-template.md`, чтобы составить описание репозитория.
- Следуй обязательному формату результата из `references/prompt-template.md`. По возможности используй его дословно.

## Рабочий процесс

### 1) Определи рамки и выдели модель системы
- По описанию репозитория определи основные компоненты, хранилища данных и внешние интеграции.
- Определи, как система работает (сервер, CLI, библиотека, воркер), и её точки входа.
- Отдели поведение во время выполнения от инструментов CI, сборки и разработки и от тестов и примеров.
- Сопоставь расположения в рамках задачи с этими компонентами и явно исключи то, что в рамки не входит.
- Не заявляй о компонентах, потоках и средствах защиты без свидетельств.

### 2) Определи границы, активы и точки входа
- Перечисли границы доверия как конкретные связи между компонентами, отмечая протокол, аутентификацию, шифрование, проверку данных и ограничение частоты запросов.
- Перечисли активы, определяющие риск (данные, учётные данные, модели, конфигурация, вычислительные ресурсы, журналы аудита).
- Определи точки входа (эндпоинты, места загрузки файлов, парсеры и декодеры, триггеры заданий, инструменты администрирования, приёмники журналов и ошибок).

### 3) Оцени активы и возможности атакующего
- Перечисли активы, определяющие риск (учётные данные, персональные данные, состояние, критичное для целостности, компоненты, критичные для доступности, артефакты сборки).
- Опиши реалистичные возможности атакующего, исходя из доступности системы и предполагаемого использования.
- Явно отметь то, чего атакующий не может, чтобы не завышать серьёзность.


### 4) Перечисли угрозы как пути злоупотребления
- Предпочитай цели атакующего, которые соответствуют активам и границам (кража данных, повышение привилегий, нарушение целостности, отказ в обслуживании).
- Классифицируй каждую угрозу и свяжи её с затронутыми активами.
- Держи число угроз небольшим, но качественным.

### 5) Расставь приоритеты с явным обоснованием вероятности и последствий
- Используй качественные оценки вероятности и последствий (низкая/средняя/высокая) с краткими обоснованиями.
- Задай общий приоритет (критический/высокий/средний/низкий) по произведению вероятности на последствия с поправкой на существующие меры защиты.
- Укажи, какие допущения сильнее всего влияют на ранжирование.

### 6) Согласуй с пользователем контекст сервиса и допущения
- Кратко изложи ключевые допущения, существенно влияющие на ранжирование угроз или рамки, и попроси пользователя подтвердить или исправить их.
- Задай 1–3 точных вопроса, чтобы восполнить недостающий контекст (владелец сервиса и окружение, масштаб и пользователи, модель развёртывания, аутентификация и авторизация, доступность из интернета, чувствительность данных, мультиарендность).
- Остановись и дождись ответа пользователя, прежде чем готовить итоговый отчёт.
- Если пользователь отказывается или не может ответить, укажи, какие допущения остаются и как они влияют на приоритет.

### 7) Предложи меры защиты и направления для сосредоточения
- Отделяй существующие меры (со свидетельствами) от рекомендуемых.
- Привязывай меры к конкретным местам (компонент, граница или точка входа) и типам средств защиты (проверки авторизации, проверка входных данных, принудительное соблюдение схемы, изоляция в песочнице, ограничения частоты запросов, изоляция секретов, журналы аудита).
- Предпочитай конкретные подсказки по реализации общим советам (например, «принудительно проверять схему на шлюзе для загружаемых данных», а не «проверять входные данные»).
- Основывай рекомендации на подтверждённом контексте пользователя; если допущения остаются неразрешёнными, помечай рекомендации как условные.

### 8) Проведи проверку качества перед завершением
- Убедись, что охвачены все обнаруженные точки входа.
- Убедись, что каждая граница доверия представлена в угрозах.
- Убедись, что поведение во время выполнения отделено от CI и разработки.
- Убедись, что уточнения пользователя (или явное отсутствие ответов) учтены.
- Убедись, что допущения и открытые вопросы названы явно.
- Убедись, что формат отчёта близко соответствует обязательному формату результата, заданному в шаблоне промта: `references/prompt-template.md`
- Запиши итоговый Markdown в файл с именем `<repo-or-dir-name>-threat-model.md` (используй имя корня репозитория или каталога в рамках задачи, если тебя просили смоделировать подпуть).


## Рекомендации по расстановке приоритетов рисков (для иллюстрации, не исчерпывающие)
- Высокий: RCE до аутентификации, обход аутентификации, доступ между арендаторами, кража чувствительных данных, кража ключей или токенов, нарушение целостности моделей или конфигурации, выход из песочницы.
- Средний: целевой DoS критичных компонентов, частичное раскрытие данных, обход ограничения частоты запросов с измеримыми последствиями, отравление журналов и метрик, влияющее на обнаружение.
- Низкий: утечки малочувствительной информации, шумный DoS с простым способом защиты, проблемы, требующие маловероятных предварительных условий.

## Справочные материалы

- Обязательный формат результата и полный шаблон промта: `references/prompt-template.md`
- Необязательный список мер защиты и активов: `references/security-controls-and-assets.md`

Загружай только те справочные файлы, которые тебе нужны. Итоговый результат должен быть кратким, обоснованным и пригодным для проверки.

Перевод: iiuniversitet. Оригинал: https://github.com/openai/skills/tree/main/skills/.curated/security-threat-model, лицензия Apache-2.0. Изменения: перевод на русский язык.