✕
Skip to content

The Vultron Coordinated Vulnerability Disclosure Protocol

Vultron is an open protocol for Coordinated Vulnerability Disclosure (CVD): it lets the systems organizations already use coordinate a vulnerability case with each other. It is a protocol in the way the Simple Mail Transfer Protocol (SMTP) is, not a product in the way a mail service is. It builds on decades of vulnerability coordination experience at the CERT Coordination Center (CERT/CC).

Site build

This site was built from an unreleased development build (2026.10.1.dev18+g3d629413b), not from a release.

This is a build version, not a release version. Release versions are numbered by the release versioning scheme.

Work in progress

Vultron is a collection of ideas, models, code, and work in progress, and is not yet ready for production use.

What kind of thing Vultron is

Each protocol below competes with centralized products that do the same job inside one company's walls. The products work well until you need to reach someone who uses a different one.

Protocol What it lets you do The centralized alternative
SMTP (email) Send mail to anyone, whatever mail service they use Direct messages inside one platform, such as Slack or Microsoft Teams
Extensible Messaging and Presence Protocol (XMPP) Chat with people on servers run by other organizations Single-vendor chat services, such as WhatsApp or Facebook Messenger
Really Simple Syndication (RSS) and Atom Follow any site's updates in the reader you choose A social media timeline that shows only what its platform hosts
Vultron Coordinate a vulnerability case with partners, whatever tracker each of them runs An account on every partner's coordination portal or disclosure platform

Email works because a message sent from one provider arrives at any other. Vultron aims to give vulnerability coordination the same property.

The problem it solves

Today, coordinating a case across organizations means holding an account on every partner's coordination system. A vendor that works with three coordinators and a disclosure platform checks four portals, each with its own login, workflow, and idea of the case's state. Vendors that coordinate directly with each other have no shared system at all. They fall back to encrypted email and tickets updated by hand, and a person copies every status change from one to the other.

Vultron replaces those per-partner accounts with one protocol. Your tracker speaks it, your partners' trackers speak it, and the case moves between them as structured messages. See What Is Vultron? for the full answer.

What Vultron is not

Each statement of what Vultron is not comes with where your own system plugs in instead.

Vultron is not… Where your system plugs in
A tracking system, such as Bugzilla or Jira Your tracker stays. It sends a Vultron message at each milestone its workflow already records: report received, validated, accepted, closed. See Process Implementation Notes.
A CVD or threat coordination tool, such as the Vulnerability Information and Coordination Environment (VINCE) or the Malware Information Sharing Platform (MISP) Your coordination tool becomes a participant in the case, and can host cases for others by providing the Case Hosting capability set. See Capability Sets.
A vulnerability disclosure program, such as the Department of Defense Cyber Crime Center (DC3) Vulnerability Disclosure Program (VDP) Your program's policy stays yours. Its intake accepts reports as Vultron messages from any reporter's system. See Run the Receive-Report Demo.
A disclosure platform or service, such as HackerOne, Bugcrowd, or Synack Your platform joins cases as a participant, so its customers can coordinate with parties who are not on it. See Capability Sets.
A prioritization tool, such as Stakeholder-Specific Vulnerability Categorization (SSVC) or the Common Vulnerability Scoring System (CVSS) Your prioritization scheme answers the prioritization call-out point, where the protocol asks whether to engage a case. See Report Prioritization.
A product Vultron is a feature set that products implement. Every decision it leaves open is a call-out point your own system answers. See the Capability Model.

Where to start

Pick the description that matches your situation.

  • You handle vulnerability reports and coordinate cases with other organizations

    How a case moves under Vultron, what it asks of each participant, and how it maps onto what you already do. If you lead a Product Security Incident Response Team (PSIRT) or a Computer Security Incident Response Team (CSIRT), this path also covers whether to adopt Vultron.

    Start here

  • You maintain a vulnerability tracker and want it to talk to your partners

    What your system sends and when, and where your own logic plugs in.

    Start here

  • You study how vulnerability disclosure works and want the models behind it

    The process models, the measurements built on them, and the formal protocol definition.

    Start here

  • You want to work on the Vultron reference implementation

    Run the demos, then learn how the codebase is built and why.

    Start here

Have a vulnerability to report?

Vultron is a protocol, not a place to send a report. Report it to the vendor through its security contact, which is often published in a security.txt file on its website. If you cannot reach the vendor, or it does not respond, the CERT Coordination Center (CERT/CC) can coordinate the case: report it to CERT/CC. The CERT Guide to Coordinated Vulnerability Disclosure explains what to expect along the way.

Who this documentation is for

The site is written for four kinds of reader, and every page declares which of them it addresses.

Stakeholder type Who it is What they want
cvd-practitioner Works CVD cases or the programs around them — including security researchers who report vulnerabilities, vendor PSIRTs, and national CSIRTs, ISACs, and ISAOs To decide whether to adopt, and how the process changes if they do
platform-developer Builds or maintains a tracker, platform, or tool that must coordinate with others What to send and when, and where their own system plugs in
process-researcher CVD process engineering, process-improvement research, cross-case ecosystem health The models, the measurements, and where the process theory leads
project-contributor Works on this reference implementation How this codebase is built, and why it was built that way
ALL Genuinely every type above Declared explicitly; never inferred from an absent key

How this documentation is organized

The documentation follows the Diátaxis Framework, which sorts pages into four kinds by what the reader is trying to do. Each page shows its kind as a badge above its title. Pages that only give directions, like this one, carry no badge.

  • Tutorials

    Step-by-step guided lessons for getting started with Vultron. Run the demos and see the protocol in action.

    Tutorials

  • Explanation

    Background, concepts, process models, and behavior logic. Builds understanding of how and why Vultron works.

    Explanation

  • How-to Guides

    Goal-oriented guidance for implementers. ActivityPub integration, wiring capabilities, and protocol implementation advice.

    How-to Guides

  • Reference

    The protocol specification, message types, the formal protocol, and International Organization for Standardization (ISO) crosswalks.

    Reference

Research material sits outside those four, in its own Research section: measuring CVD across many cases, and other uses of the case state model. The project's decision records, requirements, and generated code references are reached from Working on This Implementation.

Background

The Vultron Protocol is a continuation of the CERT/CC's work on improving the coordination of vulnerability disclosure and response. Our previous work in this area includes:

along with a variety of related research, including

More recently, the CERT/CC has been working towards formalizing this knowledge into a protocol for CVD. Our recent work in this area includes: