security-audit

Security Audit

Produce a defensible audit of the requested repository. Consistent coverage, evidence, and visible uncertainty matter more than finding counts or agreement between reviewers. This workflow cannot guarantee identical findings or the absence of vulnerabilities.

Instructions

You are the coordinator. Read methodology.md for the checks and decision rules, and artifacts.md for the versioned data contract and commands. Follow these stages in order:

1. Establish scope and provenance. Honor the user's paths, exclusions, budget, baseline selection, and existing authorization. Default to the current repository, including application code, jobs, scripts, configuration, and dependencies. Resolve the repository root explicitly; a supplied URL alone does not authorize an external penetration test. Read applicable repository guidance. Record revision, relevant dirty state, skill/plugin versions and hashes, exposed model/reviewer/tool identities, budget, and restrictions. Use unknown or not exposed for unavailable information. Read the plugin manifest; distinguish a file not inspected from one verified missing. This skill is versioned with the plugin. Host file-access settings are operational context: missing Claude settings or a count of deny rules neither blocks the audit nor establishes an application flaw. Default to repository review plus practical bounded local checks. Inspect checked-in deployment configuration and external-service integration code, but do not require live infrastructure access, vendor dashboards, service provisioning, or end-to-end production tests unless requested. State this boundary up front; never narrow an explicitly requested scope to make the status complete.
2. Inventory attack surfaces. Use deterministic discovery where practical, then trace registration, framework conventions, shared middleware, and dynamic paths. Create surface IDs and applicable check obligations before reviewing candidates. Record discovery gaps, including unsupported languages and generated code. Expand the inventory as new paths emerge; searches alone cannot establish completeness.
3. Discover candidates. Review assigned surface/check pairs using the methodology. Preserve every substantive candidate in the ledger, including uncertain ones. Do fresh discovery before reading prior findings when practical; record any earlier exposure. In blind evaluation, never read baselines or evaluator expectations.
4. Verify and challenge. Perform a separate pass that actively attempts to disprove each candidate. Trace protections and practical reachability; use bounded local reproductions where useful. Record counterevidence, assumptions, validation results, and a reasoned disposition. Independent disagreement is evidence to investigate; consensus is not proof. Keep potentially serious unresolved issues conspicuous.
5. Assess severity and priority. Apply the qualitative rubric to demonstrated impact and prerequisites. Record confidence separately. Consolidate duplicate root causes while retaining all entry points and materially different impacts. Hardening is separate from confirmed vulnerabilities. Artifact v1 deliberately supports no numeric security or CVSS scores, compliance percentages, or overall security grade.
6. Reconcile previous findings. After fresh discovery, select the latest relevant baseline or the explicitly supplied reports. Account for every prior finding with evidence or an explicit unresolved status. Absence never implies fixed. Preserve IDs across severity changes; use the legacy mapping procedure in the methodology.
7. Validate and render. Write matching timestamped JSON and Markdown artifacts to <audited-repository>/docs/security/YYYY-MM-DD-HHMMSS-security-audit.{json,md} (repository-relative, never filesystem /docs/security). Record timezone; avoid overwriting earlier runs. Run the supplied validator and renderer. Inspect the rendered report for unsupported claims as well as structural errors. Use the default concise reading copy: summary and contents first, findings before coverage. Keep the full ledger and commands in JSON; do not append reviewer reports or raw records to Markdown. Follow the report guidance. Release all audit-owned reviewers before final handoff. Apply the stopping rule below before final handoff; validation passing is not completion.