deployment-audit

name	deployment-audit
description	Authorized deployment readiness and go-live security audit for software projects and running apps. Use as the final app go-live gate to assess release readiness, validate evidence, run scanner coverage, verify authorization boundaries, prove release blockers, and produce a deployment audit report. Provides one Rust CLI boundary for Pi/CTOX agents running in a sandbox.

Deployment Audit Meta Skill

Before acting, read references/tool-policy.md and references/workflow.md. Use them as the operational contract for CLI commands, coverage gates, Pi/CTOX namespace choices, and full deployment-audit behavior.

Perform only authorized security testing on in-scope assets. Treat scope as a technical boundary, not a suggestion. Frame the work as a deployment audit or go-live readiness gate. Use the CLI wrapper for all structured assessment work so scope checks, artifacts, release-blocker state, and reports remain auditable.

For a user request to run a "deployment audit", "Go-Live-Abnahme", "release gate", "go-live security check", "full assessment", or equivalent, do not stop after a connectivity smoke test. Run the full assessment orchestrator and inspect its coverage result:

pentest assess --profile full --target ./repo --url http://127.0.0.1:3000 --json
pentest tools inventory --json
pentest tools smoke --profile full --json
pentest tools readiness --profile full --smoke --json
pentest tools proof-run --profile full --probe-versions --json
pentest tools proof-run --profile full --probe-versions --install-missing --tool <scanner> --json
pentest tools status --profile full --json
pentest analyze --json
pentest artifact audit --json

Add --active only when the rules of engagement explicitly authorize active testing such as SQL injection automation, content fuzzing, and port scanning. Without --active, the assessment must still run all safe phases and record active-testing coverage gaps.

Required CLI

Prefer ctox appsec inside CTOX. Outside CTOX or in Pi Code, use the legacy standalone pentest binary as an implementation detail, while keeping all user-facing language as deployment audit / go-live readiness.

If pentest is not on PATH and this repository is available, run it through Cargo:

cargo run --manifest-path src/tools/appsec-pentest/Cargo.toml -- <args>

All commands should include --json when the output is consumed by the agent. The wrapper never fabricates scanner results: missing external tools are reported as unavailable, and raw scanner output is stored as artifacts. scanner validate enforces per-tool evidence contracts, expected output formats, normalized candidate/observation fields, and artifact references. Native ctox appsec always binds scanner lookup to CTOX's shared runtime/tools/appsec directory, even when --state-dir points to an external artifact volume. Standalone/Pi runs that intentionally keep state and scanner runtime separate must pass --tools-root <dir> explicitly.

Strix-Derived Deployment Audit System

This skill ports Strix as one Pi/CTOX skill plus one Rust CLI boundary. Treat Strix's structure as mandatory:

• Root-agent orchestration: decompose scope into workstreams before concluding.
• Specialized work: cover recon, SAST, secrets, dependencies, AST/source flow, web mapping, active DAST, auth/JWT, IDOR, SQLi, SSRF, XSS, XXE, RCE, CSRF, race, business logic, upload, traversal, NoSQL, SSTI, and request smuggling.
• Authenticated web work: for deep/full URL targets with login or account creation, prove user and tenant isolation with CTOX web-stack browser/session artifacts. Do not add or use separate browser tools inside this skill.
• Candidate vs finding: scanner output creates candidates, not validated findings.
• Reporting gate: finding validate requires evidence, PoC/reproduction, technical analysis, impact, remediation, and CVSS/CWE/CVE sanity when set. User-facing reports call validated issues release blockers.
• Finish gate: finish refuses to mark a complete report when active workstreams/agents or coverage blockers remain. Use --allow-incomplete only when the report must explicitly state incompleteness.

First Actions

1. Create a scope file or initialize scope from explicit targets:

pentest init --target ./repo --json
pentest init --url http://127.0.0.1:3000 --json
pentest init --scope scope.json --json

2. Before touching a target, check scope:

pentest scope check --path ./repo --json
pentest scope check --url http://127.0.0.1:3000/login --json

3. For a complete deployment audit, run the orchestrator:

pentest assess --profile full --json
pentest assess --profile full --active --wordlist wordlist.txt --json

The assessment command performs scoped mapping, tool inventory, Strix-style coverage planning, assessment-specific readiness proof, practical tool-chain pipeline generation, static/source scanning for path targets, web/recon scanning for URL/host targets, optional active validation, scanner artifact triage, coverage-gap recording, final narrative draft generation, and report rendering. Afterward inspect:

pentest tools inventory --json
pentest tools smoke --profile full --json
pentest tools readiness --profile full --smoke --json
pentest tools proof-run --profile full --probe-versions --json
pentest tools proof-run --profile full --probe-versions --install-missing --tool <scanner> --json
pentest tools status --profile full --json
cat .pentest/assessment-readiness.json
cat .pentest/assessment-pipeline.json
pentest analyze --json
pentest scanner validate --json
pentest artifact audit --json
pentest report --format json --json

