dependency-audit

name	dependency-audit
description	Running the right security scanners for the detected stack — secrets, SAST, deps, images.

Dependency & Secret Audit — Scanner Selection

Purpose: given a repository, decide which scanners to actually run and how to report what they find. Detection first — a single-language project should run two or three commands, not nine.

Depth beyond execution lives elsewhere:

Need	Skill
CVE triage, severity SLAs, update strategy	skills/security/dependency-vulnerabilities/SKILL.md
Wiring SAST into CI with thresholds	skills/security/sast-pipeline/SKILL.md
Typosquatting, action pinning, dependency confusion	skills/security/supply-chain/SKILL.md
Storing and rotating secrets	skills/security/secret-management/SKILL.md

---

Step 1 — Always Run (Any Repository)

Goal	Command	Notes
Secrets in git history	gitleaks detect --source . --log-opts="HEAD~50..HEAD"	Widen the range for a first full audit (--log-opts="")
Secrets, alternative engine	trufflehog git file://. --since-commit HEAD~50	Verifies live credentials; slower — use when gitleaks reports candidates
Broad SAST	semgrep --config=auto .	Language-agnostic; the auto ruleset resolves per detected language

A secret removed from current code but still present in git history is a live exposure — rotate it. Deleting the line does not revoke the credential.

---

Step 2 — Ecosystem Detection → Dependency Scanner

Run only the rows whose signal is present.

Signal in repo	Ecosystem	Command
package-lock.json, yarn.lock, pnpm-lock.yaml	Node.js	npm audit --audit-level=high (or pnpm audit / yarn npm audit)
composer.lock	PHP	composer audit
requirements.txt, poetry.lock, Pipfile.lock, pyproject.toml	Python	pip-audit
Gemfile.lock	Ruby	bundle audit check --update
go.sum	Go	govulncheck ./...
Cargo.lock	Rust	cargo audit
pom.xml, build.gradle	Java	OWASP Dependency-Check plugin
*.csproj, packages.lock.json	.NET	dotnet list package --vulnerable
Any of the above, org uses a SaaS scanner	Multi	snyk test — only if the project already has Snyk configured

If a manifest exists without a lockfile, say so in the report: results are approximate and the build is not reproducible.

---

Step 3 — Language-Specific SAST (Add Only If Present)

Signal	Scanner	Command
*.py files	Bandit	bandit -r . -ll
Dockerfile, *.tf, *.yaml manifests	Trivy config scan	trivy config .
Built container image	Trivy image scan	trivy image <image>:<tag>
sonar-project.properties / SONAR_TOKEN	SonarQube SAST	See skills/devops/sonarqube/SKILL.md — complements, does not replace, the scanners above

---

Step 4 — Handle Missing Tools

• A scanner that is not installed is not a passing result. Report it as NOT RUN with the install hint; never conclude "no vulnerabilities found" from a missing binary.
• Prefer a runner that needs no install where one exists (npx, uvx, docker run) before asking the user to install anything.
• Never bypass a failing audit with a force/ignore flag to make a build pass.

---

Reporting Thresholds

Finding	Report as
HIGH or CRITICAL CVE in a direct dependency	Flag — blocking
CRITICAL CVE in a transitive dependency	Flag — blocking
HIGH in a transitive dependency	Note it; escalate only if the vulnerable path is reachable
MEDIUM / LOW anywhere	Batch into routine updates
Any secret found in history	Flag — blocking; rotation required, not just removal
Scanner unavailable	NOT RUN — explicitly listed, never silently omitted

Before downgrading any severity, apply the reachability triage in skills/security/dependency-vulnerabilities/SKILL.md and record the reasoning.

---

Output Discipline

• Summarize counts and the blocking findings — do not paste full scanner output into the response.
• Cite package name, installed version, fixed version, and CVE id for each blocking finding.
• Recommend the smallest upgrade that clears the finding; flag major-version bumps as needing manual review.