Coordinated vulnerability disclosure (CVD) begins when at least one individual becomes aware of a vulnerability. It can’t proceed, however, without the cooperation of many. Software supply chains, software libraries, and component vulnerabilities have evolved in complexity and have become as much a part of the CVD process as vulnerabilities in vendors’ proprietary code. Many CVD cases now require coordination across multiple vendors. This post, which is based on a recently published special report, introduces Vultron, a protocol for multi-party coordinated vulnerability disclosure (MPCVD).

Foundations in Coordinated Vulnerability Disclosure

Since releasing our first advisory in 1988, CERT/CC has sought to improve the professionalization of the world’s CVD practices. Drawing on work across the decades, our approach has been to distill and formalize what we know about this process. This work grew out of numerous ad hoc individual efforts to educate software vendors and the security research community as they engaged our services in coordinating, analyzing, and publishing vulnerability reports, including the following:

• The CERT Guide to Coordinated Vulnerability Disclosure
• A State-Based Model for Multi-Party Coordinated Vulnerability Disclosure (MPCVD)
• publication of Prioritizing Vulnerability Response with a Stakeholder-Specific Vulnerability Categorization (SSVC), versions 1 and 2
• Vulnerability Information and Coordination Environment (VINCE) software, which first saw use in 2020 underlying our CVD practice, and was released as open-source software earlier this year
• Coordinated Vulnerability Disclosure User Stories, which grew out of the VINCE development process, that we think could be generally applicable to current or future systems that provide CVD services

In addition to our own efforts, we have also participated in (and at times led) the development of related ISO/IEC standards around vulnerability disclosure, including

• ISO/IEC 29147:2018 Information technology—Security techniques—Vulnerability disclosure
• ISO/IEC 30111:2019 Information technology—Security techniques—Vulnerability handling processes

The Vultron Protocol

In September 2022, we introduced Vultron, a proposed protocol for MPCVD. The full report, Designing Vultron: A Protocol for Multi-Party Coordinated Vulnerability Disclosure (MPCVD), describes a high-level protocol that we believe provides a foundation for process interoperability among CVD stakeholders and points the way toward technical implementation in tools like VINCE and other CVD service platforms.

While I have led efforts to develop the Vultron protocol, it represents only a piece of a broader effort to improve CVD practices. The report would not have been possible without ongoing dialogue with my CERT Division colleagues including Eric Hatleback, Art Manion, Brad Runyon, Vijay Sarvepalli, Sam Perl, Jonathan Spring, Laurie Tyzenhaus, and Chuck Yarbrough.

The Vultron protocol begins with semantic interoperability because CVD participants need to first agree on what they mean when they talk about their processes. No amount of syntactic interoperability (e.g., data exchange format specifications or APIs) can help if the interpretation of that data differs for the sender and the receiver. The Vultron protocol is designed to handle both CVD and MPCVD cases. In fact, the protocol does not discriminate between them; it simply treats “normal” CVD as a special case of MPCVD in which the number of vendors is 1.

Specifically, the Vultron protocol is built around three distinct but interacting processes, which we describe in the report as deterministic finite automata (DFAs):

1. Report management—A process rooted in IT service management (ITSM) that describes a high-level workflow by which individual CVD case participants can handle and track reports from initial receipt through validation, prioritization, and work completion.
2. Embargo management—A process based on calendaring and schedule coordination that contains a workflow for proposing, accepting, revising, and exiting a period of private coordination prior to public disclosure of vulnerability information. Embargoes in CVD are intended to provide an opportunity to allow the vendors of affected products adequate time to prepare a fix or mitigation advice prior to public awareness of the vulnerability in question.
3. Case state—A process that describes the lifecycle of a CVD case through its major milestones: vendor awareness, fix ready, fix deployed, public awareness, exploit public, and attacks observed. We described this model previously in “Are We Skillful or Just Lucky? Interpreting the Possible Histories of Vulnerability Disclosures” and expanded the idea in our 2021 special report.

The Vultron protocol encompasses both local and global aspects of the CVD process. For example, whereas the report management process is local to a specific case participant, the embargo management process is expected to be shared across all case participants. Similarly, portions of the case state model are global to the case, while others are specific to individual participants. Our intent, however, is to leave plenty of room for stakeholders to implement their own internal processes to suit their individual needs. Our goal with the Vultron protocol is to provide a set of relevant abstractions to map diverse organizations’ internal processes onto a generalized workflow that promotes coordination of effort and improves the communication of case status across stakeholders.

Our report on Vultron includes detailed commentary on how the Vultron protocol might be implemented and outlines future work. Appendices are provided that map the Vultron protocol onto existing work including SSVC v2, ISO/IEC 30111:2019, ISO/IEC 29147:2018, and ISO/IEC TR 5895:2022 (Cybersecurity—Multi-party coordinated vulnerability disclosure and handling).

And yes, fans of a certain colorful anime giant mecha composed of five discrete robots with human pilots might observe more than a passing metaphor in the idea that it takes a cooperative and coordinated effort for a complex human/machine partnership to achieve some defensive goals.

Where Do We Go Next?

Although we have done some internal proof-of-concept development to explore aspects of the Vultron protocol, it has not been fully implemented yet. Nor have we completed our analysis of its properties. Due to the size and scope of what we think it might become, however, we wanted to share it now as a proposal so we can begin developing a community of interest among relevant stakeholders, including, but not limited to

• software vendors and PSIRTs
• security researchers
• CSIRTs and other third-party coordinators
• vulnerability disclosure and bug bounty platform providers

While you can expect to hear more from us about the Vultron protocol in the future, we are interested in your feedback on the protocol we have proposed in the report. Some questions to consider in your feedback include the following:

• With the proviso that all models are wrong but some are useful, how can we make the Vultron protocol more useful to your CVD practice?
• What did we miss?
• What could be clearer?
• Do you have important edge cases you think we should consider?
• What assumptions did we make that you disagree with or find questionable or odd in the context of your own environment and experience?

Also, because Vultron touches on both the human process and technical work of CVD, we expect that future work will be needed to integrate Vultron into higher-level vendor processes, such as those described in the FIRST PSIRT Services Framework.

Finally, we recognize that the Vultron protocol effort will eventually need to address syntactic interoperability, such as message and data exchange formats. We anticipate that this activity will take some form of engagement with relevant efforts, such as the Common Security Advisory Framework (CSAF), Open Source Vulnerability Format, and various CVE working groups such as the Automation Working Group (AWG).

It is not our intent to supplant existing format work. In fact, our preference is for Vultron to eventually accommodate a variety of vulnerability data exchange formats. While we appreciate that incident and malware data exchange formats exist and are related to vulnerability data exchange, we are primarily interested in vulnerability-specific formats for now. If you are aware of active vulnerability data exchange format efforts that we haven’t mentioned here, please let us know.