In the JSON report, inspect toolchain_evidence_summary. A production-ready go-live audit should not claim full scanner readiness while toolchain_evidence_summary.full_proof_ready is false, even if the narrative text is polished. pentest review enforces the same rule for full/deep assessment profiles; use its blocker output as the completion gate.

4. For narrow manual work, map the target before scanning:

pentest map --target ./repo --json
pentest map --url http://127.0.0.1:3000 --json

5. Load Strix-derived playbooks only when needed:

pentest skill load --name xss --json
pentest skill load --name sql_injection --name nextjs --json

6. Track assessment work in wrapper state:

pentest todo create --title "Validate authz on /api/admin" --priority high --json
pentest note create --title "Auth model" --category methodology --content "..." --json
pentest think --note "Current state, confirmed facts, next safe action." --json

7. Run static and/or web scans through the wrapper:

pentest scan static --target ./repo --profile standard --json
pentest scan web --url http://127.0.0.1:3000 --profile standard --json

8. Import captured traffic when request-level release validation is needed:

pentest proxy import --file traffic.har --json
pentest proxy list --method POST --status 200 --json
pentest proxy view --id req-001 --part response --json
pentest proxy replay --id req-001 --method POST --header "X-Test: 1" --body '{"probe":true}' --json
pentest proxy sitemap --json

9. For authenticated web applications, generate a CTOX web-stack authz plan/run artifact and import the resulting redacted matrix:

pentest authz plan --target http://127.0.0.1:3000 --source-id ctox-web-stack --json
pentest authz credential-proof-template --subjects authz-subjects.json --json
pentest authz preflight --target http://127.0.0.1:3000 --subjects authz-subjects.json --credential-proof .pentest/authz/credential-proof-template.json --require-credentials --json
pentest authz run --target http://127.0.0.1:3000 --subjects authz-subjects.json --source-id ctox-web-stack --json
pentest authz schema --json
pentest authz build-matrix --run .pentest/authz/authz-run-<id>.json --evidence-dir web-stack-evidence --import --json
pentest authz import --file authz-matrix.json --target http://127.0.0.1:3000 --json
pentest authz status --json

Before authz run, prefer ctox appsec authz preflight --require-credentials --json and follow its next_commands. In standalone/Pi runs, first create a redacted credential proof template with pentest authz credential-proof-template --subjects <subjects.json> --json, store or verify the referenced credentials through ctox secret put --scope ... --name ... --value-stdin, and pass the resulting proof to pentest authz preflight --credential-proof <proof.json> --require-credentials --json. The generated template is not proof of availability by itself: it starts local ctox-secret://... refs as missing and the preflight/run gate remains blocked until a redacted Secret Store check marks them available. Preflight/run readiness also requires at least two non-anonymous subjects with local credential_ref values; unauthenticated plus one account is not enough to prove account-to-account authorization. Blocked preflight output includes concrete subject-template, credential-proof, ctox secret put --scope ... --name ... --value-stdin, rerun-preflight, and authz-run steps. Never replace those reference-only commands with raw passwords or tokens in AppSec state.

The authz run command creates durable Web-Stack tasks for ctox_web_auth_assist_request, ctox_browser_automation, ctox_browser_context_capture, and ctox_browser_context_extract. Execute the generated run.web_stack_tasks as a DAG: honor requires, resolve session_id_ref.placeholder from prior auth/session task output, call harness_tool when the CTOX harness is available, otherwise run the ctox_cli program plus args. For ctox_browser_automation, pipe harness_tool.freeform_source as raw JavaScript on stdin; never wrap it as JSON or markdown. Store each redacted JSON result at the task's expected_artifact, then use pentest authz build-matrix --run <authz-run.json> --evidence-dir <dir> --import to normalize and import them. Use direct authz import only when a complete matrix already exists. The authz matrix must contain at least two credentialed account subjects, cross-subject cases, endpoints, methods, actual status codes, pass/fail/inconclusive results, and references to redacted evidence artifacts. Never import cookies, bearer tokens, passwords, private keys, raw screenshots, or unredacted browser streams.

10. Store only validated release blockers as findings and finalize narrative:

pentest finding create --input finding.json --json
pentest finding validate --id F-001 --json
pentest artifact audit --json
pentest finish --executive-summary "..." --methodology "..." --technical-analysis "..." --recommendations "..." --json
pentest report --format markdown --out pentest-report.md --json
pentest artifact cleanup --keep-latest 5 --json

Operating Rules

