Finding the dependency risk that a vulnerability count kept hiding

The software supply chain programme was measured by how many known vulnerabilities the dependency scanner reported, which meant it was measured by a number nobody could move and nobody trusted.

• 900 open CVEs with no way to prioritise

  Most were in transitive dependencies on code paths the application never executed. Upgrading them all would have taken a quarter and changed nothing about the actual exposure.

• The build system was outside the inventory

  Scanning covered application dependencies. The plugins, runners and build tooling that could inject code into every artefact were not scanned by anything.

• Vendor firmware entered without review

  Third-party components shipped with firmware that reached the same network as the build system, with no process to assess it before it arrived on the floor.

• The metric rewarded the wrong work

  Reducing the CVE count was easiest to do by upgrading trivial dependencies. The genuinely exploitable issues were harder and did not move the number faster.

The programme was re-pointed from counting known vulnerabilities to proving which ones were reachable, and from scanning applications to scanning everything that touches the artefact.

1. 1

   Reachability analysis over the dependency graph

   900 → 23

   For each CVE, static analysis determined whether the vulnerable function is reachable from an application entry point. Unreachable findings are recorded and suppressed with a reason rather than being silently dropped.

2. 2

   Build pipeline brought into scope

   Critical found

   CI runners, plugins and build containers were inventoried and tested as production systems. A plugin with a remote code execution flaw and write access to every artefact had been in place for nineteen months.

3. 3

   SAST across Java and Go services

   Per commit

   Ninety-plus rules ran against first-party code alongside the dependency work, on the argument that the code the team writes deserves at least the scrutiny given to the code it imports.

4. 4

   Artefact provenance and signing

   Every build

   Build outputs are signed and their provenance recorded, so a substituted artefact fails verification at deploy rather than being detected by inspection afterwards.

5. 5

   Vendor component intake assessment

   Per intake

   New third-party components get a standard assessment before they reach the floor network: exposed services, default credentials, update mechanism and network requirements.

First two quarters of the re-pointed programme, compared against the prior dependency-scanning baseline.

900 → 23

Exploitable dependency findingsReachability analysis, with suppressions recorded

1

Critical in the build systemRCE in a CI plugin with write access to every artefact

19 months

How long it had been thereNever scanned, because build tooling was out of scope

97%

Less remediation workMeasured in packages requiring upgrade

100%

Release artefacts signed and verifiedProvenance enforced at deploy, from the day the gate went live

8 days

Median fix time on reachable CVEsDown from an unbounded backlog

• A CVE count is a measure of your dependency tree, not your risk

  Ninety-seven percent of the backlog described code that never executed. The metric was moving effort away from the twenty-three findings that could actually be exploited.

• The build system is production

  Anything with write access to every artefact you ship is a higher-value target than most of what you ship. It sat outside the scanning scope for nineteen months for no better reason than convention.

• Record suppressions, do not hide them

  Unreachable findings are suppressed with a stated reason and re-evaluated when the code changes. A silent drop is indistinguishable from a missed finding at audit time.

• Provenance turns a detection problem into a verification one

  Signing artefacts and checking them at deploy replaced a question that required investigation with one answered by a boolean.