Decide, Then Fix: The Only Two Steps That Matter

The views expressed in this piece are those of the author.

Every dependency scanner produces a list. The list was never the problem. The problem is what happens after the list, and for most teams the honest answer is: not much, not quickly.

Notice what is missing from the two steps that matter. Finding is not one of them. A finding, whatever its source, a scanner, a public feed, runtime telemetry, a call graph, is just an input. Producing that input is table stakes and largely commoditised, and it can come from anywhere. Verifi does not much care where it comes from. It cares what happens next.

Decide

This is where noise gets separated from risk. Not every CVE in your tree is reachable from your code. Not every finding has a fix. Policy decides what counts as a violation, what has a fix path, and whether the right response is to fix it, gate it, or block it. Verifi ships sensible policies out of the box, and you can write your own. A finding without a decision is just more noise.

Fix

This is the step everyone skips, and it is the only one that changes your risk. Knowing that log4j-core is vulnerable does nothing on its own. Bumping it to the fixed version, direct or transitive, and getting that change merged, is the entire point.

So we built the fix in. For anything with a known fix, the CLI makes the change and opens the PR. For anything without one, it gates the build. Same policy, applied further up the chain, blocks a malicious package before it ever installs. Decide, then fix, and only the fix moves the number that matters.

Detection was never the hard part. Closing the gap between a finding and a merged fix is. That gap is the product.