How it decides what to fix first

sbomtriage uses fixed rules and published thresholds, and gives every finding a reason in plain English. There’s no opaque risk score, and nothing on this page is a judgement call. If you disagree with something, you can point to the exact rule.

How urgency is decided

Severity alone is a poor sort order: a medium being exploited this week matters more than a theoretical critical. Every finding goes into one of four tiers, based on whether a fix exists and what the exploitation data says.

Tier	Assigned when
Fix now	a fix exists AND (the vulnerability is in CISA KEV OR EPSS >= 0.50)
Fix soon	a fix exists AND (EPSS >= 0.10 OR CVSS >= 7.0 OR published severity is high/critical)
Monitor	a fix exists, but there's no exploitation signal or high severity
No fix available	listed separately so it doesn't dilute the action list, and flagged urgent when in CISA KEV

KEV always fix nowEPSS ≥ 0.5 fix nowEPSS ≥ 0.1 fix soonCVSS ≥ 7 fix soon

How the plan is ordered

The plan lists upgrades, rather than CVEs. Upgrades are compared on each criterion in turn, and the first criterion that differs decides the order.

1Highest tier contained in the action
2Number of KEV-listed vulnerabilities resolved
3Highest EPSS score resolved
4Number of vulnerabilities resolved
5Smaller upgrade distance (patch before minor before major)
6Direct dependencies before transitive ones

Which version is recommended

The recommended version is the lowest version, at or above the highest version present, that resolves the most known vulnerabilities for that package. It isn't necessarily the latest release, which keeps upgrades practical to apply.

Nobody applies a plan full of major-version jumps, so the recommendation is the minimum safe upgrade rather than the newest release. If the latest published fix is higher, both are shown.

How the grade is calculated

The grade is a summary and plays no part in ranking. No finding’s position in the plan depends on it, and every report shows the arithmetic behind its score.

Start at 100.
Subtract 25 if any vulnerability in CISA KEV has a fix, and 15 if any in KEV has none.
Subtract 8 per fix-now action, up to 40.
Subtract 3 per fix-soon action, up to 20.
A finding published with no severity score counts as high, so an upgrade that clears one and would otherwise be rated monitor counts as fix soon.
Subtract 50 if the SBOM declares no components at all, because nothing can be concluded from it.
Subtract up to 20 in proportion to how much of the SBOM couldn't be matched.
If a vulnerability data source failed during the scan, or part of the input couldn't be assessed, the grade is flagged as possibly optimistic. The score doesn't change.

A90-100

B75-89

C60-74

D40-59

Fbelow 40

On a tracked project, muted findings are left out of this calculation. The number of mutes is shown next to the grade, and each mute keeps its reason.

What happens to your file

1
Size-checked as it streams
The upload is capped while it arrives, rather than afterwards. A Content-Length header is optional and easy to forge, so it isn’t treated as a limit.
2
Parsed in memory
The file is never written to disk or logged. Depth and component limits are enforced before and during parsing.
3
Hashed, then released
The inventory is hashed for de-duplication and the raw bytes are dropped. From then on, only the parsed structure exists.
4
Only coordinates and CVE IDs leave the machine
purl@version pairs go to OSV.dev to look up advisories, and the CVE identifiers found go to FIRST for EPSS scores. Filenames, supplier names and other metadata aren’t sent.
5
The report is kept, the file isn’t
A report lasts 24 hours under a 128-bit random ID, and you can delete it sooner. The SBOM itself is never stored. On a tracked project, the inventory read from the file is kept until you delete the project, but the file still isn’t.

What it can’t tell you

Each of these is a real limit of analysing an inventory instead of a running system.

Whether a vulnerable function is reachable: That needs source or bytecode analysis, and an SBOM contains neither. So every finding here means “this component is present and known to be vulnerable”, rather than “you are exploitable”.
Whether you have been compromised: “Fix now” means a known-exploited flaw is present in your inventory. It describes your software, and says nothing about your logs.
Anything your SBOM generator missed: Vendored code, statically linked libraries and bundled assets don’t show up here. That’s why every scan reports its coverage.
Whether a compensating control already handles it: Network position and runtime configuration aren’t considered. A finding that’s unreachable in your deployment is still listed, and you can mute it with a reason.

Known limits of the data

Advisory coverage is OSV.dev: A vulnerability published minutes ago won’t appear, and neither will one in an ecosystem OSV doesn’t cover.
Distro matching is done twice: Distro packages are queried both by package URL and by their native ecosystem, because OSV’s purl matching is unreliable for Alpine and some RPM distributions. A distro component with no release identifier may be over-reported across releases.
Unmatchable components are never called safe: A component with no package URL can’t be matched at all. It’s counted, shown in the report and left out of any coverage claim.