Dependency and Secret Audit

Most breaches of small companies start with something already known: an old library with a published flaw, or a key someone committed two years ago. You find both, sort the real risks from the noise, and hand back a short, ordered plan. A good audit ends with fewer open items next month, not a 400-row spreadsheet nobody reads.

When to use

• "Are any of our packages vulnerable?"
• "Dependabot is shouting at us; what actually matters?"
• "Did anyone ever commit an API key to this repo?"
• "Check the Docker image before we ship it."
• Before a customer security review, a funding due diligence or open-sourcing a repo.

What you need

• The repository with full git history (a shallow clone hides old secrets). Access through a connected GitHub or GitLab app, a read-only deploy key on your computer, or an archive in the workspace. If none, ask with clarify.
• Image names and tags for any containers in scope, and access to the registry if it is private.
• Which services are internet-facing, so you can rank reachability.
• The owner's patch policy if one exists. If not, use the suggested defaults below and say they are defaults.

Method

Part A: dependencies

1. Inventory. Use search_files to find manifests and lockfiles: package-lock.json, yarn.lock, pnpm-lock.yaml, requirements*.txt, poetry.lock, Pipfile.lock, go.sum, Cargo.lock, Gemfile.lock, composer.lock, pom.xml, build.gradle, Dockerfile. A manifest without a lockfile is itself a finding: builds are not reproducible.
2. Scan with free, open-source tools in terminal. Save JSON output to the workspace with the tool version and date.
   • osv-scanner across the repo (uses the free OSV.dev database, covers most ecosystems)
   • the ecosystem's own auditor: npm audit or pnpm audit, pip-audit, govulncheck (reports whether vulnerable functions are actually called), cargo audit, bundler-audit
   • trivy image <name:tag> for container images, which also catches base image OS packages
3. Deduplicate by package, version and advisory ID (CVE or GHSA). Tools overlap heavily.
4. Triage each advisory on four questions and record the answers:
   • Runtime or dev-only? A test framework flaw rarely matters in production.
   • Reachable? Is the vulnerable function or feature used? govulncheck answers this for Go; elsewhere, search_files for the import and the specific API named in the advisory.
   • Exploited in the wild? Check the CISA Known Exploited Vulnerabilities catalogue (free, cisa.gov). Note the EPSS probability from FIRST (free) as a likelihood signal.
   • Fix available? Lowest fixed version, and whether it is a patch, minor or major upgrade.
5. Prioritise. Severity alone is a poor ranking; combine it with the answers above. Suggested defaults (replace with the owner's policy if they have one):

   Priority	Rule	Suggested target
   P1	In the KEV catalogue, or Critical/High and reachable on an internet-facing service	days
   P2	High but not reachable, or Medium and reachable	next planned release, within a month
   P3	Low, dev-only, or no realistic path	batch with routine updates
   Accept	No fix exists and no reachable path	record reason, owner and review date

6. Plan upgrades. For each P1 and P2, find the smallest version that fixes it, read the changelog for breaking changes, and group upgrades that must move together. If the owner wants you to make the change, do it on a branch, run the test suite, and open a pull request; never merge it yourself.

Part B: secrets

7. Scan the whole history, not only the working tree, with gitleaks (MIT licensed) over the git log. Also run trivy secret scanning on built images, and check .env files, CI configuration, Terraform state files (terraform.tfstate stores secrets in plain text), notebooks and log files committed by mistake.
8. Do not test whether a found credential works. Using a credential you found, even to check it, is not your call and may breach the provider's terms. Turn off any "verify" mode in scanners. Report it as live until the owner proves otherwise.
9. Classify each true hit: type (cloud key, database password, payment key, private key, webhook URL), file and commit, first committed date and author, whether the repo is or ever was public, and whether forks or mirrors exist.
10. Response order, with the owner's go-ahead at each step:
    1. Revoke or rotate at the provider. This is the only step that removes the risk.
    2. Check the provider's audit logs for use of that credential since the first commit date. Any use you cannot explain moves this to security-incident-triage.
    3. Move the secret out of code into environment variables or a secret manager the owner already uses.
    4. Optionally purge it from history with git filter-repo. This rewrites history for everyone and needs explicit approval; it does not un-leak a public secret.
11. Prevent recurrence: a gitleaks pre-commit hook, .env in .gitignore, secret scanning and automated dependency updates in CI (GitHub and GitLab both offer free options), and a lockfile for every manifest.

Output

Saved to the workspace as markdown, with a show_card showing P1/P2/P3 counts and secrets found.

# Dependency and secret audit: <repo> @ <commit>
Tools: osv-scanner x.y, gitleaks x.y, trivy x.y  (databases as of <date>)

## Summary
<counts, the P1 items in one line each, secrets needing rotation>

## Dependencies
| Pri | Package | Version | Advisory | Severity | Runtime | Reachable | KEV | Fixed in | Action |

## Secrets  (values masked)
| Type | Location | First commit | Public? | Status | Action |
| AWS access key ...WXYZ | config/prod.py:12 | 2024-03-02 abc123 | No | Live until rotated | Rotate, check CloudTrail |

## Upgrade plan
## Accepted risks (reason, owner, review date)
## Prevention steps

Checks before you finish

• Every secret is masked to its last 4 characters at most, in the report and in chat.
• No found credential was used for anything.
• Every P1 has a named fix and an owner.
• Tool versions and database dates are recorded.
• Transitive dependencies and container base images were included.
• Suppressed or accepted items each have a reason and a review date.

Pitfalls

• Sorting by CVSS alone. A critical in an unused dev dependency matters less than a medium in your login path.
• Upgrading everything at once. One giant upgrade breaks the build and gets reverted. Move P1s alone, then batch the rest.
• Deleting the secret in a new commit and calling it fixed. It is still in history and possibly in forks and caches. Rotate first.
• Ignoring the base image. Old OS packages in FROM images are often the largest share of findings.
• Silencing alerts without expiry. Every suppression gets a reason and a date to look again.
• Sign-off. You recommend; the owner or their engineering lead approves rotations, history rewrites and merges. Rotation can break production integrations, so agree a time.

See also: references/CREDITS.md for the open-source tools named here and their licences.