When a researcher reports a critical flaw in a popular Node.js package, the maintainer might publish a GitHub Security Advisory and ship a patch within 48 hours. Report the same class of bug against the Linux kernel, and the fix can sit in a public git commit for months before anyone formally requests a CVE number. Google Project Zero enforces a strict 90-day disclosure deadline, extendable by 30 days if a patch is imminent. Zero Day Initiative gives vendors 120 days. CERT/CC works on a 45-day clock. The European Union's Cyber Resilience Act now wants reports of actively exploited flaws sent to regulators within 24 hours of discovery. None of these clocks run on the same track, and the gap between "discovered" and "publicly known and patchable" can span anywhere from a few days to well over a year depending almost entirely on which ecosystem the vulnerable code lives in. For teams triaging risk across a mixed npm, PyPI, container, and Linux stack, that inconsistency isn't academic — it directly determines how much exposure window attackers get before a fix even exists to apply.
How Long Does Google Project Zero Actually Give Vendors?
Ninety days, plus a conditional 30-day grace period — a policy Project Zero has iterated on since it first published a fixed deadline in 2015. Before that, disclosure timing was negotiated case by case, which produced wildly inconsistent outcomes for equally severe bugs. The 2021 update added the grace extension only when a vendor commits to shipping a fix and communicates a real date, plus a standing rule that deadlines falling on a weekend or major holiday shift by up to 14 days. The result is a program that behaves almost like a regulator: predictable, vendor-agnostic, and enforced regardless of who the vendor is. Compare that to most open source ecosystems, where "the vendor" is a single unpaid maintainer with no legal obligation to respond to anything, and the 90-day model starts to look less like an industry norm and more like a best-resourced exception.
Why Does the Linux Kernel Play by Completely Different Rules?
Because until February 2024, the kernel had no formal CVE-assignment process at all, and the security team's own stated position is that a vulnerability is considered "fixed" the moment a patch lands in a public tree — not when a CVE is minted. That meant fixes routinely sat visible in git history and mailing list threads for weeks or months, fully patchable by anyone paying attention, long before a CVE record existed to alert less-attentive downstream users. When the Linux Foundation's kernel team finally became its own CVE Numbering Authority in early 2024, it started backfilling thousands of historical fixes with retroactive CVE IDs, some referencing commits years old. That single policy shift caused Linux's share of the annual CVE count to jump dramatically overnight, not because the kernel suddenly got less secure, but because the bookkeeping finally caught up to development practice that had never treated CVE assignment as part of the disclosure timeline in the first place.
What Happens When a Project Has No Disclosure Policy at All?
The timeline defaults to whatever the individual maintainer or reporter decides, and for most of the npm and PyPI ecosystem, that's exactly the situation. The Apache Software Foundation runs a dedicated security team but publishes no fixed public deadline, and its own advisories show turnaround ranging from days to many months depending on component and severity. Smaller registries lean on platform backstops instead of house policy: GitHub's Security Lab defaults to a 90-day coordinated disclosure window and will publish an advisory unilaterally if a maintainer goes dark, and RustSec follows a similar unresponsive-maintainer clause. But those backstops only trigger if a researcher routes the report through GitHub or a curated advisory database in the first place — plenty of reports still go straight to an email address that nobody checks, and there the clock simply doesn't exist until someone forces the issue publicly.
Why Did Log4Shell and the xz Backdoor Take Such Different Paths?
Log4Shell followed something close to coordinated disclosure under real-world pressure, while the xz backdoor skipped the coordination phase entirely because there was no good-faith vendor to coordinate with. Alibaba's Chen Zhaojun reported the Log4j flaw to the Apache Software Foundation on November 24, 2021; Apache shipped a fix on December 6, and public disclosure followed within days after proof-of-concept exploitation began circulating — roughly a two-week private window that still felt chaotic because so much of the internet depended on the affected library. The xz Utils backdoor was different in kind: Andres Freund discovered the malicious code in late March 2024 and disclosed it publicly within days, on March 29, because the compromise came from within the project's own commit history rather than from an external bug. There was no vendor grace period to honor, no embargo to protect — every downstream Linux distribution patched within 24 to 48 hours because the correct response was immediate, universal disclosure rather than a negotiated timeline.
Could the EU's 24-Hour Reporting Mandate Actually Backfire?
It could, according to a large share of the security research community, because 24 hours leaves essentially no room for a patch to exist before regulators — and potentially attackers — learn a flaw is being actively exploited. The Cyber Resilience Act requires manufacturers to notify ENISA and national CSIRTs of actively exploited vulnerabilities within 24 hours of becoming aware, with a fuller report due at 72 hours and a final report at 14 days after remediation. That stands in direct tension with the vendor-time-first philosophy behind Project Zero's 90 days or ZDI's 120, both of which exist specifically to give engineering teams a working window before anything becomes public. Critics argue that centralizing early-stage vulnerability data with government bodies creates a new leak surface and could pressure vendors into rushed, incomplete fixes just to hit a reporting clock that has nothing to do with how long a real patch takes to build and test.
Why Is the NVD Backlog Making Cross-Ecosystem Comparison Even Harder?
Because the National Vulnerability Database's own analysis delays now add an entirely separate lag on top of whatever disclosure timeline a given ecosystem uses. Starting in February 2024, NVD's enrichment backlog grew sharply, leaving a large share of newly published CVEs without CVSS scores or CPE mappings for weeks or months at a stretch. Tools and processes built around NVD data inherit that lag regardless of how fast the underlying ecosystem actually moved — an npm package disclosed and patched via GitHub Security Advisory the same day can still show up as "unscored" in NVD-dependent tooling long after the fix shipped. That mismatch means comparing "disclosure timelines" across ecosystems purely by CVE publication or scoring dates is misleading: some ecosystems self-publish severity data instantly, while others are effectively at the mercy of a federal enrichment queue that has nothing to do with the vulnerability itself.
How Safeguard Helps
Safeguard doesn't wait for any single ecosystem's disclosure clock — or NVD's enrichment queue — to tell a team whether it's exposed. By continuously mapping SBOM and dependency data across npm, PyPI, container images, and OS packages against multiple advisory sources simultaneously, including GitHub Security Advisories, OSV, and vendor-specific feeds, Safeguard surfaces real exploitability signals the moment they exist rather than the moment a formal CVE record catches up. That means a same-day GHSA disclosure and a months-delayed Linux kernel backfill both get triaged on actual patch availability and reachability in your codebase, not on which ecosystem happened to move faster on paperwork. For security and platform teams managing a genuinely mixed stack, that consistency is the difference between chasing whichever advisory database updated last and having one accurate, ecosystem-agnostic view of what's actually urgent right now.