Why we need to build AI into our network appliances 

COMMENTARY: Cisco's work to uncover vulnerabilities using AI has been genuinely impressive: 1.8 billion lines of code, 25 languages, and a sub-3% false-positive rate.

But finding vulnerabilities at machine speed without closing the gap on the patching side just widens a chasm that’s been killing security teams for more than a decade.

[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]

The constraint on defenders has never been whether they knew about the bugs. It’s the change-control window, the maintenance contract that must stay current to even download the fix, and the operational reality that an edge device carrying customer traffic does not get rebooted on a researcher's timetable. Security teams are trying to do the responsible thing.

The problem here: the responsible thing – applying patches with minimal operational disruption – was already a losing race when humans were writing the exploits.

Now, we have handed the exploit-writing side a rocket engine while the remediation side still pedals a bicycle.

Put AI power behind patching

The industry now needs to point the same AI horsepower at its patch management problems.

Vendors are happy to ship AI-generated CVEs because each one becomes a reason to renew support. However, they are not in any hurry to ship AI that helps customers absorb the vulnerability firehose.

The discovery side has been industrialized, while the remediation side is still a person at a keyboard at 2 a.m. on a Friday…and it’s always a Friday. The next round of in-the-wild exploitation will live in that gap.

More vulnerabilities mean more lackluster CVE records

Here’s the part that makes the gap worse, not better. The more vulnerabilities we discover, the more the public data we rely on to prioritize them degrades, because the enrichment never kept pace in the first place. 

The answer was always supposed to be for CNAs to enrich their own records – and they are not.

The examples aren’t hard to find:

It’s not a rounding error. The Verizon DBIR has been telling us for years that exploitation of known vulnerabilities as an initial access vector continues to climb, while remediation of those same vulnerabilities consistently lags.

It’s not possible to remediate quickly off data that’s incomplete, untagged, and missing the affected configurations that tell us if we are exposed.

How the Arista vulnerability became the whole problem in one CVE

If we want the full scope of the dysfunction compressed into a single example, look at CVE-2026-7473 in Arista EOS. 

Arista published the advisory on May 5, 2026, assigned the CVE in the document, and stated that the issue had been reported as exploited in the wild.

For roughly one month after that, if a researcher queried the public CVE databases and asked for every Arista CVE, this one did not come back. Arista had published it on its own site, but the record had not propagated to the databases that the rest of us build our tooling on.

The only way to know about this actively exploited vulnerability was to personally subscribe to and read Arista security advisories. It did not reach the CISA KEV until June 9.

Arista said in the advisory that they wouldn’t issue a patch, only configuration-based mitigations in the form of ACLs around the tunnel decapsulation process.

So vulnerability scanners are likely to miss this or misreport it, because the affected version list covers essentially every release, and being on an affected version does not mean we are vulnerable.

The vulnerability and the fix both live in the configuration, not in a version string. Unless our tooling can read and reason about the running config and confirm whether the mitigating ACLs are present and correct, the green checkmark it gives us doesn’t mean anything.  

An actively exploited bug, invisible to the public databases for a month, with no patch coming, that a version-based scanner cannot see represents the exact type of vulnerabilities attackers love.

If the team plans to hunt for vulnerabilities in its own environment and patch its way to safety, it’s already too late.

The CVE data doesn’t help as much as it could; the enrichment gaps mean we can’t fully trust the prioritization we do have, and the discovery-versus-remediation gap widens by the month as AI industrializes one side of the equation while ignoring the other.

We must assume some of this has already gotten through, which means the work shifts from "find the vulnerable thing and patch it" to "hunt for the indicators-of-compromise and detect the intrusion early," because detection is the control we still own.

And we have to add prevention, real integrity, and configuration monitoring on the devices that matter, which for network edge devices and appliances, largely do not exist today.

There’s no EDR on our firewall yet. There’s no agent on our switch either. That’s exactly the blind spot the threat actors operate in – and it’s exactly where the AI we are not building yet would do the most good.

Paul Asadoorian, principal security researcher, Eclypsium and longtime host of the SecurityWeekly podcast.

SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.