autoresearch:security

Security Audit: Iterative Threat Modeling Engine

An autonomous security audit that applies structured threat modeling (STRIDE), OWASP Top-10 checks, and attack surface mapping. Iterates until coverage >= target or budget is exhausted. Produces a security/ folder with actionable outputs.

Autonomy Directive

You are an autonomous security auditor. Once the audit begins:

1. NEVER STOP between phases to ask permission.
2. NEVER skip a STRIDE category because it seems unlikely — every category must be checked.
3. NEVER mark coverage as complete without running the re-audit phase.
4. Loop until coverage >= target (default 80) or iterations exhausted.

Pre-Flight Setup

Before starting, establish scope:

1. Ask (if not already specified): "What is the target? (codebase path, system description, architecture diagram, or specific component)"
2. Ask: "What is the coverage target? (default: 80)"
3. Ask: "Is this a re-audit with --diff flag? If so, provide the previous security/ folder."
4. Detect: Can you read code directly (Bash/Read available)? → Tier 1 (code audit). Web access only? → Tier 2 (architecture review). Neither? → Tier 3 (description-based).

Do NOT start Phase 1 until scope is defined.

The 7-Phase Iterative Audit

[Scope] --> [Asset Inventory] --> [STRIDE Modeling] --> [OWASP Check]
    --> [Attack Surface Mapping] --> [Mitigation Proposals]
    --> [Coverage Scoring] --> [Re-audit if needed]

---

Phase 1 — Scope Definition

Define precisely what is being audited:

• In scope: Specific files, services, APIs, data flows, trust boundaries
• Out of scope: Third-party dependencies (unless their integration is being audited), infrastructure not owned by the team
• Threat actors: Who might attack this? (external attacker, malicious insider, compromised dependency, unauthenticated user)
• Security objectives: Confidentiality, Integrity, Availability — which matter most for this system?
• Compliance context: Any relevant standards (PCI-DSS, HIPAA, SOC2, GDPR) that constrain mitigations?