CISA's New Disclosure Guidance and the End of the Zero-CVE Report: What to Actually Tell Your Board

CISA's New Disclosure Guidance and the End of the Zero-CVE Report: What to Actually Tell Your Board 

The government just told every vendor what a defensible vulnerability process looks like. A raw CVE count was never going to be it.

TL;DR

• CISA, the NSA, and international partners published joint guidance directing vendors to formalize vulnerability disclosure: clear policies, defined testing scope, ongoing researcher communication, and a repeatable process from report to fix to advisory.

• The guidance sets a new floor: a defensible vulnerability process is now a stated government expectation, not an optional best practice.

• Separately, renewed attention on the "zero-CVE" problem confirms that a package with no known CVEs can still carry undisclosed flaws, malicious code, or a compromised maintainer that a CVE scanner would never catch.

• ActiveState's own remediation SLA, 5 business days for critical CVEs, 10 for high severity, 30 for everything else, is the kind of specific, timed commitment the CISA guidance is describing.

• The EU Cyber Resilience Act adds a 24-hour ENISA reporting deadline for actively exploited vulnerabilities starting September 11, 2026, applying to products already on the market.

CISA, the NSA, and international partners just published joint guidance telling every vendor to formalize how it receives, validates, remediates, and discloses vulnerabilities reported by outside researchers. Clear policies. Defined testing boundaries. Ongoing communication with the people who found the problem. A repeatable process from first report to tested fix to public advisory.

None of that is new to anyone who has run a security program well. What is new is that it is no longer a best practice you can choose to adopt. It is the baseline the federal government is now telling every vendor to meet.

A defensible process is not optional anymore. It is the floor.

A floor like that changes the actual question. The question your board should be asking is no longer "do we have a vulnerability disclosure policy." It is "would our current process survive being described in public, in writing, after an incident." Those are very different questions, and most security teams are only prepared to answer the first one.

A CVE Count Was Never the Right Thing to Report to the Board

The New Stack made a point that deserves more attention than the trade coverage it got: a package with zero known CVEs is not the same thing as a package that is actually secure. CVE scanners miss undisclosed flaws, malicious code, and compromised maintainers, none of which show up as a CVE until someone finds them. A RapidFort and ReversingLabs partnership is now independently scanning curated open source packages for exactly that gap: malware and integrity issues a CVE count would never surface.

This is a familiar failure mode, and not just in security. A metric that is easy to report becomes the metric that gets reported, whether or not it is the metric that matters. A zero-CVE package looks clean on a slide. It tells the board nothing about whether the package was ever independently verified, whether its maintainers are still who they were when it was first approved, or whether anyone is actually accountable for what happens if that changes.

The good news is your dashboard says zero known vulnerabilities. The bad news is that sentence is doing a lot less work than the board thinks it is.

What "Defensible" Actually Requires

Put the CISA guidance and the zero-CVE problem next to each other and the shape of the answer becomes obvious. Defensible does not mean the fewest visible flaws. It means a documented process: who is accountable for evaluating a package before it enters your environment, what the remediation timeline is once a vulnerability is confirmed, and what gets reported, to whom, on what clock, when something is found.

ActiveState's own contractual remediation SLA is 5 business days for critical CVEs, 10 for high severity, and 30 for everything else, against an industry average that lags well beyond that on critical issues. That SLA is not a marketing number. It is the kind of specific, timestamped commitment the CISA guidance is describing when it asks vendors to build a process that moves from report to tested fix to advisory in a predictable, repeatable way.

The EU Cyber Resilience Act adds a second, harder deadline underneath all of this. Starting September 11, 2026, actively exploited vulnerabilities must be reported to ENISA within 24 hours, and that applies to products already on the market. A board that has been told its exposure is low because a scanner reports zero CVEs has not been told anything that survives that 24-hour clock.

The Question for Your Next Board Meeting

Not "how many vulnerabilities did we find." Ask instead who is accountable for the decision to let a package into the environment in the first place, what the remediation clock looks like once something is found, and whether that process would hold up described in writing, in public, after the fact.

A clean scan is not a defensible posture. A documented, timed, owned process is. The government just said so in writing. Your board report should catch up.

Frequently Asked Questions

What does CISA's new vulnerability disclosure guidance require?

The guidance, issued with the NSA and international partners, urges vendors to publish clear disclosure policies, define permitted testing, maintain communication with researchers, and build a repeatable internal process from initial report through a tested fix and public advisory.

Is a zero-CVE package actually secure?

Not necessarily. A CVE count only reflects known, disclosed vulnerabilities. It says nothing about undisclosed flaws, malicious code, or a compromised maintainer, which is why independent scanning efforts, such as the RapidFort and ReversingLabs partnership, are emerging to check for exactly that gap.

What should a board be asking about vulnerability management instead of a CVE count?

Who is accountable for the decision to let a package into the environment, what the remediation timeline is once a vulnerability is confirmed, and whether the process would hold up described in writing, in public, after an incident.

How does the EU Cyber Resilience Act affect vulnerability reporting timelines?

Starting September 11, 2026, the Cyber Resilience Act requires reporting of actively exploited vulnerabilities to ENISA within 24 hours, and that requirement applies to products already on the market, not only new releases.

What is a defensible remediation timeline?

ActiveState's own contractual standard is 5 business days for critical CVEs, 10 business days for high severity, and 30 days for all others, against an industry average that lags well beyond that on critical issues.