security-audit
Security Audit
Challenge the change from an attacker and misuse perspective before it ships.
Context
Security audit is the focused quality pass for abuse resistance. It is narrower than full security architecture work and deeper than ordinary code review. Use it when a change crosses trust boundaries, handles sensitive data, touches authn/authz, introduces new dependencies, or materially changes deployment exposure.
In Prodcraft, security audit exists to stop avoidable release risk. It should produce concrete findings tied to the current slice, not a generic list of best practices.
Inputs
- source-code -- The implementation under audit, including configuration and integration points visible in the change.
- architecture-doc -- Trust boundaries, component interactions, and intended control points.
- threat-model -- Known attacker capabilities, abuse cases, and assumptions to verify when one exists.
Process
Step 1: Map the Attack Surface
List the externally reachable paths, privileged operations, secret stores, data flows, and dependency changes involved in the slice. Focus on what changed, not the entire product.
Step 2: Inspect Trust Boundaries
Check authentication, authorization, tenancy isolation, input validation, output encoding, secret handling, and failure modes. Confirm the implementation matches the intended trust model instead of assuming the architecture doc was followed.
Step 3: Check Supply Chain and Configuration Risk
Review dependency additions or upgrades, deployment configuration, default exposure, logging of sensitive fields, and environment-specific behavior. Security failures often come from unsafe defaults rather than the core business logic.
Step 4: Write a Release-Useful Report
Classify findings by severity and exploitability. Separate:
- release blockers that must be fixed now
- medium-risk issues that need an owner and follow-up date
- accepted risks with explicit rationale
Every finding should point to the affected boundary, evidence, and expected remediation direction.
Outputs
- security-report -- Findings, risk classification, evidence, remediation guidance, and explicit release recommendation.
Quality Gate
- Trust boundaries for the change were reviewed explicitly
- High and critical findings are resolved or formally accepted
- Sensitive data handling and secret exposure were checked
- Dependency and configuration changes were reviewed for security impact
- The release recommendation is explicit: pass, conditional pass, or block
Anti-Patterns
- Scanner-only audit -- treating tool output as the entire audit.
- Checklist without context -- reporting generic issues that do not apply to the actual slice.
- Security as post-release paperwork -- auditing after the rollout decision is already made.
- Severity without exploit path -- labeling issues without explaining how the system could actually be abused.
Related Skills
- code-review -- catches general correctness and maintainability issues before the deeper security pass
- testing-strategy -- incorporates security checks into the broader verification plan
- deployment-strategy -- consumes the audit when rollout risk or blast radius must be constrained
- security-design -- provides deeper threat modeling and control design upstream
Distribution
- Public install surface:
skills/.curated - Canonical authoring source:
skills/05-quality/security-audit/SKILL.md - This package is exported for
npx skills add/updatecompatibility. - Packaging stability:
beta - Capability readiness:
beta
More from yknothing/prodcraft
system-design
Use when reviewed requirements or specifications are ready and the team must decide high-level architecture, component boundaries, integration seams, or brownfield coexistence strategy before API design, technology selection, or task planning.
6ci-cd
Use when a reviewed implementation slice needs an automated build, test, and deployment pipeline, especially when brownfield rollback, release-boundary checks, contract/integration gates, and staged delivery must be explicit before shipping.
6feature-development
Use when a reviewed task slice has tests or acceptance targets and the team must turn it into a small, mergeable implementation increment without expanding scope, breaking contracts, or hiding release-boundary risk.
6monitoring-observability
Use when a live service or newly delivered release needs actionable telemetry, dashboards, and alerts that expose real user-impactful boundaries, especially when brownfield coexistence rules, unsupported-flow safety, rollback health, or queue/backfill behavior must be visible before incidents escalate.
6requirements-engineering
Use when the work is still at the \u201Cwhat should we build\u201D stage and approved discovery inputs or entry-stack outputs must become prioritized requirements and scope boundaries before specification, architecture, planning, or coding. Not for acceptance criteria, spec review, or implementation.
6deployment-strategy
Use when a release candidate is ready and the team must choose the safest rollout pattern, verification checkpoints, and rollback path for the current risk, blast radius, and operational constraints.
6