Find›Prioritize›Fix›Prove
Scanners find. NextFix decides.
A scanner hands you a thousand vulnerabilities in no particular order. NextFix reads your own code alongside the advisories, works out which of them an attacker can actually reach, and keeps a written reason for every one it sets aside.
In development at GRCSAC v0.3.0
The problem
Most of the list is not a way in
A dependency scanner tells you that a package you install has a published advisory. It does not know whether your application loads that package, whether it calls the affected function, or whether anything a stranger can send a request to leads there.
NextFix works that part out. It builds a call graph of your source, finds the HTTP entry points and their authentication guards, and traces whether a path exists from an entry point to the vulnerable call. Of the twenty findings in the sample application, fourteen are set aside, because the package is only present at build time, or nothing imports it, or the risky function is never called. Two more are watched: the function does run, but nothing an outsider can touch reaches it. They are all still real advisories. They are just not a route into this application today, and NextFix records why.
The decision
Four buckets, in the order you work them
Every finding lands in one bucket with a score from 0 to 100 for ordering inside it. The model follows SSVC, so the question it answers is what to do about a finding rather than how large its CVSS number is.
Act
Reachable from an entry point, and the surrounding facts say this one should not wait for the next release.
Attend
Reachable, but behind authentication or without the exploit pressure that would justify stopping other work.
Track
Not shipped, never imported or never called. Set aside with evidence an auditor can read.
Track*
The vulnerable function runs somewhere, but nothing public reaches it yet. Re-checked on every scan.
Each bucket carries an icon and a label as well as a colour, and the ring draws red, amber, blue and cyan in an order checked against colour-vision deficiency.
Reachability
Six tiers, each one graded by how good the evidence is
Reachability is not a yes or a no. A package can be absent from the shipped artifact, present but unused, used but never called at the vulnerable function, or genuinely wired to a route. NextFix names which of those it found.
| Tier | What NextFix found | Default |
|---|---|---|
dev-only | A development dependency, so it is not in the shipped artifact. | Set aside |
unused | Installed, but no source file imports it. | Set aside |
imported-not-called | Imported, but none of the vulnerable functions are called. | Set aside |
imported-unknown-symbol | Imported, and there is no function-level data for this advisory yet. | Watch |
called-unreached | The vulnerable function is called, but no entry point leads to it. | Watch |
reachable | An entry point leads to the vulnerable call. | Fix next cycle |
A reachable finding is then graded on whether the entry point requires authentication, whether request data reaches the call, whether the service is published on a port, and what EPSS and the CISA KEV catalogue say. The full model is here.
The dashboards
One scan, read two ways
The Overview is for the person who has to report upward: how many need action, which entry points are open to the public, whether the number is going down. Findings is for the person who has to do the work.
Evidence
A reason you can hand to an auditor
The hard part of leaving a vulnerability open is not the decision. It is
explaining the decision a year later to somebody holding a scan report.
Every set-aside in NextFix is exported as an OpenVEX statement with the
standard justification vulnerable_code_not_in_execute_path,
which Dependency-Track and other tooling already understand.
- A plain-English why on every finding, written out line by line, including the ones nobody has to act on.
- The call path from the entry point to the vulnerable function, with file names and line numbers.
- A full JSON report and an OpenVEX document per scan, both stamped with the version of NextFix that produced them.
- Scan history in a local SQLite file, so you can show that the actionable count moved.
Where it runs
On your machine, or on a server you own
NextFix is self-contained. You point it at a project folder, it reads the lockfile and the source, and the report stays where it was produced. There is no account to create and no NextFix service behind it.
The only outbound traffic is advisory data: OSV
for the advisories, FIRST EPSS
for exploit probability, and the
CISA KEV catalogue
for confirmed exploitation. Those responses are cached locally, and
--offline reuses the cache so a scan can run with no network
at all. Your source code is never uploaded anywhere.
Status
Version 0.3.0, still being built
Today NextFix reads Node.js projects with a package-lock.json
and understands Express entry points. Python and Go are next, along with
container image inventory and function data derived automatically from
the commits that fix each advisory.
NextFix is open core. The engine, the command line, the local server and both dashboards are licensed under Apache 2.0. Single sign-on, roles, an audit log and the curated vulnerable-symbol feed are the commercial side, and they are not written yet.
There is nothing to download at the moment. If this is a problem you have at your own company, write to contact@grcsac.com and we will let you know when there is a build worth trying.
Point NextFix at code you own or are authorized to assess.