How Do We Manage Vulnerabilities?

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 artifact, 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.

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

CVE has long been the vulnerability tracking and distribution method for discovered vulnerabilities. CVEs tied to versions help to sort through which 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. 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 favor 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?

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.

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.

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 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) where the hardware itself remains the lagging anchor as the core problem remains. 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.

Don't just accept the outcomes. Actively participate in guiding associated process changes that follow from base changes such as what we are seeing 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.