tools-only Executive Summary
Software engineering is currently undergoing a major paradigm shift—from waterfall development to agile iteration to AI-assisted programming. This transformation affects philosophy, processes, and technology alike. Security engineering must adapt accordingly, evolving from "document-driven, phase-separated" to "code-driven, verification-closed-loop," and from "gate-based, external tooling" to "extreme shift-left, rapid iteration."
Chapter 1: The Role of SDL and Security Processes in Traditional Software Lifecycles
1.1 Theory and Practice of the Security Development Lifecycle (SDL)
The traditional Security Development Lifecycle (SDL) embeds security into each phase of software development. This methodology originated from Microsoft's "Trustworthy Computing" initiative launched in 2002 in response to worms like Code Red and Nimda. The core insight was: security must be built into products from the design phase, not remediated afterward.
In the theoretical SDL model, each phase carries distinct security responsibilities:
Requirements Analysis Phase: Teams identify compliance requirements (e.g., data protection regulations, industry security standards) and define security features (e.g., identity and permission isolation, encryption algorithm strength, authentication mechanisms, audit logging). Since concrete system design is absent at this stage, security work remains at the level of principled declarations.
Design Phase: In SDL theory, this is the primary phase for Threat Modeling. Architects and security experts review system architecture diagrams, attempting to identify potential design flaws before coding begins. The STRIDE model developed by Microsoft is a key methodology for this phase.
Implementation Phase: Static Application Security Testing (SAST) and secure coding standards are introduced. Experienced developers apply secure design patterns following coding standards, IDEs use security plugins for real-time vulnerability pattern detection, and SAST tools perform periodic weakness scanning at designated checkpoints. However, these tools are essentially pattern matchers—they can capture specific dangerous patterns (e.g., unsafe use of strcpy), but struggle to assess actual risk in business process contexts, especially complex business logic vulnerabilities.
Verification Phase: Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), and manual penetration testing are executed at this stage. While these techniques can identify real issues, defects discovered when products near completion incur higher remediation costs. In practice, positional conflicts often create friction between development and security teams.
Release and Response Phase: Runtime monitoring, security incident response, and vulnerability patching. Issues discovered at this stage stem from insufficient threat coverage during the design phase, while remediation costs and derivative risks are significantly amplified.
1.2 Security Activity Insertion Points in Traditional Development Processes
Understanding the design assumptions of traditional SDL requires analyzing the time distribution characteristics of traditional development processes:
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ Time Distribution of Traditional Software Development │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ Requirements Design Implementation (Coding) Verification (Testing) Release│
│ ├──────────┼─────────────┼───────────────────────┼─────────────────────────┼────┤ │
│ │ 15% │ 20% │ 30% │ 30% │ 5% │ │
│ │ │ │ │ │ │ │
│ │ │ │ ┌───────────────────────────────────┐ │ │ │
│ │ │ │ │ Primary Iteration Cycle │ │ │ │
│ │ │ │ │ (Coding ↔ Testing) │ │ │ │
│ │ │ │ │ ~60%+ of total development │ │ │ │
│ │ │ │ └───────────────────────────────────┘ │ │ │
│ │ │ │ │ │ │ │
│ ├──────────┼─────────────┼───────────────────────┼─────────────────────────┼────┤ │
│ │ │ Threat │ SAST/Code Review │ IAST/DAST/Pentest/ │ │ │
│ │ │ Modeling │ │ Security Testing │ │ │
│ │ │ (Theory) │ │ (Actual insertion point)│ │ │
│ │ │ │ │ │ │ │
│ └──────────┴─────────────┴───────────────────────┴─────────────────────────┴────┘ │
│ │
│ Key Observations: │
│ ───────────────────────────────────────────────────────────────────────────── │
│ • Threat modeling should theoretically occur during design, but due to limited │
│ actionable information, it is often postponed to the testing phase │
│ • The verification phase (testing) provides adequate time windows, becoming the │
│ primary insertion point for security work │
│ • Security testing, penetration testing, and compliance audits—high-investment │
│ activities—are executed in this phase │
│ • In traditional lifecycles, this "verification phase" time buffer is sufficient │
│ to accommodate security activities │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
Traditional SDL models, built on traditional software engineering methods, assume: development processes have clear phase boundaries where security activities can be executed at specific stages. The verification phase, with its longer duration and clear quality gate role, has become the primary insertion point for security work.
1.3 Overview of the STRIDE Threat Modeling Method
STRIDE, commonly used in threat modeling, was proposed by Microsoft engineers Loren Kohnfelder and Praerit Garg in 1999. It encompasses six threat categories:
| Category | Full Name | Definition | Typical Defense Mechanisms |
|---|---|---|---|
| S | Spoofing | Impersonating another identity for unauthorized access | Authentication, digital signatures, multi-factor verification |
| T | Tampering | Unauthorized modification of data or code | Integrity checks, digital signatures, audit logs |
| R | Repudiation | Denying performed actions | Audit logs, timestamps, non-repudiation signatures |
| I | Information Disclosure | Exposing sensitive information to unauthorized parties | Encryption, access control, data masking |
| D | Denial of Service | Preventing legitimate users from accessing services | Rate limiting, redundancy design, failover |
| E | Elevation of Privilege | Gaining elevated privileges from a low-privilege identity | Least privilege principle, sandboxing, boundary validation |
STRIDE was designed to provide a structured thinking framework that helps non-security experts systematically examine potential threats in designs.
Traditional STRIDE Practice Flow:
- Data Flow Diagram (DFD) Creation: Decompose the system into four element types—external entities, processes, data stores, and data flows—and annotate trust boundaries
- Element-by-Element Threat Enumeration: For each element and interaction in the DFD, systematically pose questions according to the STRIDE model
- Mitigation Design: Design corresponding security controls for identified threats
1.4 Gap Analysis: Theory vs. Practice
STRIDE methodology guides and Microsoft's official documentation state that threat modeling is "most effective when performed during the design phase." However, industry observations reveal: the theoretical model of design-phase threat modeling faces implementation barriers in most organizations.
Primary difficulties in implementing STRIDE:
First, the "design phase" has blurred boundaries in modern development. In agile environments, design and implementation are highly intertwined. A module designed in Sprint 1 may be adjusted in Sprint 3 due to requirement changes, invalidating the original threat model.
Second, effective STRIDE analysis requires specific design information. Abstract architecture diagrams (e.g., "User → Load Balancer → Web Server → Database") cannot support meaningful threat analysis. Only with concrete implementation details (e.g., "JWT used for session management," "database stores plaintext passwords") can threat enumeration produce substantive conclusions. These details are typically determined during implementation.
Finally, resource constraints are a critical bottleneck (and create significant cost increases). Effective STRIDE analysis requires collaboration among architects, developers, and security experts. In fast-paced product development, convening threat modeling analysis and decision meetings for every design decision is impractical. Industry experience shows that fully implementing threat modeling can add 3-5% to overall software costs.
Common Alternative Practice Patterns:
Due to various constraints and issues inherent in traditional SDL and threat modeling, the industry often adopts simplified or alternative approaches:
- Implementation-phase threat modeling: Conducted during or after coding (testing phase) when more concrete system information is available; this is the most common actual scenario
- Sprint-level incremental threat modeling: In agile environments, threat modeling is decomposed into fixed activities within each sprint
- Developer-driven lightweight checklists: Simplified checklists based on STRIDE thinking for developers to self-check during code review
- Threat modeling as code: Using tools like pytm and threagile to define threat models as code
1.5 Limitations Analysis of Code Review
Code review is another important gate security control in traditional SDL. If threat modeling is macro-level architecture audit, Code Review is micro-level implementation verification. In traditional SDL, code review occurs at the end of implementation or as a CI pipeline gate.
However, code review faces the following practical implementation limitations:
Context limitations are the primary obstacle. In microservice architectures, complete business flows may span multiple services involving numerous RPC calls. Reviewers face single-commit diffs (tens to hundreds of lines of code changes) and struggle to construct complete call chains spanning thousands of lines. An input validation function that appears complete may be ineffective if placed after the wrong trust boundary.
Cognitive load limits review depth. Research shows that code review effectiveness significantly decreases beyond 200-400 lines of code. Reviewers easily spot syntax errors or explicit injection vulnerabilities but struggle to detect architecture violations, race conditions, or business logic flaws.
| Dimension | Traditional STRIDE Threat Modeling | Traditional Code Review |
|---|---|---|
| Analysis Object | Design documents, architecture diagrams, DFD | Code changes (Diff/PR) |
| Theoretical Phase | Design phase (early) | Development phase (mid-late) |
| Actual Phase | Often postponed or omitted | CI pipeline gate |
| Core Limitation | Abstraction-implementation gap, insufficient design info | Context missing, cognitive load |
| Resource Dependency | Experts with architecture + offensive/defensive skills | Individual developer security awareness |
| Output Format | Static documents, risk lists | Code comments, modification suggestions |
| Verification Capability | Weak (difficult to automate verification) | Medium (verifiable through testing, limited coverage) |
Chapter 2: Challenges of Traditional SDL Methods: Cognitive Bottlenecks and Validation Gaps
2.1 Synchronization/Consistency Issues Between Documentation and Code
Traditional STRIDE analysis starts from design documents or architecture diagrams. However, software iteration and development are dynamic evolutionary processes. Design documentation begins diverging from actual code at the start of coding (Implementation Drift). As engineering scale grows and code changes accumulate, synchronization gaps widen.
Typical example: A security team performs threat modeling in Q1 based on architect-provided design documents, identifying 15 high-risk threats. By Q3 product launch, technical debt, architecture adjustments, and requirement changes during development cause significant divergence between the actual system and original design. Version differences create "shadow areas" between manually predefined "threat models" and actual running system instances.
Some high-risk vulnerabilities arise precisely from design-implementation gaps. For example, design documentation specifies "all API calls must pass through authentication middleware," but actual implementation may contain debug endpoints that bypass authentication—issues often overlooked in static design document analysis.
2.2 Expert Resource Availability Constraints
Effective STRIDE analysis requires both system architecture understanding and offensive/defensive practical experience. To assess API endpoint privilege escalation risks, analysts must understand:
- Web framework authentication middleware implementation mechanisms
- Common JWT token signature weaknesses (e.g., algorithm confusion attacks)
- RBAC/ABAC access control model implementation pitfalls
- Related historical vulnerabilities (e.g., CVE-2015-9235 JWT None algorithm vulnerability)
Experts combining "architecture vision + offensive/defensive depth" are scarce in the industry. Without qualified personnel and adequate time allocation, threat modeling and code audits often devolve into formalistic checklist filling.
2.3 Missing Verification Closed Loop
Traditional STRIDE output is static threat lists and mitigation recommendations. After development teams apply fixes, how does the security team verify fix effectiveness?
Existing methods generally lack low-cost, automatable verification mechanisms. Threat modeling produces descriptive content ("SQL injection risk exists here") rather than executable test cases ("test this endpoint with ' OR 1=1 -- payload"). The broken identification-remediation-verification chain allows known risks to persist in systems long-term.
2.4 STRIDE's Dependence on Implementation Information
Can STRIDE analysis produce meaningful conclusions without detailed layered design and code implementation?
Traditional static STRIDE analysis faces another issue: the disconnect between security design-assessment-control-verification. "This framework primarily conducts theoretical threat analysis during conceptual design phases, not during post-release security assessment phases." STRIDE's design assumes analysts possess sufficiently specific system information. When information is insufficient, analysis tends toward abstraction—one can say "the user authentication module may face spoofing threats" but cannot identify specific attack paths or vulnerability locations.
2.5 Hidden Dependencies on Process Insertion Points
Traditional SDL and STRIDE methodologies have a latent assumption: development processes have sufficiently long verification phases that provide time windows for security activities.
In traditional development models:
- Coding and testing are separated: Developers write code, testing teams independently execute tests
- Testing phase has adequate time: Verification phase typically occupies 25-35% of project cycles
- Security activities can be embedded in testing phase: Penetration testing, security audits, and compliance checks are executed here
Under this model, even if threat modeling isn't completed during design, security teams still have opportunities to remediate during testing—executing security tests, discovering vulnerabilities, requesting fixes. The testing phase becomes a "buffer zone" for security work.
However, this assumption faces challenges under new development paradigms (see Chapter 3).
Traditional threat modeling faces timing dilemmas:
- Too early: Insufficient design information, analysis becomes abstract
- Too late: Higher remediation costs, missed early intervention opportunities
- Continuous: Lacks automation support, manual costs unsustainable
Chapter 3: Changes and Security Implications from AI-Assisted Programming: Structural Left-Shift of the Development Main Loop
3.1 Programming Paradigm Changes and Main Loop Restructuring
AI-assisted programming tools (GitHub Copilot, Claude Code, etc.) have transformed software development work patterns. These tools significantly reduce the marginal cost of code generation—developers shift from character-by-character coding to describing intent and reviewing AI-generated results. This role change brings substantial increases in development speed and code volume and complexity.
More profound impacts of increasingly powerful and intelligent AI-assisted programming tools on the software ecosystem include: the development process main loop has undergone structural left-shift.
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ Structural Left-Shift of Development Main Loop: Traditional vs AI-Assisted │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ 【Traditional Development Model】 │
│ ─────────────────────────────────────────────────────────────────────────────────── │
│ │
│ Requirements ──► Design ──────► Coding ◄───────────────────► Testing ──► Release │
│ 15% 20% │ │ 5% │
│ │ Main Loop (60%) │ │
│ │ ┌─────────────────────────┐│ │
│ └───►│ Coding ↔ Testing │◄┘ │
│ │ (Manual coding + │ │
│ │ independent testing) │ │
│ └─────────────────────────┘ │
│ ▲ │
│ │ │
│ Security Work Insertion Point: Testing Phase │
│ • Adequate time windows │
│ • Clear phase boundaries │
│ • Can accommodate high-investment activities │
│ │
│ ═══════════════════════════════════════════════════════════════════════════════════ │
│ │
│ 【AI-Assisted Development Model (Vibe Coding)】 │
│ ─────────────────────────────────────────────────────────────────────────────────── │
│ │
│ Requirements/Intent ◄─────────────────────────────────► Code Generation ──► Release│
│ │ Main Loop (70%+) │ 5% │
│ │ ┌─────────────────────────────────┐ │ │
│ └────────►│ Requirements/Design ↔ Code+Test│◄─────────────┘ │
│ │ (Intent description → AI │ │
│ │ generation → Review) │ │
│ │ Testing embedded in coding, │ │
│ │ not independent phase │ │
│ └─────────────────────────────────┘ │
│ ▲ │
│ │ │
│ Traditional Security Work Insertion Point? │
│ • Testing phase compressed/disappeared │
│ • Phase boundaries blurred │
│ • Cannot accommodate long-cycle security activities │
│ │
│ ═══════════════════════════════════════════════════════════════════════════════════ │
│ │
│ 【Structural Change Analysis】 │
│ ─────────────────────────────────────────────────────────────────────────────────── │
│ │
│ ┌────────────────┬────────────────────┬────────────────────────────────────────┐ │
│ │ Dimension │ Traditional Model │ AI-Assisted Model │ │
│ ├────────────────┼────────────────────┼────────────────────────────────────────┤ │
│ │ Main loop │ Coding ↔ Testing │ Requirements/Design ↔ Code │ │
│ │ Testing phase │ Independent phase, │ Embedded in coding, │ │
│ │ │ adequate time │ automated execution │ │
│ │ Phase boundaries│ Clear │ Blurred │ │
│ │ Iteration cycle│ Days/weeks │ Minutes/hours │ │
│ │ Security │ Testing phase │ Disappeared or fragmented │ │
│ │ insertion point│ (clear) │ │ │
│ │ Security work │ Batch, periodic │ Requires real-time, continuous │ │
│ │ mode │ │ │ │
│ └────────────────┴────────────────────┴────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
The Imminent Transformation: Main Loop Left-Shifts from "Coding↔Testing" to "Requirements/Design↔Code"
In the traditional model, developers' primary work was writing code and verifying through tests. Coding and testing were relatively independent activities, executed by different personnel or at different times. This separation provided natural insertion points for security work—during the testing phase, security teams had time and opportunity to execute threat modeling, penetration testing, and security audits.
In the AI-assisted model (Vibe Coding):
- Coding costs drastically reduced: Developers describe intent, AI generates code
- Testing embedded in coding process: AI-generated code typically includes tests, or developers immediately run tests for verification
- Main loop left-shifts: Developers' primary work becomes "describing requirements/design" and "reviewing/adjusting AI-generated code"
- Traditional testing phase compressed: Independent, long-cycle testing phases are compressed or disappear entirely
This structural change leads to: traditional security work loses appropriate process insertion points and gate positions.
3.2 The Crisis of Security Workflow Embedding
Traditional security activities were designed assuming: there exists a sufficiently long phase (typically testing) that can accommodate the following work:
| Security Activity | Typical Time Investment | Traditional Insertion Point | Status in AI-Assisted Model |
|---|---|---|---|
| Threat Modeling | 1-3 days/module | Design/Testing phase | Phase boundaries blurred, difficult to schedule |
| Security Code Review | 2-4 hours/PR | Development phase | Code generation speed exceeds review capacity |
| Penetration Testing | 1-4 weeks/system | Testing phase | Testing phase compressed |
| Security Audit | 2-4 weeks/project | Pre-release | Release cycles compressed |
| Compliance Check | 1-2 weeks/project | Testing/Release phase | Insufficient time windows |
When the development main loop left-shifts, these security activities dependent on "testing phase time windows" face structural challenges:
- Time windows disappear: Extensive test automation and further process-coding integration eliminate the complete "testing phase"
- Speed mismatch: AI generates modules in minutes, traditional security activities require days/weeks
- Process fragmentation: Security activities cannot find appropriate insertion points
- Personnel bottleneck: Security experts cannot keep pace with code generation speed
3.3 Structural Gap in Security Response Speed
Traditional security processes were designed around manual coding speeds. Threat modeling meetings require hours of expert discussion; SAST scan reports require days of manual review; penetration testing cycles are measured in weeks. Under past coding speeds, these cycles were acceptable.
When AI increases coding speed by an order of magnitude, the response speed gap of security measures becomes significant:
- Insufficient real-time capability: When AI generates new modules in minutes, traditional "convene experts, schedule meetings, whiteboard drawings" threat modeling processes cannot be embedded in CI/CD pipelines
- AI generation risks: AI may "hallucinate" non-existent dependency packages (Package Hallucination), or reuse outdated, vulnerable code patterns from training data (e.g., hardcoded credentials, deprecated encryption algorithms)
- Business logic understanding gap: AI-generated code may be syntactically correct but have business logic flaws (e.g., correctly implementing payment deduction logic but ignoring negative amount boundary cases)
3.4 Non-Linear Growth of Code Complexity
This productivity improvement carries security-related costs: non-linear growth of code complexity.
AI models tend to generate structurally complete, fully functional code, but may introduce libraries, patterns, and dependencies that developers don't fully understand. A single requirement may generate hundreds of lines of code involving multiple third-party library interactions. The system's attack surface expands while developers may lack awareness of security implications within.
3.5 Systemic Challenges Facing Traditional Threat Modeling
Synthesizing the above analysis, challenges facing traditional STRIDE and threat modeling methods in AI-assisted programming environments can be summarized as:
| Challenge Dimension | Specific Manifestation | Root Cause |
|---|---|---|
| Process embedding crisis | Cannot find appropriate execution timing | Main loop left-shift, testing phase compression |
| Speed mismatch | Analysis speed far below generation speed | Human-driven vs. AI-driven |
| Expert bottleneck | Expert numbers cannot match code growth | Limited security talent supply |
| Methodology obsolescence | Underlying assumptions (phase separation) no longer hold | Designed for traditional development processes |
Core Problem: Traditional threat modeling methodologies were designed for "development processes with clear phase boundaries." When this premise is disrupted by AI-assisted programming, the methodology itself requires restructuring, not just acceleration.
Security systems must possess response speed and understanding depth matching AI generation capabilities—this is precisely the design objective of the skill-threat-modeling project.
Chapter 4: Architecture and Design Principles of skill-threat-modeling
Design Philosophy: LLM Autonomous Drive and the "Context, not Control" Principle
To address the research and development transformation wave and new challenges brought by Vibe Coding, we designed this automated toolset named skill-threat-modeling. skill-threat-modeling is an open-ended Agent Skillset that can easily be transformed into equivalent Agent workflows. Its core knowledge base system can also supplement and support other AI-driven systems.
The core design philosophy of skill-threat-modeling can be summarized as: LLM autonomous drive, context empowerment, open workflow, integrated knowledge system. This philosophy differs from traditional security tools' "rule-driven, mandatory constraint" patterns.
Traditional security tools typically adopt a "control" paradigm: predefined detection rules, mandatory process execution, fixed-format report output. Tool capability boundaries are determined by rule library coverage. This pattern is effective for handling known patterns but often has limitations facing novel attack vectors or complex business logic.
skill-threat-modeling adopts a knowledge-base-guided intent-aware context paradigm: clarify goals and intentions, provide information reference and guidance, rather than strictly controlling processes. The core philosophy is:
- LLMs possess reasoning capabilities: Large language models like Claude have code comprehension, logical reasoning, and attack path construction capabilities. The Skill's role is not to replace these capabilities but to enhance and guide them;
- Context defines objectives: Each phase's Skill provides intent definition, knowledge reference, and output expectations for that phase, not step-by-step operational instructions;
- Knowledge base empowers decisions: Security knowledge bases (CWE, CAPEC, ATT&CK, etc.) serve as reference resources for LLM flexible querying and citation, not mandatory mapping rules;
Practical implications of the "Context, not Control" principle:
| Dimension | Control Mode | Context Mode |
|---|---|---|
| Execution logic | Predefined rule-driven | LLM reasoning-driven |
| Process constraints | Mandatory step sequences | Phase objective-oriented |
| Knowledge application | Rule library matching | Knowledge base query reference |
| Output format | Fixed templates | Structured but flexible |
| Extension capability | Depends on rule updates | Depends on LLM reasoning |
This design enables skill-threat-modeling to adapt to various technology stacks and business scenarios. For example, facing a project using an uncommon framework, traditional rule-based tools might fail due to lacking corresponding rules; while the Context mode Skill can complete analysis through LLM's semantic understanding of the code.
The core architecture of skill-threat-modeling is based on First Principles—stripping away existing forms to analyze the essence of problems.
4.1 Design Strategies for Addressing Development Main Loop Left-Shift
Based on Chapter 3's analysis, skill-threat-modeling proposes the following design strategies for the "development main loop left-shift" problem:
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ skill-threat-modeling Design Strategies for Main Loop Left-Shift │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ 【Problems with Traditional Security Work】 │
│ ─────────────────────────────────────────────────────────────────────────────────── │
│ • Depends on independent testing phase as insertion point │
│ • Human-driven, slow response speed │
│ • Batch execution, cannot be continuous │
│ • Disconnected from development workflow │
│ │
│ 【skill-threat-modeling Design Responses】 │
│ ─────────────────────────────────────────────────────────────────────────────────── │
│ │
│ ┌────────────────────────────────────────────────────────────────────────────┐ │
│ │ Strategy 1: Synchronize with Code (Code-First) │ │
│ │ ──────────────────────────────────────────────────────────────────────── │ │
│ │ • Analyze source code directly, don't wait for design documents │ │
│ │ • Threat modeling can execute immediately after code generation │ │
│ │ • No dependency on independent testing phase │ │
│ │ • Can embed in AI programming environment's real-time workflow │ │
│ └────────────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────────────────────────┐ │
│ │ Strategy 2: AI-Driven Analysis (LLM Autonomous) │ │
│ │ ──────────────────────────────────────────────────────────────────────── │ │
│ │ • Use AI to analyze AI-generated code │ │
│ │ • Response speed matches code generation speed │ │
│ │ • No need for human experts' full participation │ │
│ │ • Can be automated, continuously executable │ │
│ └────────────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────────────────────────┐ │
│ │ Strategy 3: Integrate into New Main Loop (Integrated Workflow) │ │
│ │ ──────────────────────────────────────────────────────────────────────── │ │
│ │ • Adapt to "Requirements/Design ↔ Code" new main loop │ │
│ │ • Can trigger immediately after code generation │ │
│ │ • Support incremental analysis and continuous threat modeling │ │
│ │ • Output can directly guide next round of code generation │ │
│ └────────────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────────────────────────┐ │
│ │ Strategy 4: Knowledge Density Enhancement (Knowledge Density) │ │
│ │ ──────────────────────────────────────────────────────────────────────── │ │
│ │ • Encode scattered security expert knowledge into structured, │ │
│ │ strongly-logical knowledge bases │ │
│ │ • Reduce dependency on scarce expert experience │ │
│ │ • Improve analysis efficiency through knowledge reuse │ │
│ │ • Ensure consistency of analysis quality │ │
│ └────────────────────────────────────────────────────────────────────────────┘ │
│ │
│ 【New Security Work Embedding Model】 │
│ ─────────────────────────────────────────────────────────────────────────────────── │
│ │
│ Requirements/Intent ◄───────────────────────────────► Code Generation ──► Release │
│ │ Main Loop │ │
│ │ ┌─────────────────────────────────┐ │ │
│ └────────►│ Requirements/Design ↔ Code+Test│◄─────────┘ │
│ │ ▲ │ │ │
│ │ │ │ │ │
│ │ │ ▼ │ │
│ │ ┌────────────────────┐ │ │
│ │ │ skill-threat- │ │ │
│ │ │ modeling │ │ │
│ │ │ (Real-time/ │ │ │
│ │ │ Continuous Threat │ │ │
│ │ │ Analysis) │ │ │
│ │ └────────────────────┘ │ │
│ └─────────────────────────────────┘ │
│ │
│ Security work insertion point: Synchronized with code generation, │
│ integrated into main loop │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
4.2 Code as Primary Analysis Object (Code-First Principle)
The main problem with traditional threat modeling is the disconnect between analysis objects (design documents) and actual systems (running code). Code itself is the single source of truth for system state.
From this follows: all architecture diagrams, data flow diagrams (DFD), and trust boundaries should be real-time mappings of code—derived information from code, not manually drawn static images. When code changes, derived information should automatically update.
skill-threat-modeling doesn't depend on user-provided design documents but directly scans project sou
…(truncated)