run-scans

Run Scans

Produce the scan evidence the review requires, with the honesty line drawn per family: what an agent ran (from what inputs, with the report file on disk) versus what only the owner can run (and is therefore PENDING until the owner's report file exists). Evidence lands in <target>/.security-review/evidence/; dispositions land in the FP dossier (${CLAUDE_PLUGIN_ROOT}/templates/fp-dossier.md.tmpl → <target>/docs/security-review/fp-dossier.md). The failure class this phase exists to kill: a submission whose scan reports are missing, stale, unauthenticated, scoped narrower than the architecture doc, or carrying undispositioned findings — each of those bounces at the materials check (baseline: process-prequeue-validation, scan-no-clean-scan-required).

When to use

• As the journey's static-scan substrate (early, BEFORE the audit): the host-independent families need only the scope manifest — see "The static/live partition" below
• As the journey's live/conditional tail (late): artifacts drafted and the scope manifest's endpoint inventory exists — the DAST scope is generated from it (this prerequisite belongs to the DAST/live tail, not the static substrate)
• Re-scanning after fixes: the submitted report must be the post-fix run
• Refreshing evidence before submission (baseline: scan-report-freshness)
• NOT a replacement for the white-box audit (/sf-security-review-toolkit:audit-codebase is static code review — a different evidence class, never presentable as DAST)
• NOT for executing the DAST scan itself — that is owner-run by nature, and this skill never claims otherwise (CONVENTIONS §2)
• NOT the reviewer's pen test — Salesforce's Product Security team tests the surface regardless of anything submitted (baseline: dast-salesforce-runs-own-pentest)

Prerequisites

• <target>/.security-review/scope-manifest.json (from /sf-security-review-toolkit:scope-submission). Missing? Offer to route there first; degraded mode runs only the track the repo itself proves (package tree → Code Analyzer; lockfiles → dependency audit) and records that the endpoint families were skipped for lack of an inventory.
• ${CLAUDE_PLUGIN_ROOT}/baseline/requirements-baseline.yaml readable.
• Per family: the Code Analyzer CLI + JDK 11+ (PMD engine) for the package track — present sf used as-is, else consent-installable as the whole stack to the tmp dir (0.8.41, the same gate as the OSS scanners); a ZAP install (or the container) wherever the owner will run DAST; network access for the TLS check; ecosystem package managers for the dependency audit. For the external-endpoint families (7/8) and the DAST/TLS extensions, the free/OSS tools — Semgrep, OSV-Scanner, Checkov, and optionally Trivy / Nuclei / Schemathesis / testssl.sh / sslyze; each is auto-detected (never auto-installed by THIS skill — see the hard boundary below), found on the prepended PATH when the operator consented to a tmp install at the journey gate (<target>/.security-review/scanner-install.json), and, if still absent, handed to the owner as the exact install + run command (PENDING-OWNER-RUN) rather than skipped silently.
• Credentials only ever via environment variables — this skill refuses to write a secret into a plan, an evidence file, or the run log (CONVENTIONS §6).