- InfoWorld argues that a CVSS severity score is not a fix queue, and OWASP's CVE Lite CLI pairs it with an exploitation forecast.
- Scanners leave out context such as reachability and internet exposure, so teams still own the final priority call.
- Ask how your team ranks scan results, how it handles brand-new CVEs, and who owns upgrades blocked by parent packages.
A long list is not a plan
A dependency scan of a mid-sized JavaScript project can return 10, 20 or even 50 findings, InfoWorld reports. Many carry the same "high" label. Someone still has to choose the first one to fix.
The common habit is to start with the highest CVSS number. InfoWorld argues that this treats a severity score as a to-do list. The two are different things.
Here is the idea to keep. Severity describes the flaw. Priority is a choice about that flaw in your own setting. A scanner can give you the first. Only your organisation can give you the second.
What each score says
CVSS rates how serious a flaw is on technical grounds. It looks at how an attack is delivered, how hard it is, what access it needs, and the harm to data and uptime.
It cannot tell you whether your code ever runs the faulty part. It also does not know if the system faces the internet. And it does not show whether anyone is using the flaw.
EPSS, the Exploit Prediction Scoring System, asks a different question. FIRST maintains it and updates it daily. It estimates the chance that exploitation of a published CVE will be seen in the wild within 30 days.
EPSS gives a probability and a percentile, and people mix them up. The percentile only shows where a CVE ranks among scored CVEs. A CVE at the 93rd percentile ranks above 93% of them.
That is not a 93% chance of attack. Exploitation is uncommon. So a CVE can rank near the top while its real probability is only a few percent, InfoWorld says.
EPSS is also a forecast, not proof. To confirm that attackers are using a flaw, you need another source. InfoWorld points to the CISA Known Exploited Vulnerabilities catalog (KEV) or reliable threat intelligence.
How CVE Lite CLI sorts the list
CVE Lite CLI is a free scanner. It is an OWASP Lab Project, and Sonu Kapoor is its maintainer. It reads a project's lockfile on your machine. It checks the OSV database and the npm registry advisory API, then prints upgrade commands you can copy and run. The README says no source code leaves your machine.
The tool merges CVSS severity and EPSS into four tiers. InfoWorld names two of them, Fix Soon and Monitor. It calls them decision lanes, not a strict ranking. They tell you which question to ask next.
One example from InfoWorld shows why. A reachable Monitor finding on an internet-facing login service may matter more than a Fix Soon finding in a tool nobody uses.
InfoWorld also says the 90th-percentile line is a default the tool's authors chose. It is not a rule of the field. A team that adopts it takes on someone else's cut-off. Check that it fits your risk.
Why a fix is rarely one line
A vulnerable package is often present only because another package needs it. The README explains the problem. One of your direct dependencies may hold that package below the fixed version. Clearing it then takes a major upgrade that can break things. A plain scanner does not say so.
CVE Lite CLI's DM001 rule flags this case. It also flags direct dependencies that npm has marked deprecated. For a manager, a "simple" patch may turn out to be an upgrade project with testing attached.
The fix can carry its own risk. The README points to the chalk and debug compromise. A tampered release was live for about two hours before anyone caught it. Package managers have added a release cooldown that skips that early window.
The tool reads the cooldown your project already sets. It warns if a suggested fix is newer than that window. The warning is advisory, and exit codes do not change.
What the tool does not do
The maintainers list the limits plainly. The tool cannot spot malicious packages before they show up in advisory data. It does not analyse package behaviour or content. It does not prove a flaw can be exploited or check runtime reachability. Its scope ends at a project's dependencies, so built images, credentials and infrastructure setup need other tools. For now it covers JavaScript and TypeScript only.
Reachability is the missing piece. None of the scores here tells you whether your code calls the faulty function.
InfoWorld poses a further question. What should a team do with a new CVE that has a high severity score but no EPSS or KEV record yet? Your team needs its own written rule.
Questions to put to your team
Ask how the team ranks scan results today. If the answer is "by CVSS", ask what happens to a medium finding that is being exploited.
Ask who knows which systems face the internet and which tools are unused. Ask whether that knowledge reaches the person reading the scan.
Ask what the rule is for brand-new CVEs with no exploitation data. Ask whether a fix released hours ago may be installed, and whether a cooldown is set.
Ask how many findings are blocked by a parent package that needs a major upgrade. Ask who owns that work.
A scanner can sort the list. Deciding what the list means for your business stays a human job.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: OWASP.
