security-scan

Run the open-source security scanners installed on this machine over the project and summarize what they report. The results are leads for a review, not confirmed vulnerabilities.

Arguments

• A path (optional): the directory to scan; the repository root without it.

Flow

1. Detect the scanners with command -v semgrep osv-scanner gitleaks trivy. Never install one yourself: for each missing scanner, name it in the report with its install page (semgrep.dev, google.github.io/osv-scanner, gitleaks.io, trivy.dev). If none is installed, report that and stop.
2. Run each installed scanner read-only, with machine-readable output written to a temporary directory outside the repository:
   • Static analysis: semgrep scan --config auto --json --quiet --output <tmp>/semgrep.json <path>. --config auto downloads rules from the Semgrep registry and sends project metrics; when the user objects or the machine is offline, use a local rules directory with --metrics off.
   • Known-vulnerable dependencies: osv-scanner scan source --recursive --format json --output <tmp>/osv.json <path> (older releases: osv-scanner --recursive --format json <path>).
   • Secrets: gitleaks git --redact --report-format json --report-path <tmp>/gitleaks.json <path> for the history and gitleaks dir --redact ... for the working tree (older releases: gitleaks detect --redact). Always pass --redact.
   • Misconfiguration, containers and IaC: trivy fs --scanners vuln,misconfig,secret --format json --output <tmp>/trivy.json <path>. If a command's flags are rejected, read that scanner's --help and adapt; a non-zero exit code usually means "findings found", not a failure.
3. Read the results and remove duplicates: one entry per rule and location, and one per vulnerable package version, however many scanners reported it.
4. Triage quickly: open the reported location and mark each lead as "looks real", "needs review" or "likely false positive" with a one-line reason. Test fixtures, examples and vendored code are usually the last.
5. Delete the temporary result files, since they can quote sensitive lines.

Report

• The scanners that ran, with their versions, and the ones missing.
• Leads grouped by kind (code, dependencies, secrets, configuration), most severe first: rule or advisory id, file and line or package and version, the fixed version when one exists, and the triage mark.
• Secrets by file, line and kind only, never the value.
• Totals per scanner, and what was not scanned.