Linux kernel developers operate under constraints that very few other open source community maintainers experience. Evolving the capabilities of the world’s most popular operating system is just one side of the coin. The other is that you can “never break userspace,” and you must maintain backward compatibility and stability for the millions of devices and users running on Linux.The Linux kernel community’s decision a year ago to become a CVE numbering authority (CNA) was largely viewed as a win. It felt overdue for the largest platform running the world’s infrastructure to align with the security industry’s de facto security disclosure mechanism. Transparency has long been one of the Linux kernel community’s strongest characteristics. It sounded like a big win.The noisiest new contributor to the CVE firehoseThe Linux kernel is not just another dependency. It’s the dependency. Every container, every namespace, every policy engine ultimately runs through it. Historically, kernel vulnerabilities were rare, carefully disclosed, and treated with gravity. When a kernel bug mattered, you knew it.When it became a CNA, the kernel community made a deliberate decision to assign CVEs broadly, often for bugs that would previously have lived only in mailing lists. It was a form of compliance with a CVE model that demands identifiers for everything. The result is that kernel issues now appear in the same feeds, dashboards, and scanners as user-space libraries and application bugs.Now the kernel is the noisiest contributor to an already-overwhelming stream of vulnerabilities.Cisco’s Jerry Gamblin recently published a review of 2025 CVE data. In 2025, there were 48,185 CVEs reported. For the first time, the Linux kernel topped the list as the most vulnerable technology by sheer count. Some of these kernel vulnerabilities are logic errors that can affect a specific path in a program. Others may be dependent on configuration. Additionally, some may only be theoretical in their implications. A smaller percentage of these issues would potentially allow an attacker to exploit a vulnerability in a production environment. However, regardless of the type of issue or whether it could be exploited in a production environment, the CVE model views each issue as an identical artifact.Security pros are being conditioned to triage and ignoreSecurity teams do not have infinite time or cognitive bandwidth. When vulnerability disclosures get this high volume, triage becomes the default. Alerts are acknowledged, and risk is normalized.This situation conditions the industry to ignore those vulnerabilities. When everything looks urgent, the alert that actually threatens the system’s root of trust gets missed. Kernel CVEs are especially susceptible to this fate — not because they matter less, but because they sit beneath every other control teams rely on to contain failures. Many require specific configurations or access patterns. Some are theoretical. Others are exploitable. Who has the time and cognitive bandwidth to understand the difference?“When everything looks urgent, the alert that actually threatens the system’s root of trust gets missed.”Flooding the system with disclosures does not automatically produce better security outcomes. It’s more likely to produce complacency.That boundary problem we keep talking aroundThe kernel is not just another component to be patched. It is the enforcement layer for almost every security control in cloud native environments. Namespaces, cgroups, seccomp, LSMs, and eBPF-based tooling all assume a trustworthy kernel. When that assumption fails, everything above it has been compromised as well. If a vulnerability at that layer is missed, no higher-level control remains to compensate.But the Linux execution model creates the appearance of separation without providing the hard boundaries most people assume are provided by containers. Containers feel isolated because they hide resources, but do not enforce separation. A container is still just a process. The boundary is implemented through shared kernel state. When that state is compromised, isolation collapses completely.Yet the security conversation rarely centers on this. It focuses on vulnerability counts, severities, and compliance rather than on whether kernel-level failures can actually be contained.Ignoring kernel security vulnerabilities is not winningThe Linux kernel community deserves enormous credit. Few projects of its size and age have maintained the level of stability and security that Linux has over the decades. Becoming a CNA was a good-faith security effort.“When the kernel generates dozens of CVEs a week, most teams have no realistic way to understand which ones threaten their isolation model and which ones do not.”But a year in, it is fair to ask what value the industry is actually extracting from this flood of information. When the kernel generates dozens of CVEs a week, most teams have no realistic way to understand which ones threaten their isolation model and which ones do not. CVEs are effective at cataloging known defects, but they are the wrong interface for reasoning about unknown failure modes in the system’s root of trust.The danger is that the most important vulnerabilities are being quietly ignored because the system has taught us to stop listening.Attending Cloud Native Rejekts EU in Amsterdam next week? Catch my talk: “Kernel Observability: The Missing Layer in Cloud Native Engineering,” which will cover this emerging problem. It will also be live-streamed for virtual viewing.The post Linux kernel scale is swamping an already-flawed CVE system appeared first on The New Stack.