Security teams have long prioritized high-severity vulnerabilities while often postponing fixes for lower-severity issues. That approach may soon become more dangerous.
Today's vulnerability management practices were built for a pre-AI world. According to TuxCare CEO Igor Seletskiy, AI models are beginning to identify chains involving multiple low- and medium-severity vulnerabilities that human researchers would rarely connect. Individually, these flaws might not warrant urgent action. Combined, they can lead to a complete system compromise.
A longtime entrepreneur in the Linux, hosting, and cybersecurity industries, Seletskiy believes enterprises are focusing on the wrong metric. The future risk, he said, is not necessarily an increase in high-severity Common Vulnerabilities and Exposures (CVEs). It is AI's ability to create high-impact exploits from vulnerabilities that were never considered high risk in isolation.
"What breaks is using it as a prioritization gate because it has no concept of composition. Three low flaws, an info leak, a memory bug, and a weak sandbox can chain into a full compromise even though no single link is critical," he told LinuxInsider.
The Greater Threat
Seletskiy is more concerned about another emerging risk. The threat is not the CVE score at all. It is how many vulnerabilities you carry.
Every open flaw is another link that can combine with the rest. The number of possible chains grows exponentially with that count, not linearly.
"A score of three shouldn’t read as safe to defer. It should read as a potential link in a chain, and the total number of open vulnerabilities becomes a first-class risk metric in its own right," he warned.
Seletskiy contends that if CVE scoring needs an overhaul, it should become more contextual. What else is running on a server and how much remains unpatched matters more than any single base score.
If counting high-severity CVEs is the wrong metric, chief information security officers (CISOs) should track software vulnerabilities by specific key performance indicators (KPIs). He suggested they stop measuring incoming vulnerabilities and start measuring their own exposure and remediation throughput.
"Counting critical CVEs tells you what the world produced, not what your risk is," he said.
Track 4 Things Instead
Seletskiy is known for his passion for helping organizations improve security, uptime, and compliance through automated live patching and extended lifecycle support for Linux and open-source software. Instead of relying on isolated CVE scores, he recommends tracking these metrics:
- Time from vulnerability discovered to patched across the whole fleet. Look at the full clock, not just your deploy speed, and for lows and mediums. If the vendor takes six months to ship the fix, your deployment speed is irrelevant. Favor software and vendors that turn fixes around fast, because their patch latency becomes your exposure.
- Backlog size, not just age. The raw number of open vulnerabilities is now a risk metric in its own right because chaining risk grows exponentially with it — 200 deferred lows are not 200 small problems. They are the raw material for an enormous number of possible chains.
- Backlog age: how long flaws sit open. A chain only needs its links to stay open long enough to be assembled.
- Stop treating "not reachable" as "safe." Chaining breaks that filter. A flaw that is unreachable today becomes reachable the moment another link opens the path to it.
"Your chaining risk is a function of how many flaws you carry and how long they stay open. So measure the backlog and the speed at which you clear it, not the severity of the inbound," he summarized.
How 3 Minor Flaws Become One Major Breach
Seletskiy used a scenario based on three flaws that busy security teams commonly postpone fixing.
The first is a low-severity info leak — a verbose error that exposes a memory address. The second is a medium-impact access-control or server-side request forgery (SSRF) gap that allows a low-privilege user to reach an internal service. The third is a memory-corruption bug in that service, which everyone called "not practically exploitable" because address space layout randomization (ASLR) makes it unreliable without knowledge of the memory layout.
He explained that, individually, these are the kinds of flaws IT teams routinely postpone fixing. However, once chained, flaw one provides the memory layout that makes flaw three reliable. Flaw two gives the path to reach it. Now it is a dependable remote code execution, and the hacker owns the server.
"The AI's contribution isn't finding any one of them. It’s recognizing that the leak is exactly the missing ingredient that makes the memory bug work, across components your triage looked at on different days and closed as low," Seletskiy noted.
He continued, "It needn’t stop at three. A machine will happily build a ten- or 20-link chain no human would ever trace by hand. That’s why the raw count of 'harmless' flaws you carry matters so much. Every extra one is another rung the chain can use."
Tip the Scales Back to Defenders
According to Seletskiy, one seemingly logical solution doesn't work. Trying to pre-chain is a trap. The odds favor the attackers, who only need to find one viable chain.
"You’d have to map them all, and the number grows exponentially. That’s a race you can’t win," he said.
The more effective solution requires rethinking how software is built and maintained, rather than using defensive AI. Predicting chains plays the attackers' game on a board tilted in their favor. Instead, reducing the number of things that can be chained at all is the game that defenders can win.
Seletskiy recommended eliminating the vulnerabilities that enable chaining. Take away the links so there is nothing to assemble.
"Because the risk grows exponentially in the count, every flaw you remove strips out a disproportionate amount of it," he said.
That approach comes down to two priorities: First, harden software so fewer flaws are introduced through secure development practices, memory-safe languages, reduced attack surfaces, and real isolation. Second, rapidly eliminate the flaws already in your systems.
Loading ...
