Find›Prioritize›Fix›Prove

How NextFix™ decides what to fix next

Scanners find. NextFix decides. Every vulnerability a scanner reports is asked three questions about your application, then lands in one of four decisions with its evidence attached. Most findings can wait, and the page says exactly why.

Four decisions

▲Fix now · out of cycle

●Fix next cycle · tell the owner

◔Watch · re-check on new data

○Set aside with evidence · VEX for the auditor

Reachable?

Can a request from outside actually run the vulnerable code?

Is it shipped? Development-only packages never leave the build.
Is it imported? Installed is not the same as used.
Is the vulnerable function called? One bad function in a library of hundreds.
Does an entry point lead there? The route, its auth guard, and whether request data reaches the call.

Exposed?

How close is an attacker to that route?

Without a login or behind one.
Network-published: Dockerfile, compose, the listen address.
Internet-facing: infrastructure files, or a declaration.
Observed traffic: the access logs, last 30 days, public versus internal addresses.

Exploited?

Is anyone attacking this in the wild?

Active: on CISA's Known Exploited Vulnerabilities list.
Likely: EPSS gives it a 10% or higher chance of exploitation within 30 days.
None yet: severity alone, which is the weakest signal of the three.

The reachability ladder: seven rungs from “found” to “matters”

Each rung is a fact about your code, checked in order. A finding stops at the first rung it fails.

Not shippedA development dependency; it is not in the production artifact.Set aside

Never importedInstalled by the lockfile, but no source file loads it.Set aside

Imported, never calledThe package is used, the vulnerable function is not.Set aside

No function data yetImported, but which function is vulnerable is still unknown, so it cannot be ruled out.Watch

Called, unreachedThe function is called, but no HTTP route leads to that code.Watch

In the image onlyAn OS package or tool in the container; the application never imports it.Watch · next cycle with a fix

ReachableAn entry point leads to the vulnerable call. Now exposure and exploitation decide.Fix now · next cycle

▲

Fix nowAct · out of cycle

Reachable without a login, and any of: known or likely exploitation, CVSS 9 or higher, request data reaching a high-severity call, or the internet already calling that route. Reachable behind a login only when exploitation is active.

An attacker has a path, a door, and a reason. Nothing else on the list is this.

●

Fix next cycleAttend · tell the owner

Reachable, but behind a login, or without exploitation evidence. Also: no function data yet with exploitation or high severity, or an image package with a fix and a reason to move.

Real, but the door is smaller or nobody is pushing on it. It goes in the next release, not tonight's hotfix.

◔

WatchTrack* · re-check

Called but no route reaches it; imported with no function data; or in the container image with no fix to move to.

Re-decided every night with fresh exploit data, and again when the code changes. It rises the moment the facts do.

○

Set aside with evidenceTrack · VEX

Not shipped, never imported, or the vulnerable function is never called. Or a person accepted it, with a reason, an approver and an expiry.

Exported as an OpenVEX statement with the standard justification, so the auditor gets the reason, not a shrug.

Why most findings can wait

Severity scores describe the worst case for anyone. NextFix describes the actual case for you.

1
A critical score in code you never run is noise.
Eighty to ninety-nine percent of findings on real applications are in packages that are not shipped, not imported, or whose vulnerable function is never called. They are set aside with the proof.
2
Behind a login is a smaller door.
An attacker needs credentials first. The finding is still fixed, in the next cycle, unless it is being exploited in the wild.
3
Nobody is calling it, yet.
Thirty days of access logs with no request to any route that reaches the call holds a severity-only “fix now” at “next cycle”. The first request, or new exploit data, lifts it back.
4
Not on the internet.
A service the infrastructure files, or the logs, show as internal only has an internal attacker surface. An open route there waits a cycle; the same route on the internet does not.
5
No fix to move to.
A finding with no published fix is watched and mitigated at the entry point rather than scheduled, so the queue holds work someone can actually do.

What moves a finding

The same evidence that lets things wait also pulls things forward.

Lifts it

Known exploitation (CISA KEV) or EPSS at 10% or more
No login on the route that reaches the call
Request data traced into the vulnerable call's arguments
Public traffic observed on that route in the last 30 days
Internet-facing per infrastructure files or a declaration

Holds it

Behind a login, or treated as internal in the project config
Nobody called it in a month of logs that cover this service
Internal only: the internet cannot reach the service
Loopback only: the service binds to the local host
A person accepted it, with a reason and an expiry

One rule outranks every hold: known or likely exploitation keeps a reachable finding at Fix now. Quiet routes and internal networks lower the bar for severity, never for evidence of attack.

The score (0 to 100) only orders findings inside a decision; it never changes one. Every decision carries its “why” in plain words: the route, the call, the guard, the traffic, the exploit data, the fix. Data: OSV advisories, FIRST EPSS, CISA KEV, your own logs and infrastructure files. Nothing leaves your machine but those lookups.

nextfix.grcsac.com · Apache-2.0 · free · NextFix and the NextFix logo are trademarks of GRCSAC LLC.

This page is laid out as one tall sheet for printing: use your browser's Print command to keep a copy. The full rules are in the decision model document.