• Do not scan, crawl, fuzz, or connect to assets outside initialized scope.
• A complete deployment-audit request requires pentest assess --profile full unless the user explicitly asks for a narrower smoke test, single tool, or validation task.
• After pentest assess, inspect .pentest/coverage.json or the JSON output. If coverage_complete is false, continue with missing workstreams or report the exact blockers; do not call it complete.
• After pentest assess, also inspect .pentest/assessment-readiness.json and .pentest/assessment-pipeline.json. Readiness blockers mean the required scanner binary, native/manual attestation, template, or wordlist is not actually usable for the planned assessment. Pipeline stages define the expected handoffs between recon, scanner output, proxy replay, CTOX web-stack authz, candidate creation, and finding validation.
• After pentest analyze, run pentest scanner validate --json. Treat validation failure as an incomplete scanner pipeline, not as a successful deployment audit. Fix parser/contract/artifact gaps or report the exact blocker. Inspect each scanner result's runner_safety: ok=false means the scanner command did not include the conservative production-bounded defaults expected for that tool and should be rerun or justified before closure.
• After installing scanners, run pentest tools smoke --profile <profile> --json or pentest tools readiness --profile <profile> --smoke --json. Smoke probes are local version/start checks only; they do not scan targets.
• Use pentest tools status --profile <profile> --json for the telemetry-free local operator view: scanner paths/versions, template and wordlist metadata, cache size, and latest readiness/smoke artifacts.
• When a URL target uses login/account state, authenticated-multi-user-authz coverage is mandatory for deep/full assessments. Use pentest authz run to generate the Web-Stack task plan. Execute its web_stack_tasks using the embedded harness_tool or ctox_cli contracts, resolving session placeholders before context capture/extract and replay. Then build/import the completed redacted evidence with pentest authz build-matrix --run <authz-run.json> --evidence-dir <dir> --import.
• Do not submit a finding from scanner output alone. Validate exploitability or concrete impact first.
• For source-only findings without a replayable HTTP endpoint, export the issue bundle and verify it with an explicit checkout root: pentest finding verify-bundle --id <id> --execute --source-root /path/to/repo --json. The generated reproduce.py returns exit code 2 while the scanner marker still exists and 0 after the source marker is fixed or no longer reproducible.
• For assessment handoff or fix verification, prefer the aggregate verifier so the agent does not have to guess which bundles still need proof execution: pentest finding verify-all --mode http-only --execute --json for black-box/no-source proof bundles and pentest finding verify-all --mode source-only --execute --source-root /path/to/repo --json when source is available. The command writes .pentest/reports/proof-verifications.json; include that artifact in the report handoff.
• Before exporting or handing off a report, run pentest artifact audit --json. A false result means the AppSec state still contains secret-like keys such as cookies, bearer tokens, passwords, private keys, raw browser streams, storage state, or screenshots.
• Use pentest artifact cleanup --keep-latest <n> --json for a dry-run plan after large runs. Execute deletion only with --execute --confirm-cleanup; cleanup excludes evidence, authz, proxy, notes, findings, todos, and approvals.
• Prefer pentest run <tool> over direct tool invocation. Use direct shell calls only for manual validation that the wrapper does not cover, and save the evidence with pentest artifact add.
• If an external tool is missing, report it as an environment gap and continue with available in-scope methods; do not invent equivalent output.
• Use pentest web-search only when Perplexity credentials are configured in the sandbox. If unavailable, treat it as a research coverage gap.
• Use pentest agent ... as durable coordination state for Pi/CTOX orchestration. The wrapper records queued workers/messages; Pi/CTOX should spawn the actual child agents and mark them finished before pentest finish.
• For white-box work, combine code review, Greppy source-code intelligence, SAST, dependency/secret scanning, and dynamic validation when the app can be run. Use Greppy to find entrypoints, auth/tenant policy paths, data-flow chokepoints, and source evidence that can be turned into browser/CLI proof scripts; do not treat it as a replacement for dynamic validation.
• For black-box work, perform recon and attack-surface mapping before active exploitation unless the user explicitly scopes a narrow validation task.
• For source-code targets, fix confirmed vulnerabilities after reporting them when the user asked for remediation or the task includes code changes.

Workflow References

Load only the reference needed for the current phase:

• references/workflow.md - end-to-end Pi/CTOX workflow and command recipes.
• references/tool-policy.md - allowed wrappers, external binaries, and raw tool rules.
• references/finding-schema.md - JSON schema and validation rules for findings.
• references/strix-port-map.md - mapping from Strix skills/tools to this single skill.

Strix-Derived Playbooks

The Strix playbook corpus is bundled under references/strix/ as reference material from usestrix/strix commit 5ee34481fec54b269523a958802389cb3c5873dc, not as separate skills. Load the specific file for the vulnerability, framework, technology, scan mode, or tool being used.

Common references:

• Vulnerabilities: references/strix/vulnerabilities/*.md
• Tools: references/strix/tooling/*.md
• Frameworks: references/strix/frameworks/*.md
• Technologies: references/strix/technologies/*.md
• Protocols: references/strix/protocols/graphql.md
• Scan modes: references/strix/scan_modes/{quick,standard,deep}.md
• White-box coordination: references/strix/coordination/source_aware_whitebox.md
• Source-aware SAST: references/strix/custom/source_aware_sast.md

Use these references for payload patterns, validation strategy, tool syntax, and coverage planning. The pentest CLI remains the state and evidence boundary.