Recent guidance issued by CISA and the NSA (along with cybersecurity agencies from Japan and the Netherlands) establishes best practices for development of coordinated vulnerability disclosure (CVD) programs. Aimed at software manufacturers and online service providers working with external security researchers, the guidance focuses on processes for triaging, remediating and assigning Common Vulnerabilities and Exposures (CVE) identifiers to reported vulnerabilities.
The advice is concentrated in a “Cybersecurity Information Sheet” that provides advice on setting the scope of security testing, publicly addressing vulnerabilities and creating a vulnerability disclosure policy. It also advises on options for leveraging available government teams and third-party intermediaries for supplementing or substituting supplier programs. The guidance comes as both public and private organizations are grappling with the prospect of near-term “machine speed” discovery of vulnerabilities by attackers wielding AI tools, and looking at potential major overhauls to their remediation and reporting processes.
Government advice on vulnerability disclosure comes at outset of the “machine speed era”
The guidance opens with advice on developing a CVD program, and addresses creation of a clear vulnerability disclosure policy (VDP) as a first step. This is an area that many organizations continue to struggle with even as the AI discovery era looms, failing to have even a clear means of reporting vulnerabilities available to independent researchers that are seeking to assist them. Some key recommendations in this area are avoidance of blanket disclosure restrictions (such as NDAs) and ensuring that vulnerability disclosures are easily discoverable on the organization’s public website and encourage public participation. Organizations are also encouraged to sign the CISA “Secure by Design Pledge.”
While public participation is encouraged, the guidelines also advise setting clear terms for how independent researchers can and cannot operate on the organization’s network. This includes establishing minimum reporting requirements: desired proof of concept, assessment of impact, and how write-ups of the issue should be structured among other items. The path to reporting should also be clearly defined, particularly when the organization asks a researcher to first go to a third-party mediator (such as CISA itself).
The vulnerability disclosure guidelines also recommend establishment of a “safe harbor” policy to assure researchers acting in good faith that they will not be subject to hacking laws. Disclosure of embargo periods is also a suggested element, as well as noting to what extent researchers can expect to be acknowledged or credited in vulnerability advisories so that misunderstandings do not arise later.
The guidance also offers some advice on determining whether or not a vulnerability requires a CVE ID, something generally governed by the Operational Rules of the CVE program. ID numbers are assigned by CVE Numbering Authorities (CNAs), and the guidance suggests organizations should look into becoming one if they expect any kind of regular reporting.
The guidance closes with some recommendations for publishing a vulnerability disclosure: using the standardized Common Security Advisory Framework (CSAF) so that disclosures are guaranteed to be machine readable, providing this information in an area of the website that is not restricted with a login or paywall, and considering public statements that will be published alongside the disclosure (such as blog and social media posts or direct notifications to customers).
Vulnerability disclosure guidance suggests regular review of CVD programs, use of available security intermediaries
Regular review of CVP programs is also encouraged by the guidance, to include establishing tabletop exercises and establishing a two-way feedback channel with researchers. Another suggestion that many organizations lack is a bug bounty program. While this may feel overwhelming, the guidance notes that this element can be handed off to external service providers.
On that subject the guidance also notes that much of vulnerability disclosure can be bolstered by, or even outright outsourced to, third party providers. These incident response teams can serve as the first point of contact for researchers looking to report a vulnerability, assign CVEs independently as a Numbering Authority, provide their own professional assessments of reported vulnerabilities, and assist with proper handling of disclosure and remediation among other elements.
The guidance is obviously quite timely given the expected explosion in vulnerability detection (and thus likely need for vulnerability disclosure) caused by AI tools working at machine speed. While these same AI tools will also certainly help with detection and may well also help with remediation, vulnerability disclosure remains an area where their abilities to cut down on work volume remain limited. Where they can assist is in determining how much of an immediate risk a vulnerability is, and prioritizing for review accordingly. Andrew Costis, Engineering Manager of the Adversary Research Team at AttackIQ, notes that this is much more of an individualized process than simply taking on the issues with the highest CVE scores first:
“Managing that process effectively calls for a continuous approach to threat exposure management. Vulnerabilities can’t be treated as isolated findings or prioritized on severity alone. Teams need to understand how a weakness connects to the rest of their environment and whether it creates a viable path to critical systems. Once that exposure is addressed, defenses should be tested again. Closing a ticket is one thing. Proving the attack path is broken and the fix holds against real-world adversary behavior is another.”
