# Rethinking vulnerability management in the age of AI and CI/CD > Source: > Published: 2026-06-18 22:55:52+00:00 [Tanveer Mahendra's orginal](https://unsplash.com/@tanveermahendra?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)on [Unsplash](https://unsplash.com/photos/a-white-and-red-usb-drive-sQK8HdKUvQA?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText). [Vibe coding](https://en.wikipedia.org/wiki/Vibe_coding), where developers guide Artificial Intelligence (AI) agents to build software rather than writing line-by-line code, and the use of AI to secure it, have taken hold. Even sophisticated developers have transitioned because of speed and the ability to increase their output tenfold. 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 to a discovered vulnerability. The likely pattern is that the AI scans the code, looks for similar vulnerabilities, and asks whether it should resolve them as well. A thorough review of the codebase is then performed to remove that type of vulnerability. Another possibility is that the code is regenerated from the artefact, which may reduce other existing vulnerabilities. The model or training data may have learned improved patterns for software architecture, alignment to zero trust, and API security improvements. Because the code is being reconstructed, the vulnerabilities you seek to fix may be resolved alongside an entire set that was previously unknown. This changes the question we should be asking about the Common Vulnerabilities and Exposures (CVE) system. CVE has long been the primary method for tracking and sharing discovered vulnerabilities. CVEs tied to versions help identify which vulnerabilities no longer apply. CI/CD pipelines, where applications are pushed out continuously, operate differently from codebases where vendors provide updates for customers to deploy onsite. For years, cloud-native architectures have used a different model to patch and remediate vulnerabilities without distributing impact to customers. There have also been ongoing challenges in deciding which CVEs should be prioritized. But what happens as entire codebases are rewritten using more secure languages and updated architectural patterns? The existing set of vulnerabilities may be removed, or potentially replaced with new ones, ideally far fewer. Over time, we should see less need to track vulnerabilities as older, more vulnerable software is deprecated in favour of modern languages, improved architecture, and AI-driven software assurance. This raises an important question: If a vulnerability is discovered and resolved within a platform managed through a CI/CD pipeline, and you know it is resolved, should the CVE still exist? The purpose of the CVE catalogue is to coordinate awareness and remediation across vendors and operators who might still be exposed. If remediation is confirmed, automatic, and verifiable, and if no impacted version remains in use, what role does an active CVE serve? Keeping it as a historical record has value for retrospective analysis. However, as a live signal in a threat feed, it becomes noise. We should start considering better mechanisms for tracking vulnerabilities in highly dynamic environments, where new code and patches can be generated quickly, and workloads can shift to updated software through the resilience of cloud-native platforms and CI/CD pipelines. This pace of change not only challenges how we track vulnerabilities through CVE, but it also reshapes how we score their severity using the Common Vulnerability Scoring System (CVSS). CVSS may need to include greater consideration of the operating environment. Code may be vulnerable in isolation, but how vulnerable is it when environmental controls are taken into account? Not all workloads run within a trusted execution environment or secure enclave, but some do. In addition, systems may verify changes in running code to detect exploits of known vulnerabilities quickly, reducing or preventing harm. A static base score that ignores these factors increasingly tells us less than it once did. Despite numerous reports suggesting that vulnerabilities may disappear, we are not there yet. Even if code is widely written in languages that prevent memory safety vulnerabilities, risks remain. These include embedded malicious code from insider threats and hardware-based vulnerabilities that require software or firmware mitigation, for example, [Spectre](https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)) and [Meltdown](https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)). AI can rapidly rewrite software to work around hardware flaws, as seen with Spectre and Meltdown, which exploit speculative execution in hardware. In these cases, hardware remains the limiting factor. With software, however, it is increasingly possible to transition an entire codebase in a short time to a language that improves memory safety. Legacy code is disappearing quickly, and this trend is likely to continue over the next few years. Do not simply accept these outcomes. Actively participate in shaping the process changes that follow this rapid evolution in software development. CVEs, CVSS, and threat feeds were designed for a slower, more static world. It is time to step back and consider the implications not only for vulnerabilities and exploits, but also for the processes we use to manage them and the impact on our environments. *Kathleen Moriarty is the Founder of SecurityBiaS, a Technology Strategist, CTO, Board Member, Keynote Speaker, Author, CISO, and former IETF Security Area Director. She has more than two decades of experience working on ecosystems, standards, and strategy.* *Adapted from the original on SecurityBias blog.* The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a [Code of Conduct](/?p=395) applies to this blog.