- Aikido Security argues that finding a vulnerable function in your code is not the same as showing an attacker can use it.
- A severity score describes a flaw in general. Your own code and setup decide the real risk.
- Ask your team whether tools report reachable or exploitable, and who approves each downgrade.
A scanner flags a flaw in a software library your team uses. The severity score is 7.2 out of 10. An engineer has to decide how much it matters. The score cannot say, because it describes the flaw in general, not your application. The better question is whether an attacker can meet the conditions the bug needs, in your setup. Aikido Security, a security vendor, set out that distinction in a blog post published on October 17.
Two questions that sound alike
Aikido describes reachability analysis as a check on whether your code can run the vulnerable function inside a dependency. A tool traces the routes from your own code into the libraries it relies on. Security people call that trace a call graph.
Aikido says older scanners flagged every known flaw in every dependency. That included indirect ones your code didn't call. Reachability tied each finding to your actual code. It turned a dependency alert queue into one a team could work through.
Exploitability is a separate question. Aikido lists what else a bug may need. The attacker's input must arrive in the right form. An optional feature may need to be switched on. The attacker may need certain account privileges. The setup must also let the result do real harm.
Aikido points to CISA's VEX status justifications. They list two different reasons a product is not affected. One is "vulnerable code not in execute path". The other is "vulnerable code cannot be controlled by adversary". The first is a reachability verdict. The second is an exploitability verdict.
One lodash flaw, three apps
Aikido's example is CVE-2021-23337, a command injection flaw in Lodash, a widely used JavaScript utility library. It sits in the _.template function in versions before 4.17.21.
The mechanism is simple. Lodash pastes one of the function's options straight into code it generates, with no cleaning. If an attacker controls that option, they can supply a command instead of a plain name. The command then runs as the template is compiled.
Aikido gives the flaw a CVSS score of 7.2. It reports an EPSS score of about 21% in October 2026, higher than 97% of scored CVEs. EPSS estimates the chance a flaw is exploited somewhere in the wild within 30 days. Aikido says CISA's Known Exploited Vulnerabilities catalog lists about 1,700 CVEs. This flaw is not one of them. Aikido adds that none of these figures reflect the context of your app.
Aikido then compares three apps that all use a vulnerable lodash version.
App A only uses simple collection helpers such as map and filter. It does not call _.template, so reachability analysis can dismiss the finding.
App B uses _.template to render an email. The developer wrote both the template and its options. The function is reachable, but an attacker cannot influence the vulnerable option. Exploitability analysis can downgrade the finding and record why.
In App C, data from incoming requests is copied into the template's options. The attacker's input can reach the vulnerable setting. The finding stays a priority.
Same flaw, same score, three different responses.
A "not exploitable" verdict expires
Aikido says a verdict only describes the code and deployment as they are today. Four kinds of change can overturn it: a new place that calls the function, a new route for user input, a changed setting, or an updated base image.
Lodash itself shows how. Aikido says the 2021 patch checked the variable option but left a gap. The key names in options.imports were not validated, and they reach the same Function() constructor. That second route was later logged as CVE-2026-4800 and closed in lodash 4.18.0.
Aikido also describes a scenario for App B. Prototype pollution is a bug class where an attacker plants extra properties on Object.prototype. Nearly every JavaScript object inherits from it. Aikido says _.template copies inherited properties into imports. A pollution bug elsewhere in App B could therefore open that route, with no change to App B's template code.
The lesson here is that a downgrade is a judgment about the whole application, not one line of it.
Triage becomes a delegated decision
Aikido sells a product that automates this judgment. It says its agent inspects the code repository and the container the app ships in. That includes the Dockerfile, the base image, the operating system distribution and how the container is run. The agent decides whether a finding is exploitable.
It then takes only the actions you permit: ignore, snooze, downgrade or upgrade. Each decision comes with written reasoning that a reviewer can read before approving.
Two cautions apply. This is a vendor describing its own product. The post gives no accuracy figures. The implication is that once software helps decide which flaws to set aside, the written reasoning becomes the control that matters.
Questions for your security team
Ask whether your tools report that code is reachable or that it is exploitable. Ask how many findings get patched only because they cross a CVSS threshold. Ask what that costs in engineering time.
Ask where the written reason for each downgrade is stored, and who approved it. Ask what triggers a re-check, such as a new endpoint, a configuration change or a new base image.
If an automated agent is involved, ask which actions it can take without a human. Ask what evidence shows its verdicts are right.
A severity score describes the flaw. Only your own code and deployment show the risk, and that answer needs checking each time they change.
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: Aikido Security.
