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.
• intake-brief -- Must include quality_target_context with runtime_context, exposure_profile, production_target, non_targets, and evidence_refs.

Process

Step 0: Calibrate the Security Target

Read quality_target_context before mapping attack surface. Confirm whether the reviewed target is an agent-internal skill, host runtime tool, local harness, internal service, or public HTTP service.

Do not downgrade baseline security because the target is internal. An agent-internal skill still needs review for prompt injection, command safety, remote instruction trust, tool/file/network side effects, secrets and PII in prompts, examples, logs, and artifacts, dependency execution risk, and public export supply-chain safety.

Escalate to full service-style audit when runtime_context=public_service, exposure_profile=public_internet, or evidence shows externally reachable behavior, multi-user access, sensitive data handling, auth/authz, privileged operations, new deployment exposure, or service-to-service trust boundaries. Only then should CORS, public auth, rate limiting, browser session handling, and internet abuse paths become release blockers.

If target context is missing or contradictory, stop and request the boundary or route a course-correction-note; do not invent public service blockers from HTTP-shaped implementation details alone.

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

1. Scanner-only audit -- treating tool output as the entire audit.
2. Checklist without context -- reporting generic issues that do not apply to the actual slice.
3. Security as post-release paperwork -- auditing after the rollout decision is already made.
4. 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/update compatibility.
• Packaging stability: beta
• Capability readiness: beta