hamza-hnt/preprod-security-audit

Preproduction Security Audit

Produce a decision-useful security assessment of the specified release. Explain what was examined, what the evidence supports, what remains unknown, and how to remediate and verify each issue. Default to English for the report unless the user requests another language.

Use only the current host's available, authorized capabilities. Resolve bundled references relative to this skill folder. Local file access, shell/scanners, browsing, connectors, and delegation are not assumed. When a capability is unavailable, review supplied evidence and record U-### gaps. If the requested filesystem destination cannot be written, provide the report as a downloadable artifact or Markdown text and state that delivery limitation.

Calibrate before selecting checks

1. Identify the requested assessment, target release or commit, deployment target, available evidence, and existing authorization. Preserve the user's scope and prior answers.
2. Read scoping questions. Resolve Q-00 before inspecting repository contents if repository review has not already been requested or clearly included. A request to audit the repository or code already answers it; do not ask again. If the user excludes repository review, work from the selected documents/configuration/runtime evidence and record the limit.
3. Inspect only in-scope project metadata and documentation without executing project code. Record facts separately from inferences and user statements. Ask a short batch of material remaining questions and branch by product, exposure, hosting, identity, data, and available access. Continue independently authorized work while waiting; silence does not answer an unresolved scope choice.
4. Record a scope snapshot, selected modules, applicable control IDs, permitted checks, and unresolved questions in the report. Update this snapshot when answers change the scope.

Route to relevant modules

Always use audit method and findings and priorities. Load module details only when their surface is present or needs investigation. Do not load every module simply because it exists.

Use the 35-domain coverage map to relate the original assessment areas to control IDs. When tool-assisted checks are in scope, follow scanner execution procedures for Gitleaks, Semgrep CE, Trivy, and ZAP; select tools by evidence and availability, and record actual runs, errors, and omissions. A manual-only request does not activate scanners.

For dependency inventories, reuse a target-matched SBOM first, then use Trivy if generation is needed and permitted. Native package graphs, Syft, and source-import analysis are optional supplements; follow the inventory procedure in the same reference. Keep package relationships separate from code imports and runtime relationships.

Surface	Module	Routing guidance
Every assessment	Architecture	Establish assets, trust boundaries, critical actions, exposure, and responsibility.
Accounts, permissions, tenants, sessions, or service identities	Identity and access	Include infrastructure identities even if the product has no login.
Web interfaces, APIs, workers, files, or integrations	Application and API	Select controls for actual input, output, protocol, and business paths.
Data, credentials, cryptography, databases, or storage	Data and secrets	Include credentials and metadata even when personal data is absent.
A deployed service or planned deployment	Infrastructure and deployment	Match the provider and deployment model; distinguish intended configuration from observed runtime.
Source, dependencies, build, or release process	Supply chain	When repository review is included, inspect discovered CI/CD definitions, their scripts/templates, trust transitions, and deployment gates without waiting for a second permission question. Effective platform settings remain a separate evidence source.
A service entering or already in operation	Operations and resilience	Assess detection, recovery, incident handling, availability, and ownership.
LLMs, RAG, AI tools, agents, or MCP	AI and agents	Review model inputs, data access, delegated authority, outputs, and resource limits.
Mobile, desktop, or browser-extension client	Mobile and desktop	Select platform sections and audit the backend separately.

For unsupported specialist surfaces, such as industrial equipment or custom hardware, document the coverage limit and required specialist review. Do not imply that the software modules fully assess them.

Examine and record

• Follow the audit method's evidence, authorization, and execution rules. An audit request authorizes analysis and report creation; it does not automatically authorize production changes, destructive probes, or publishing sensitive results.
• A repository review covers the agreed files, source paths, manifests, relevant history, and CI/CD definitions. It includes hardcoded secrets, unsafe fallback values, environment-specific destinations, and fixed security/identity policy. Honor narrower path/history exclusions; do not label ordinary constants as vulnerabilities without a security consequence.
• Maintain an evidence ledger, control matrix, findings, unknowns, audit-path edges, and dependency edges while working. Tie all material claims to exact source locations or observations and the inspected version/environment.
• Treat scanner output as a lead until contextualized. Trace relevant callers, guards, data paths, configuration, and deployment assumptions before assigning a confirmed defect or release consequence.
• After inventory, apply the supply-chain module's focused current-advisory triage (SC-003), prioritizing critical components and known-exploited or critical/high issues. Record exact package/version matches, dated sources, verified fixes, local exposure and queried coverage; offline or failed lookups remain explicit gaps.
• Use the same control ID in coverage, findings, remediation, and graphs. Deduplicate findings with the same underlying cause while preserving affected surfaces.
• For long reviews, delegate independent modules when supported. Give each reviewer the scope and ID allocation, then reconcile shared trust boundaries and conflicting claims before writing the report.
• If access or a tool is unavailable, record the limitation and continue useful work. A failed check is not a passed check. An unknown control is not non-applicable.

Deliver the report

Use the report template. Default to a new file at security-audits/<YYYY-MM-DD>-<revision-or-target>/security-audit.md inside the audited project unless the user specifies another destination. Use a non-conflicting suffix if that destination already exists. Do not save target reports inside this skill, overwrite a prior assessment, or commit/upload reports unless requested.

Include both required Mermaid diagrams:

1. Analysis path graph: the observable audit trail from scope and artifacts through performed checks to findings, supported conclusions, and gaps. Show what was inspected and where a check stopped. This is an evidence map, not private reasoning or an invented chronology.
2. Analyzed dependency graph: the inspected components, package dependencies, services, identity systems, storage, and external integrations, with explicit edge types, evidence references, and inspection coverage. Include material uninspected boundaries as such.

Build graphs from the ledgers using the graph contract in the audit method. Include node/edge tables so the report remains usable without Mermaid rendering. Split large dependency maps by runtime/service, package/build, or CI/CD trust relationships under the dependency section. For reviewed pipelines, show trigger/input → job → runner/identity → artifact → environment, with actual gates, trust boundaries, and uninspected settings distinguished.

The report must contain a prioritized correction plan, owners or unassigned roles, dependencies between fixes, acceptance tests, residual risks, and unresolved decisions. State a bounded readiness recommendation using the findings rules; the skill does not approve a deployment or certify compliance.

Final quality check

• Verify scope, revision, evidence links, control statuses, and all finding/unknown IDs agree across text, tables, graphs, and plan.
• Check graph edge directions and labels. Mark declarations, observed behavior, inferences, and unavailable evidence distinctly. Remove all template example data.
• Ensure no credentials, personal data samples, sensitive prompt content, or private infrastructure identifiers are unnecessarily disclosed.
• Every finding needs a concrete correction and verification criterion. Every critical unknown needs a next action and its release-decision consequence.
• State which checks actually ran, which failed or were skipped, and whether diagrams were rendered or only syntax-reviewed. Never claim a test, render, or runtime verification that did not happen.
• Deliver the file location, major release blockers, and coverage limits concisely. Leave implementation of fixes to an authorized follow-up unless already included in the request.