Dear Linux Kernel CNA, what have you done?

Original Article ↗ Hacker News Discussion ↗

Role and Meaning of CVEs

  • Several comments stress that CVEs were intended mainly as unique identifiers so people talk about the same issue, not as a complete or authoritative list of “real” security bugs.
  • Others counter that, in practice, regulators, enterprises, and tooling have come to treat “has a CVE” as synonymous with “known security vulnerability,” whether or not that was the original design.
  • This mismatch between intended use and real-world use is seen as the core tension.

Linux Kernel’s “Every Bug is a Security Bug” Approach

  • The kernel community’s long‑held stance: it’s often impossible to reliably separate “security” from “non‑security” bugs, so assume all bugs may be security‑relevant.
  • Becoming a CNA and issuing CVEs for essentially all bugfixes is viewed by some as a logical extension of that stance; by others as a deliberate “burn down the system” move to expose CVE process flaws.

Regulation, Compliance, and Downstream Burden

  • Many worry about a flood of kernel CVEs driving compliance pain: more triage, more mandatory patching cycles, and potential safety/stability risks in regulated or long‑lived systems.
  • Some argue standards (PCI‑DSS, ISO, SOC2, CRA) mostly require processes to discover and handle exploitable vulnerabilities, not blind patching of all CVEs. One commenter claims CRA explicitly excludes upstream OSS and focuses on exploitability.
  • A recurring view: large companies benefiting from Linux should fund their own triage instead of expecting unpaid kernel developers to classify bugs for them.

Security Outcomes and Attacker Perspective

  • Supporters believe more CVEs improve transparency and push laggards toward rolling updates, which is the only realistic way to keep kernels secure.
  • Critics claim vague, unscored, post‑hoc CVEs—plus no CVEs for unfixed bugs—may extend exploit shelf life and complicate defense, especially for legacy systems that can’t fully upgrade.

Quality, Scoring, and Tooling Issues

  • Many see CVSS scoring as subjective, gameable, and often misleading, yet acknowledge that tooling and regulation are built around CVE+CVSS.
  • Concern that Linux’s many minimally described, unscored CVEs will break or devalue existing automation and “checklist security” processes.

Proposed Responses and Mitigations

  • Suggestions include:
    • Treat CVEs only as triage inputs, not hard requirements.
    • Pay vendors to deliver curated “clean feeds” and tested updates.
    • Reduce exposure by disabling unused kernel components and automating minor-version merges.
  • Some argue that organizations doing naive CVE-by-CVE compliance have “only themselves to blame” and must evolve their processes.