Secrets: scan for hardcoded credentials (patterns from references/detection-patterns.md §1)
Compute RASQ (attack surface score):
RASQ = Sum(entry_points x weight x multipliers)
Weights: unauth_http=10, auth_http=5, websocket=8, file_upload=9, webhook=7, server_action=7
Multipliers: handles_PII=x2, internet_facing=x1.5, rate_limited=x0.5, auth_required=x0.7
Phase 2: STRIDE Threat Model
For each entry point and trust boundary, evaluate all 6 STRIDE categories.
Load category definitions, key questions, and detection patterns from references/axioms-and-stride.md.
Category
Violated Property
S Spoofing
Authentication
T Tampering
Integrity
R Repudiation
Non-repudiation
I Info Disclosure
Confidentiality
D Denial of Service
Availability
E Elevation
Authorization
Phase 3: Detection Engine (6 Layers)
Execute in order. Each layer feeds the next.
Layer
What
Reference
1. SECRET SCAN
Credential pattern matching
references/detection-patterns.md §1
2. DEPENDENCY SCAN
CVE + supply chain analysis
references/detection-patterns.md §2
3. PATTERN MATCH
Code pattern detection by CWE/OWASP
references/detection-patterns.md §3
4. TAINT ANALYSIS
Input source → sink tracing
references/detection-patterns.md §4
5. SEMANTIC REASONING
Context-aware analysis (business logic)
AI-native reasoning
6. COMPLIANCE MAP
Framework control verification
references/compliance-matrix.md
Layer 4 traces untrusted inputs through transforms to sensitive sinks. Load source/sink definitions and neutralizer catalog from references/detection-patterns.md §4.
Phase 4: Risk Scoring (5 Dimensions)
RISK = (Severity x 0.8) + (Confidence x 0.4) + (Exploitability x 0.6) + (Prevalence x 0.2)
Range: 2.0 to 10.0
PRIORITY = RISK x FIXABILITY_MODIFIER (F=5: x1.05, F=3: x1.0, F=1: x0.95)
ACTION LEVELS:
8.0-10.0 CRITICAL Block deployment. Fix immediately.
6.0-7.9 HIGH Fix within current sprint.
4.0-5.9 MEDIUM Fix within 30 days.
2.0-3.9 LOW Fix when touching related code.
ID: AEGIS-{STRIDE}-{SEQ} (e.g., AEGIS-T-001)
Title: descriptive name
STRIDE: S|T|R|I|D|E
CWE: CWE-XXX
OWASP: AXX:2021
Location: file:line, function name
Code snippet: vulnerable code
Scoring: S/C/E/P/F = risk_score -> action_level
Attack scenario: 1-2 sentences
Remediation: fix_type (auto|guided|manual) + secure code
Compliance: which CC-XX checks this resolves
CYCLE 2: FIX (Remedy & Verify)
Fix Classification
Type
Criteria
Action
auto
Deterministic transform, Confidence >= 4
Apply fix. Verify.
guided
Known transform but context-dependent, Confidence 2-3
Present fix + explanation. User confirms.
manual
Architectural change or business decision needed
Document. Provide guidance. User implements.
Core Transforms (apply via Edit tool)
Load the full transform catalog from references/detection-patterns.md §5. Each transform maps a CWE pattern to its secure equivalent. Apply transforms using the Edit tool. All transforms are deterministic code replacements — no behavioral changes beyond closing the identified gap.
Verification (after every fix)
Re-scan the pattern that triggered the finding
Run all patterns on the modified file
Verify build succeeds (npm run build or equivalent)
Check for regressions (new findings introduced)
CYCLE 3: HARDEN (Prevent & Monitor)
Security Headers
Load header configurations and implementation details from references/hardening.md §1.
Input Validation
Load Zod schema catalog for common input types from references/hardening.md §2.
Pre-Commit Hooks
Generate pre-commit configuration and secret scanning rules. Load templates from references/devops-artifacts.md §1.
CI/CD Security Pipeline
5 automated workflows for continuous security monitoring. Load YAML definitions from references/devops-artifacts.md §2.
Static Analysis Rules
10 production rules targeting common vulnerability patterns. Load rule definitions from references/devops-artifacts.md §3.
Stack Detection & Module Loading
Auto-detect stack and load relevant module from references/stack-modules.md:
Detection Signal
Module
Checks
next.config.*, app/ dir
Next.js (NX-01..08)
8
firebase.json, firestore.rules
Firebase (FB-01..10)
10
stripe in deps
Stripe (ST-01..06)
6
Dockerfile
Docker (DK-01..07)
7
*.tf files
AWS Terraform (AWS-01..22)
22
google_ in .tf
GCP Terraform (GCP-01..12)
12
K8s manifests (.yaml with apiVersion)
Kubernetes (K8S-01..15)
15
vercel.json
Vercel (VCL-01..06)
6
express in deps
Express.js (EXP-01..22)
22
django in deps/imports
Django (DJ-01..20)
20
fastapi in deps/imports
FastAPI (FA-01..20)
20
AI/LLM & Agentic Detection
If AI/LLM dependencies detected (openai, anthropic, langchain, llamaindex, agent frameworks):
Load references/privacy-and-agentic.md §1 for OWASP LLM Top 10 (AI-01..08) and §2 for OWASP Agentic Top 10 (AG-01..10).
Privacy Detection
If PII handling detected (user data, health data, payment data, EU scope):
Load references/privacy-and-agentic.md §3 for LINDDUN privacy threat model (LN-01..07).
If .aegis/ directory doesn't exist, create it on first audit. If last-audit.json is missing, skip delta — run as first-time audit.
Adversarial Self-Review
Before delivering findings, AEGIS challenges its own analysis:
For each CRITICAL/HIGH finding, ask:
False positive check: "Could this pattern match legitimate, safe code?" — If yes, verify with Layer 5 semantic reasoning. Downgrade or add caveat if context shows the pattern is safe.
Severity challenge: "Am I scoring this high because the pattern looks scary, or because the actual exploitability is high?" — Re-verify the Exploitability dimension (E) with a concrete attack scenario. If you can't construct one in 2 sentences, downgrade E by 1.
Completeness challenge: "Did I miss a compensating control that makes this finding lower risk?" — Check for auth middleware, WAF config, rate limiting, or input validation that might already mitigate.
For the overall report, ask:
"What did I NOT check that could be more dangerous than what I found?" — Name at least 1 blind spot in the Residual Risk section.
"If I were attacking this system, would I exploit any of these findings, or would I look elsewhere?" — This forces prioritization honesty.
Findings that survive self-review are marked confidence: verified. Findings where self-review raised doubt are marked confidence: review-recommended with the specific concern noted.
Quality Gate
Before delivering any audit report, verify:
SCO was built from real file reads, not assumptions (entry points enumerated from code)
Every finding has all required fields (ID, STRIDE, CWE, OWASP, location, snippet, scoring, remediation)
Risk scores are mathematically consistent (formula applied, not eyeballed)
No false positives from pattern matching without context (Layer 5 semantic check applied)
Compliance mappings reference actual framework controls, not invented ones
Auto-fix transforms preserve existing functionality (no breaking changes)
Report follows the 10-section structure completely
If any check fails: fix before delivering. Never ship a report with incomplete findings.
Composability
As standalone: Full audit cycle (detect → fix → harden) for any project
As input to: CI/CD pipelines (use RAPID mode in PR checks), security dashboards, compliance reports
As output from: Project scaffolding tools that generate code needing initial audit
Pairs well with: Code review skills, deployment workflows, compliance tracking systems
In workflows: Can be step 03-security-gate in any release workflow — blocks deploy if CRITICAL findings exist
