Audit an inherited repo

You have inherited something. Nobody knows its security posture, the last commit was a while ago, and you need a defensible answer about whether it is safe to run.

The failure mode here is producing a 400-item list nobody reads. Order matters more than completeness.

1. What is it built from

/mcp__vulnetix__vulnetix_capabilities_detect

Probes the repository and your machine, writing .vulnetix/capabilities.yaml: primary package manager, containers, IaC, CI, and which scanners you have available. Everything downstream reads it.

2. Is anything actively exploited

Skip “how many vulnerabilities”. That number is always large and always unhelpful. Start with the ones being used against real systems.

/mcp__vulnetix__vulnetix_kev_watch

Pulls the KEV catalogue and intersects it with what the repo actually depends on. If this comes back empty, you have already learned the most important thing.

Anything it finds goes straight to the top of the list, with dueDate as the sort key.

3. Is anything unsupported

/mcp__vulnetix__vulnetix_eol_check

An end-of-life runtime is a vulnerability that will never be fixed. A Node 14 or Python 3.7 service outranks most individual CVEs, because every future advisory against it is permanent.

vulnetix_eol_products gives the tracked catalogue if you want to check a specific runtime directly.

4. Is anything hostile

/mcp__vulnetix__vulnetix_typosquat_check --installed

Cross-references installed dependencies against AI-malware family intelligence, name similarity to popular packages, and low maintainer-health signals. Rare, and worth ruling out early, because the answer changes what kind of problem you have.

5. Now the broad sweep

Only now, with the sharp edges known:

/mcp__vulnetix__vulnetix_sast_scan
/mcp__vulnetix__vulnetix_secret_scan
/mcp__vulnetix__vulnetix_iac_scan
/mcp__vulnetix__vulnetix_container_scan
/mcp__vulnetix__vulnetix_license_check

Secrets first among these. A committed credential is exploitable today by anyone with read access, needs no vulnerability, and is usually the single highest-value finding in an inherited repository.

6. Turn it into a shortlist

Group everything found by whether it is (a) KEV-listed or actively exploited, (b) has a fix available with no major version bump, (c) needs a migration, or (d) is not reachable from our entry points. Give me the top ten in group (a) and (b) with the single command that closes each.

Groups (a) and (b) are this week. Group (c) is a planning conversation. Group (d) gets recorded and closed:

/mcp__vulnetix__vulnetix_vex_publish

A documented not-affected is a finished item. An ignored one comes back every scan forever.

7. Baseline it

/mcp__vulnetix__vulnetix_sbom_generate
/mcp__vulnetix__vulnetix_compliance_report

An SBOM turns the next audit from an investigation into a diff. The compliance bundle assembles SBOM, licence report, SARIF findings and VEX with SHA-256 sums and an index.

8. Stop the bleeding

An audit that is not followed by a gate gets repeated in six months with the same findings. Add a dependency check to the workflow, as in Gate a new dependency, so the number goes down instead of resetting.

What “done” looks like

Not zero findings. A repository with:

  • No KEV-listed vulnerabilities reachable from an entry point
  • No unsupported runtimes
  • No committed secrets
  • Every remaining finding either fixed, scheduled, or recorded as not-affected with a justification
  • An SBOM, so next time is a diff

That is defensible. “Zero vulnerabilities” is not achievable and claiming it is a sign nobody looked properly.