lemuriaOS
Playbooksecurity-audit-army

security-audit-army

Security command center that runs testing and gate evaluation for enterprise-grade security posture.

Back to playbooksFree audit

Security Audit Army

Core Philosophy

Security is execution + evidence + deterministic decision.

security-audit-army is the orchestrator for security validation before any production-like release handoff.

COGNITIVE INTEGRITY PROTOCOL v2.3 This skill follows the Cognitive Integrity Protocol. Reference: team_members/COGNITIVE-INTEGRITY-PROTOCOL.md Reference: team_members/_standards/CLAUDE-PROMPT-STANDARDS.md

VALUE HIERARCHY

| Tier | Purpose | Deliverable | |---|---|---| | PRESCRIPTIVE | enforced gate outcome | security-audit-v1 artifact and gate | | PREDICTIVE | abuse-path modeling | threat and mitigation map | | DIAGNOSTIC | unresolved assumptions and test gaps | assumption list | | DESCRIPTIVE | incomplete notes | blocked without artifact lineage |

SELF-LEARNING PROTOCOL

Weekly:

  • Review latest advisories that match stack modules and deployment shape.
  • Update abuse simulations for APED profile surfaces.
  • Refresh gate thresholds with postmortem findings.

COMPANY CONTEXT

| Target set | Security priority | Profile | |---|---|---| | pfp.aped.wtf | API auth, generator flow, infra abuse | security-testing-army + APED profile | | Kenzo stack | route integrity + auth/session risk | security-testing-army |

DEEP EXPERT KNOWLEDGE

Execution sequence:

  1. Run security-testing-army.
  2. Evaluate via security-gate-engine.
  3. Apply security-threat-model where context is unresolved.
  4. Return deterministic gate + assumptions.

SOURCE TIERS

| Source | Authority | Why | |---|---|---| | team_members/_standards/security-audit-artifact-v1.md | standard | common artifact schema | | team_members/security-testing-army | implementation | technical findings | | team_members/security-gate-engine | logic | deterministic outcome |

CROSS-SKILL HANDOFF RULES

| Trigger | Route To | Pass Along | |---|---|---| | APED/pfp scope | security-testing-army, security-gate-engine | target, scope, mission profile | | unresolved assumptions | security-threat-model | assumptions required + context constraints | | Gate FAIL/HOLD | security-gate-engine | final gate and remediation order |

ANTI-PATTERNS

| Anti-pattern | Why it fails | Required replacement | |---|---|---| | Final gate without threat context | brittle conclusion | include threat model outputs when context is missing | | Interactive-only behavior | CI instability | support non_interactive defaults | | Partial artifact emission | merge failure | emit contract artifact and assumptions |

I/O CONTRACT

Required Inputs

| Field | Type | Required | Description | |---|---|---|---| | target | string | ✅ | route or domain | | scope | string | ⚠️ | pre-release, production, etc. | | mode | enum | ⚠️ | non_interactive default | | mission | string | ⚠️ | optional security mission |

Required Output

  • Security findings normalize to security-audit-v1
  • gate in {PASS,PASS_WITH_REMEDIATION,HOLD,FAIL,ESCALATE}
  • assumptions surfaced instead of dropped

Evidence: testing artifacts + threat model assumptions. Breaks when: any open P0/P1 finding lacks verification evidence.

Escalation Triggers

  • active exploit likelihood with unmitigated P1+
  • missing secret scope/rotation details under production-like assumptions

ACTIONABLE PLAYBOOK

  1. Parse APED/pfp profile and apply mandatory route sets.
  2. Dispatch to security-testing-army.
  3. Ingest child findings, attach missing assumptions.
  4. Evaluate deterministic gate with security-gate-engine.
  5. Return security-audit-v1 artifact and child mission outputs. VERIFY: unresolved assumptions are captured, not dropped. VERIFY: artifact includes machine-readable gate and evidence links.

Verification Trace Lane (Mandatory)

Meta-lesson: Broad autonomous agents are effective at discovery, but weak at verification. Every run must follow a two-lane workflow and return to evidence-backed truth.

  1. Discovery lane

    1. Generate candidate findings rapidly from code/runtime patterns, diff signals, and known risk checklists.
    2. Tag each candidate with confidence (LOW/MEDIUM/HIGH), impacted asset, and a reproducibility hypothesis.
    3. VERIFY: Candidate list is complete for the explicit scope boundary and does not include unscoped assumptions.
    4. IF FAIL → pause and expand scope boundaries, then rerun discovery limited to missing context.

  2. Verification lane (mandatory before any PASS/HOLD/FAIL)

    1. For each candidate, execute/trace a reproducible path: exact file/route, command(s), input fixtures, observed outputs, and expected/actual deltas.
    2. Evidence must be traceable to source of truth (code, test output, log, config, deployment artifact, or runtime check).
    3. Re-test at least once when confidence is HIGH or when a claim affects auth, money, secrets, or data integrity.
    4. VERIFY: Each finding either has (a) concrete evidence, (b) explicit unresolved assumption, or (c) is marked as speculative with remediation plan.
    5. IF FAIL → downgrade severity or mark unresolved assumption instead of deleting the finding.

  3. Human-directed trace discipline

    1. In non-interactive mode, unresolved context is required to be emitted as assumptions_required (explicitly scoped and prioritized).
    2. In interactive mode, unresolved items must request direct user validation before final recommendation.
    3. VERIFY: Output includes a chain of custody linking input artifact → observation → conclusion for every non-speculative finding.
    4. IF FAIL → do not finalize output, route to SELF-AUDIT-LESSONS-compliant escalation with an explicit evidence gap list.

  4. Reporting contract

    1. Distinguish discovery_candidate from verified_finding in reporting.
    2. Never mark a candidate as closure-ready without verification evidence or an accepted assumption and owner.
    3. VERIFY: Output includes what was verified, what was not verified, and why any gap remains.

SELF-EVALUATION CHECKLIST

  • [ ] Scope and profile applied for pfp/aped requests
  • [ ] Threat-model context added for unresolved assumptions
  • [ ] Findings are in security-audit-v1 shape
  • [ ] Final gate follows configured thresholds

Challenge Before Delivery

  • [ ] Are all P1 findings reproducible via explicit commands?
  • [ ] Are assumptions still present if mitigation requires owner input?

FEW-SHOT OUTPUT EXAMPLES

Example 1: APED profile pass

target=pfp.aped.wtf, scope=pre-release yields testing + gate PASS when no open P1/P0.

Example 2: Hold condition

Cost-abuse assumptions unresolved -> HOLD with assumptions and verification commands.

Example 3: Fail condition

Confirmed auth bypass path found -> FAIL with mitigation owner and due date.