How Do We Manage Vulnerabilities in the Age of AI?

Vibe coding, where developers guide AI agents to build software rather than writing line-by-line code, and the use of AI to secure it has taken over. Even sophisticated developers have transitioned due to speed and the ability to 10x their work. The implications extend far beyond how we write software - they reach into how we discover, track, and remediate vulnerabilities. The downstream processes from software development must adapt.

Consider what happens when a developer alerts the AI of a discovered vulnerability. The likely pattern is that the AI will scan through the code looking for similar vulnerabilities and ask if they should be resolved as well. A thorough review of the code base is performed to remove that type of vulnerability.

Another possibility is that the code will be regenerated from the artefact, and other existing vulnerabilities may be reduced. The model or training data may have learned improved patterns for software architecture, alignment to zero trust, and API security improvements. Since the code is being reconstructed, the vulnerabilities you seek to fix may be resolved along with an entire set that was unknown.

The limits of traditional vulnerability tracking

That changes the question we should be asking about Common Vulnerability Enumeration (CVE).

CVE has long been the vulnerability tracking and distribution method for discovered vulnerabilities. CVEs tied to versions help to sort through which ones no longer apply. CI/CD pipelines where applications are pushed out from that pipeline operate differently than code bases that a vendor would provide updates to be deployed at customer sites.

For years, we have had a different model in cloud native architectures to patch and remediate vulnerabilities without this distributed impact to customers. There have also been noted issues on which CVEs should be prioritised.

Reconsidering CVEs in a CI/CD world

But what happens as entire codebases are written anew using more secure languages and updated architecture patterns? The existing set of vulnerabilities may be removed (or potentially replaced with some new ones, hopefully far fewer). Gradually we should see a much reduced necessity to track vulnerabilities as older more vulnerable software is deprecated in favour of updated coding languages, improved architectural patterns, and software assurance improvements through AI.

So here is the question worth raising: if a vulnerability is discovered and resolved within a platform managed in a CI/CD pipeline, and you know it is resolved, should the CVE go away?

From historical record to operational signal

The purpose of the catalog is to coordinate awareness and remediation across vendors and operators who might still be exposed. If the remediation is confirmed, automatic, and verifiable - and if no impacted version remains running in the wild - what does the active CVE still serve?

Keeping it as a historical record has value for retrospective analysis. But as a live signal in a threat feed, it is noise. We should be starting to think about the best mechanisms to track vulnerabilities in a highly dynamic environment where new code and patches can not only be generated quickly, but we can also shift workloads to use updated software due to the improved resilience enabled by cloud native platforms and CI/CD pipelines.

Revisiting CVSS

This dynamic speed doesn't just break how we track vulnerabilities (CVE); it also reshapes how we score their severity (CVSS). CVSS may shift to include considerations for the operating environment of code as well. The code may be vulnerable, but how vulnerable is it if the operating environment controls are considered? Not all workloads execute within a trusted execution environment (TEE) or secure enclave, but some do. Additionally, the system may be verifying changes in running code to quickly detect exploits of known vulnerabilities, so the harm may be reduced or prevented. A static base score that ignores all of that increasingly tells us less than it used to.

What remains vulnerable?

With numerous news articles stating vulnerabilities may go away, it's an exciting time. That may happen, but we are not there yet. Even once code is universally improved with use of languages that prevent memory safety vulnerabilities, we still have the possibility of embedded malicious code (insider threat) or hardware-based vulnerabilities that are resolved in software or firmware that may flag a problem (e.g. SPECTRE/Meltdown).

AI can rapidly rewrite software to work around hardware flaws, as with SPECTRE/Meltdown (speculative execution in hardware). In this case, the hardware itself remains the lagging anchor as the core problem. With software, it is possible to transition an entire codebase over a weekend to a language known to improve memory safety. Legacy code is quickly disappearing, and this will continue over the next few years.

The next evolution of vulnerability management

Don't just accept the outcomes. Actively participate in guiding associated process changes that follow from what we are seeing in an incredible evolution in software development.

CVEs, CVSS, and threat feeds were built for a slower, more static world. We should be stepping back to consider the implications not only to vulnerabilities and exploits, but to the processes we use to manage them and the implications to our environments.

This article was originally published over on the Security Bias blog.