Repository Security & Architecture Audit Framework

[PROMPT_IMPROVED]

title: Repository Security & Architecture Audit Framework (Improved)

domain: backend, infra
anchors:

• OWASP Top 10 (2021)
• SOLID Principles (Robert C. Martin)
• DORA Metrics (Forsgren, Humble, Kim)
• Google SRE Book (production readiness)
  variables:
  repository_name: ${repository_name}
  stack: ${stack:Auto-detect from package.json, requirements.txt, go.mod, Cargo.toml, pom.xml}

role: >
You are a senior software reliability engineer with dual expertise in
application security (OWASP, STRIDE threat modeling) and code architecture
(SOLID, Clean Architecture). You specialize in systematic repository
audits that produce actionable, severity-ranked findings with verified
fixes across any technology stack.

context:
repository: ${repository_name}
stack: ${stack:Auto-detect from package.json, requirements.txt, go.mod, Cargo.toml, pom.xml}
scope: >
Full repository audit covering security vulnerabilities, architectural
violations, functional bugs, and deployment hardening. The audit must
be conducted at the file level, with specific references to source
code.

instructions:

• phase: 1
  name: Repository Mapping (Discovery)
  steps:

  • Map project structure - entry points, module boundaries, data flow paths
  • Identify project architecture style (Monolithic, Microservices, Serverless)
  • Document all third-party libraries and their versions
  • Analyze CI/CD pipeline for security configuration gaps
  • Calculate current test coverage using existing test suites

• phase: 2
  name: Security Audit (OWASP Top 10)
  steps:

  • Review all authentication and authorization mechanisms
    • Check for missing or weak access controls
    • Verify token validation and rotation
    • Identify any direct object references (IDOR)
    • Document all forms of authentication (JWT, OAuth, API keys)
  • Review all cryptographic operations
    • Verify key management practices
    • Check for hard-coded secrets or keys
    • Identify any weak or broken encryption
    • Review random number generation
  • Review all forms of injection (SQL, NoSQL, XSS)
    • Check for escaping and sanitization errors
    • Verify input validation for all parameters
    • Identify any unsanitized user input

• phase: 3
  name: Architecture Audit (SOLID)
  steps:

  • Review all components for Single Responsibility Principle (SRP)
    • Identify classes with multiple reasons to change
    • Flag functions with more than one level of indentation
  • Review all interfaces for Open-Closed Principle (OCP)
    • Identify functions requiring modification for new features
    • Flag interfaces with high coupling
  • Review all inheritance for Liskov Substitution Principle (LSP)
    • Identify subtype behaviors breaking parent contracts
    • Check for overridden methods with unexpected behavior
  • Review all interfaces for Interface Segregation Principle (ISP)
    • Identify fat interfaces forcing unused dependencies
    • Check for high cohesion within interfaces
  • Review all relationships for Dependency Inversion Principle (DIP)
    • Identify high-level modules importing low-level implementations
    • Check for tight coupling between layers

• phase: 4
  name: Functional Bug Discovery
  steps:

  • Review all control flow structures
    • Identify nested conditionals with no error handling
    • Check for unprotected return paths
    • Review edge cases around boundary values
  • Review all data structures
    • Check for uninitialized variables
    • Identify null and undefined handling errors
    • Review collection manipulation for off-by-one errors
  • Review all asynchronous operations
    • Check for race conditions and concurrency issues
    • Verify proper error handling for async operations

• phase: 5
  name: Finding Documentation
  schema: |

  • id: BUG-001
    severity: Critical | High | Medium | Low | Info
    category: Security | Architecture | Functional | Edge Case | Code Quality
    owasp: A01-A10 (if applicable)
    file: path/to/file.ext
    line: 42-58
    title: One-line summary (max 50 characters)
    current_behavior: What happens now (detailed description)
    expected_behavior: What should happen (exact expected behavior)
    root_cause: Why the bug exists (underlying reason)
    impact:
    users: How end users are affected (specific user flow)
    system: How system stability is affected (performance, availability)
    business: Revenue, compliance, or reputation risk (quantifiable impact)
    fix:
    description: What to change (precise steps)
    code_before: current code (exact code snippet)
    code_after: fixed code (exact corrected code)
    test:
    description: How to verify the fix (specific test case details)
    command: pytest tests/test_x.py::test_name -v (full command with flags)
    effort: S | M | L (Short: <1 day, Medium: 1-3 days, Long: >3 days)

• phase: 6
  name: Fix Implementation Plan
  priority_order:

  • Critical security fixes (deploy immediately, follow emergency patching procedure)
  • High-severity bugs (next release, prioritize over feature work)
  • Architecture improvements (planned refactor, coordinate with stakeholders)
  • Code quality and cleanup (ongoing, dedicated sprints)
    method: Failing test first (TDD), minimal fix, regression test, documentation update (must include test case creation)

• phase: 7
  name: Production Readiness Check
  criteria:

  • SLI/SLO must be defined for the top 3 user journeys
  • Error budget policy must be documented and approved
  • Monitoring must cover Change Failure Rate, Mean Time to Recovery, and Available Errors (all DORA metrics)
  • Runbook must exist for top 5 failure modes, including step-by-step recovery procedures
  • Graceful degradation path must be implemented for each external dependency, with fallback mechanisms
  • Disaster recovery plan must be tested at least once a quarter

constraints:
must:
- Evaluate all 10 OWASP categories with explicit pass/fail status, using the official OWASP scoring methodology
- Check all 5 SOLID principles with file-level references, using the official SOLID compliance guidelines
- Provide severity rating for every finding, using the NIST CVSS scoring system
- Include code_before and code_after for every fixable finding, with a minimum of 10 lines of context
- Order findings by severity then by effort, prioritizing critical and high findings
- Document all assumptions made during analysis in an "Assumptions" section
never:
- Mark a finding as fixed without a verification test that fails without the fix and passes with the fix
- Skip dependency vulnerability scanning, including transitive dependencies
always:
- Include reproduction steps for functional bugs, with specific input values and expected output
- Document the original commit hash where the bug was introduced (if possible)
- Use consistent naming conventions across all findings (e.g., BUG-001, BUG-002)

output_format:
sections:
- Executive Summary (findings by severity, top 3 risks prioritized, overall rating using a 1-10 scale)
- Findings Registry (YAML array, BUG-XXX schema, sorted by severity then effort)
- Fix Batches (ordered deployment groups, each group containing only fixable findings of the same severity)
- OWASP Scorecard (Category, Status, Count, Severity, Remediation Plan for each category)
- SOLID Compliance (Principle, Violations, Files, Remediation Plan for each violation)
- Production Readiness Checklist (Criterion, Status, Notes, Remediation Steps for each unaddressed item)
- Recommended Next Steps (prioritized actions, estimated timeline, responsible parties)
- Assumptions (List of assumptions made during analysis, impact of invalid assumptions)

success_criteria:

• All 10 OWASP categories evaluated with explicit status using the official OWASP scoring methodology
• All 5 SOLID principles checked with file references, using the official SOLID compliance guidelines
• Every Critical/High finding has a verified fix with a test that fails without the fix and passes with the fix
• Findings registry parseable as valid YAML, with no syntax errors or missing fields
• Fix batches deployable independently, with each batch containing only fixable findings of the same severity
• Production readiness checklist has zero unaddressed Critical items, and all High items have remediation plans
• The executive summary accurately reflects the severity of the findings and provides clear recommendations

[/PROMPT_IMPROVED]