菜单
Analyze mixed repositories (application code + infrastructure + policies + docs) to extract ALL components for ONE unified threat model. Use when analyzing codebases with multiple source types for threat modeling. Architecture modeling only - do NOT identify vulnerabilities.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Step-by-step instructions for creating IriusRisk threat models (OTM files). Use when creating or updating threat models. Covers validation, component mapping, trust zones, and complete workflow from analysis to import.
Detailed guidance on OTM component layout and positioning. Use when creating initial layouts from scratch or updating existing layouts. Covers component sizes, spacing, nesting hierarchies, and cascading size calculations.
Analyze source code to answer IriusRisk questionnaires that refine threat models based on actual implementation. Use after creating threat model to reduce false positives and improve accuracy. Requires thorough code analysis.
Trigger point for architecture, design, or system structure reviews. Use when user asks to review architecture, design, or understand system structure. Guides you to check for existing threat models first.
Complete workflow instructions for IriusRisk threat modeling. Use when starting any threat modeling task. Provides decision logic for using existing threat models, creating new ones, and when to ask permission.
Help developers assess security impact of their work and recommend threat modeling when appropriate. Use when developer is planning changes or asks about security. Respects autonomy and workflow while providing guidance.
| name | analyze-source-material |
| description | Analyze mixed repositories (application code + infrastructure + policies + docs) to extract ALL components for ONE unified threat model. Use when analyzing codebases with multiple source types for threat modeling. Architecture modeling only - do NOT identify vulnerabilities. |
Analyze mixed repositories (application code + infrastructure + policies + docs) to extract ALL components for ONE unified threat model. Your role: architecture modeling only—extract components, trust zones, and data flows. Do NOT identify vulnerabilities or security flaws; IriusRisk handles that automatically. Create a single comprehensive threat model covering all layers.
Create ONE unified threat model including ALL components from ALL source types. Do NOT create separate models for code vs. infrastructure—IriusRisk works best with a complete, holistic view of the entire system.
FIRST: Check for repository scope definition in .iriusrisk/project.json:
{
"name": "E-commerce Platform",
"reference_id": "ecommerce-platform",
"scope": "AWS cloud infrastructure via Terraform. Provisions ECS for backend API
(api-backend repo), RDS PostgreSQL, ALB, CloudFront for frontend static
assets (web-frontend repo). All application components from other repos
should run within these AWS services."
}
Your analysis must be FOCUSED on the scope:
Understand the scope boundaries:
Focus your component extraction:
Scope-specific extraction strategies:
Infrastructure scope (e.g., "AWS infrastructure", "Kubernetes platform"):
Application scope (e.g., "Backend API", "Payment service"):
Frontend scope (e.g., "React SPA", "Mobile app"):
Use comprehensive, all-encompassing analysis:
Do: Extract components, trust zones, and data flows
Do NOT: Identify vulnerabilities, threats, security flaws, or speculate about weaknesses
Why: IriusRisk performs all security analysis automatically
When analyzing source code, you will inevitably notice security issues (SQL injection, weak crypto, etc.). DO NOT add these as tags to components or dataflows.
Tags describe the NATURE and PURPOSE of components:
components:
- id: "payment-api"
name: "Payment Service"
tags:
- "payment-processing" # ✅ Business function
- "pci-dss-scope" # ✅ Compliance relevance
- "customer-data" # ✅ Data sensitivity
- "public-facing" # ✅ Network exposure
NEVER add tags for vulnerabilities you find in code:
# ❌ DO NOT DO THIS - Even if you find these issues in source code
components:
- id: "flask-app"
tags:
- "sql-injection-vulnerable" # ❌ NO! This is a threat
- "insecure-deserialization" # ❌ NO! This is a vulnerability
From source code, APIs, microservices:
From databases, data flows, storage systems:
From Terraform, cloud configurations, network diagrams:
From cloud provider configurations:
From API configurations, message queues, external services:
Identify all source types in the repository:
Catalog components by source type:
From Application Code: Extract business logic (auth services, business domain services, API endpoints, background jobs). Extract components separately from infrastructure—they'll be nested within infrastructure components (containers, VMs).
From Infrastructure Code (Terraform/CloudFormation): Extract cloud resources, security groups/ACLs, load balancers, database instances, monitoring configs, IAM roles.
From Security Policies/Documentation: Identify required controls, compliance frameworks, data classification, network segmentation policies.
From Configuration/Deployment Files: Discover container definitions, orchestration, environment configs, CI/CD pipelines, monitoring/observability.
1. Merge overlapping components: Consolidate same logical component appearing in multiple sources into one with comprehensive properties.
2. Plan nesting hierarchy:
3. Establish relationships: Nesting (business logic within infrastructure), data flows (between components and data stores), network connections (between infrastructure).
4. Define trust zones:
⚠️ IMPORTANT: Always call sync() before creating or modifying the OTM, even if .iriusrisk/current-threat-model.otm already exists locally. The user may have modified the threat model via the IriusRisk web interface since the last sync. Using a stale local file will overwrite their changes.
Result: Single, comprehensive threat model for holistic IriusRisk analysis across all system layers.