The Visibility Gap Above the Hardware

Cloud AI’s vulnerability problem is not only that software can contain flaws. It is that the information needed to understand, compare, and fix those flaws is divided among providers, customers, researchers, and public institutions. This chapter focuses on the path from a technical weakness to a public identifier, evidence of exploitation, provider disclosure, and customer action. Distinguishing those stages helps readers judge what a vulnerability record actually tells them—and what it leaves unknown.

The distinction matters because AI infrastructure relies on managed layers that customers may use without operating. A customer can depend on a runtime, storage service, logging system, or gateway while having no direct ability to inspect its implementation or patch it. If a weakness is not disclosed, or if it is recorded only inside one provider’s process, the customer may face a security problem before there is a shared vocabulary for describing it.

A record is not a risk judgment

The Common Vulnerabilities and Exposures system, usually called CVE, gives publicly discussed vulnerabilities identifiers that allow different tools and organizations to refer to the same issue. The National Vulnerability Database, or NVD, enriches vulnerability records and has supported compliance frameworks, automated scanning tools, and risk assessments. These functions are important because a scanner, policy team, and operator need more than a private bug report to coordinate action.

But a public identifier does not answer every operational question. It may identify a flaw without showing whether a particular customer’s configuration is exposed, whether the vulnerable component is present in a managed service, how easy exploitation is, or what mitigation is available. A record can be a common reference point while still requiring local analysis. The difference is similar to the difference between naming a disease and diagnosing its effect in one patient, except that the infrastructure context determines whether the analogy holds: the identifier is shared, while exposure and consequence depend on the system using the component.

A second signal serves a different purpose. CISA’s Known Exploited Vulnerabilities catalog, or KEV, records vulnerabilities that the agency has identified as exploited in the wild. The Atlantic Council brief reports that, as of March 2026, the catalog contained 1,551 vulnerabilities, compared with 339,010 vulnerabilities in the NVD. Those figures should not be read as a competition in which the smaller catalog is incomplete and the larger one is authoritative for every decision. They represent different functions. The NVD is a broad public inventory and enrichment resource; KEV is a narrower signal that exploitation evidence should influence prioritization.

The distinction changes how an operator should read the absence of a record. A vulnerability not present in KEV has not, on the evidence described here, received that catalog’s exploited-in-the-wild signal. That does not prove that it is harmless or unexploited. A vulnerability absent from NVD or without a CVE identifier may be harder to find through tools that depend on those records, but the absence can reflect disclosure and cataloging decisions rather than the absence of a technical weakness. Public data is evidence about visibility, not a complete census of reality.

The brief also describes strain in the public vulnerability infrastructure.