NIST Special Publication
NIST SP 800-216

Recommendations for Federal
Vulnerability Disclosure
Guidelines
Kim SchafferPeter Mell
Hung Trinh
Isabel Van Wyk
This publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-216

NIST Special Publication
NIST SP 800-216

Recommendations for Federal
Vulnerability Disclosure
Guidelines
Kim SchafferPeter Mell
Hung Trinh
Isabel Van Wyk

Computer Security Division
Information Technology Laboratory

This publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-216
May 2023

U.S. Department of Commerce
Gina M. Raimondo, Secretary
National Institute of Standards and Technology
Laurie E. Locascio, NIST Director and Under Secretary of Commerce for Standards and Technology

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Certain commercial equipment, instruments, software, or materials, commercial or non-commercial, are identified inthis paper in order to specify the experimental procedure adequately. Such identification does not imply
recommendation or endorsement of any product or service by NIST, nor does it imply that the materials or
equipment identified are necessarily the best available for the purpose.
There may be references in this publication to other publications currently under development by NIST in
accordance with its assigned statutory responsibilities. The information in this publication, including concepts andmethodologies, may be used by federal agencies even before the completion of such companion publications. Thus,
until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain
operative. For planning and transition purposes, federal agencies may wish to closely follow the development ofthese new publications by NIST.
Organizations are encouraged to review all draft publications during public comment periods and provide feedback
to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available athttps://csrc.nist.gov/publications.
Authority
This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal
Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283.
NIST is responsible for developing information security standards and guidelines, including minimum requirements
for federal information systems, but such standards and guidelines shall not apply to national security systems
without the express approval of appropriate federal officials exercising policy authority over such systems. This
guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.
Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding
on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines beinterpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or
any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis andis not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.
NIST Technical Series Policies
Copyright, Use, and Licensing Statements
NIST Technical Series Publication Identifier Syntax
Publication History
Approved by the NIST Editorial Review Board on 2023-05-17
How to Cite this NIST Technical Series Publication:
Schaffer K, Mell P, Trinh H, Van Wyk I (2023) Recommendations for Federal Vulnerability Disclosure Guidelines.
(National Institute of Standards and Technology, Gaithersburg, MD), NIST (Special Publication) NIST SP 800-216.
https://doi.org/10.6028/NIST.SP.800-216
Author ORCID iDs
Kim Schaffer: 0000-0003-3073-2395
Peter Mell: 0000-0003-2938-897X
Hung Trinh: 0000-0002-3323-0836
Isabel Van Wyk: 0000-0001-8566-6829

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Contact Information
sp800-216-comments@nist.gov
National Institute of Standards and Technology
Attn: Computer Security Division, Information Technology Laboratory
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930
All comments are subject to release under the Freedom of Information Act (FOIA).

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Abstract
Receiving reports on suspected security vulnerabilities in information systems is one of the best
ways for developers and services to become aware of issues. Formalizing actions to accept,
assess, and manage vulnerability disclosure reports can help reduce known security
vulnerabilities. This document recommends guidance for establishing a federal vulnerability
disclosure framework, properly handling vulnerability reports, and communicating the mitigation
and/or remediation of vulnerabilities. The framework allows for local resolution support whileproviding federal oversight and should be applied to all software, hardware, and digital services
under federal control.
Keywords
advisory; Federal Coordination Body; findings report; source vulnerability report; vulnerability
communication; Vulnerability Disclosure; Vulnerability Disclosure Policy; Vulnerability
Disclosure Program Office; vulnerability processing; vulnerability tracking.
Reports on Computer Systems Technology
The Information Technology Laboratory (ITL) at the National Institute of Standards andTechnology (NIST) promotes the U.S. economy and public welfare by providing technicalleadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test
methods, reference data, proof of concept implementations, and technical analyses to advancethe development and productive use of information technology. ITL’s responsibilities include thedevelopment of management, administrative, technical, and physical standards and guidelines forthe cost-effective security and privacy of other than national security-related information infederal information systems. The Special Publication 800-series reports on ITL’s research,guidelines, and outreach efforts in information system security, and its collaborative activities
with industry, government, and academic organizations.

iNIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Patent Disclosure Notice
NOTICE: ITL has requested that holders of patent claims whose use may be required forcompliance with the guidance or requirements of this publication disclose such patent claims to
ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL
has not undertaken a patent search in order to identify which, if any, patents may apply to thispublication.
As of the date of publication and following call(s) for the identification of patent claims whose
use may be required for compliance with the guidance or requirements of this publication, nosuch patent claims have been identified to ITL.
No representation is made or implied by ITL that licenses are not required to avoid patent
infringement in the use of this publication.

ii

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Table of Contents
Executive Summary ................................................................................................................. 1
U.S. Government Vulnerability Disclosure ..................................................................... 2
Usage of Document Terminology................................................................................ 5Federal Vulnerability Disclosure Coordination Body .................................................... 6
Preparation ................................................................................................................. 7
2.1.1.

Create Source Vulnerability Report Receipt Capability ............................................. 7

2.1.2.

Determine Scope and Obtain Contacts .................................................................... 8

2.1.3.

Develop Technical Analysis Capability ..................................................................... 9
Receive Source Vulnerability Report .......................................................................... 9
Triage and Prioritize Source Vulnerability Report........................................................ 9
Determine the Reported Vulnerable System ..............................................................10
Identify the Reported Vulnerable Software.................................................................10
Verify and Remediate Vulnerability ............................................................................10
Determine Whether to Publish an Advisory................................................................112.7.1.

Determine Whether Public Disclosure is Warranted ................................................112.7.2.

Produce Advisory ....................................................................................................122.7.3.

Government Advisory Services ...............................................................................13
Stakeholders in Federal Vulnerability Disclosure Coordination ..................................14
Technical Approaches and Resources ......................................................................14

Vulnerability Disclosure Program Offices .....................................................................16
Vulnerability Disclosure Program Office Description ..................................................16
Vulnerability Disclosure Program Office Structural Requirements ..............................16
3.2.1.

Development of Source Vulnerability Report Acceptance Policies ...........................173.2.2.

Monitoring of Source Vulnerability Reports ..............................................................173.2.3.

Processing and Resolution of Source Vulnerability Reports ....................................18

3.2.4.

Development of Vulnerability Disclosure Handling Procedures................................18

3.2.5.

Vulnerability Disclosure Program Office Operational Duties ....................................18
Management Considerations .....................................................................................22

3.3.1.

Leadership Support .................................................................................................22

3.3.2.

Staffing Needs .........................................................................................................22

3.3.3.

Leveraging Existing Processes................................................................................22

3.3.4.

Integration of Contractor Support into the VDPO .....................................................22

3.3.5.

Customer Support and Public Relations ..................................................................22

References ..............................................................................................................................24
Appendix A.

List of Symbols, Abbreviations, and Acronyms...........................................26

iii

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Appendix B.

Glossary ..........................................................................................................27

Appendix C.

Examples and Resources for Federal Vulnerability Disclosure Programs
and Policies ....................................................................................................28

List of Figures
Fig. 1. High-level federal vulnerability disclosure framework and information flow ..................... 3
Fig. 2. Federal vulnerability disclosure coordination process ..................................................... 6
Fig. 3. VDPO structural requirements .......................................................................................16
Fig. 4. Process flow specification for VDPO operational duties .................................................19iv

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Acknowledgments
The authors would like to thank Tanya Brewer for her advice and support.

v

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Executive Summary
This document provides a guideline for managing vulnerability disclosure for information
systems within the Federal Government. The document follows the IoT Cybersecurity
Improvement Act of 2020, Public Law 116-207, Section 5 [CYB_IMPR_ACT], which directs
NIST to provide guidelines:(1) for the reporting, coordinating, publishing, and receiving information about –a. a security vulnerability relating to information systems owned or controlled byan agency (including Internet of Things devices owned or controlled by anagency); andb. the resolution of such security vulnerability; and(2) for a contractor providing to an agency an information system (including an Internetof Things device) and any subcontractor thereof at any tier providing suchinformation system to such contractor, on –a. receiving information about a potential security vulnerability relating to theinformation system; andb. disseminating information about the resolution of a security vulnerability
relating to the information system.
The guidelines published under subsection (a) shall –(1) to the maximum extent practicable, be aligned with industry best practices andStandards 29147 and 30111 of the International Standards Organization (or any
successor standard) or any other appropriate, relevant, and widely-used standard;(2) incorporate guidelines on –a. receiving information about a potential security vulnerability relating to an
information system owned or controlled by an agency (including an Internetof Things device); andb. disseminating information about the resolution of a security vulnerability
relating to an information system owned or controlled by an agency (including
an Internet of Things device); and(3) be consistent with the policies and procedures produced under section 2009(m) of theHomeland Security Act of 2002 (6 U.S.C. 659(m)).
This document defines the Federal Coordination Body (FCB) as the primary interface forvulnerability disclosure reporting and oversight. It also defines Vulnerability Disclosure Program
Offices (VDPOs), which should be part of the information technology security offices (ITSOs)
closest to the products and services provided. The FCB and VDPOs work together to address
vulnerability disclosure in the Federal Government.

1

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

U.S. Government Vulnerability Disclosure
Thousands of security vulnerabilities in computer software and systems are discovered andpublicly disclosed every year. Likely, even more are discovered by developers and quietly fixed
without anyone ever being aware. In 2021 alone, there were over 20,000 new vulnerabilities
reported to the NIST National Vulnerability Database [NVD].
Vulnerabilities are discovered by a variety of sources. Developers of software may find security
bugs in already deployed code. Security researchers and penetration testers may findvulnerabilities by scanning or manually testing software and accessible systems (following
published rules of behavior). While identifying an issue, users of systems may stumble across avulnerability. Malicious actors may seek out unknown or unpublished vulnerabilities and use
them in malware. Evidence of these attacks may then be discovered and analyzed by security
experts, resulting in an identified vulnerability being reported. Regardless of who finds thesevulnerabilities, it is critical that they are reported so that the owners of vulnerable software andsystems can resolve or identify ways to mitigate the reported vulnerabilities. In many cases,
owners should issue advisories to notify users of any actions to be taken (e.g., patches to beinstalled) or of potential damage to systems (i.e., potential consequences of the vulnerability
having existed).
International standard [ISOIEC_29147] provides guidance for coordinating the reporting ofvulnerabilities and the creation of advisories to notify the public. It is designed to work incoordination with [ISOIEC_30111], which addresses the process of handling a reported
vulnerability. Relevant topics in both ISO/IEC 29147 and ISO/IEC 30111 are referenced within
this guidance. Hereafter, these two standards are referred to as ‘the ISO/IEC standards’ or simply‘the standards.’
NIST has been directed under the Cybersecurity Improvement Act of 2020 [CYB_IMPR_ACT]
to create guidelines for vulnerability disclosure for federal agencies in alignment with both
ISO/IEC standards. Per the legislation, this document provides guidelines for:
1. Receiving information about a potential security vulnerability in a federal information
system,2. Coordinating with stakeholders, and
3. Resolving and disseminating information about such security vulnerabilities.
In order to define vulnerability disclosure guidelines, this document describes a framework for
the U.S. Government to establish and maintain a unified and flexible collection and management
process for vulnerability disclosures. The framework can be applied at all levels, from a central
oversight body down to the individual program offices. The framework can also be applied to all
government-developed, commercial, and open-source software used by government systems. All
government data and information systems that include development or support services benefit
from vulnerability disclosure program coverage.

2

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Fig. 1. High-level federal vulnerability disclosure framework and information flow

These guidelines focus on assessing risk from identified vulnerabilities and encourage allorganizations throughout the Federal Government to collect and evaluate vulnerability
disclosures for maximum communication and accountability. Creating efficient and effective
vulnerability disclosure programs can help minimize the unintended exposure of government andprivate information, the corruption of data, and the loss of services.
This document leverages the ISO/IEC standards in defining a framework for vulnerability
disclosure designed specifically for the United States Federal Government. Its implementation
specifies actors working at the federal, agency, and information system levels and how theyshould coordinate in performing vulnerability disclosure. This guidance also aligns with andleverages Binding Operational Directive [BOD20-01], which was released in 2020 and requires
federal agencies to publish vulnerability disclosure policies that enable users to reportvulnerabilities in Federal Government systems.
Figure 1 provides a high-level view of the framework that shows the major actors andinformation flows. The two primary government entities are the Federal Coordination Body
(FCB) and the Vulnerability Disclosure Program Offices (VDPOs). Other actors defined in theframework include the reporter, the public, and the external coordinator, all of whom aredescribed more thoroughly in later sections of this document.
The FCB is a group of cooperating members that collectively provide flexible, high-levelvulnerability disclosure coordination among government agencies. The group represents theprimary mechanism by which vulnerabilities should be tracked by the Government and for which
vulnerability advisories should be produced. Although some overlap may occur, FCB members
will have distinct areas of responsibility that reflect typical dividing lines in the Government

3

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines(e.g., between the military and civilian sectors) and represent the current state of existing
vulnerability disclosure coordination capabilities.
A VDPO represents the operational unit that is responsible for information technology (IT)systems and coordinating with other actors to identify, resolve, and issue advisories on reported
vulnerabilities. Ideally, it is part of an existing vulnerability management program closest to theaffected products and/or services. Agencies may also consider sharing resources between
coordinating offices to alleviate the shortages of necessary vulnerability or technology expertise,
while maintaining VDPO services adjacent to the products and services provided. Largeorganizations may choose to utilize a hierarchical structure for each sub-agency or division tocoordinate vulnerability reporting between the FCB and VDPOs. Additionally, an agency may
have many VDPOs since implementation technologies, support levels, and mission requirements
may vary widely. For simplicity, this document will primarily focus on each operational unit
having a single VDPO.
Note that a particular vulnerability may affect a system that supports multiple services acrossmultiple agencies. When a system serves multiple agencies, the other agencies help determine
how and when to address the vulnerability. The relevant system owner will work with theimpacted agencies to coordinate and appropriately address a vulnerability. The responsibility forevery vulnerability should reside in a particular system covered by a single, lowest-level VDPO.
A “reporter” is an entity who submits a source vulnerability report to a government organization.
The reporter may be an entity outside of the Government, within the Government, or even within
the specific system that has the vulnerability. In any case, when a user of a government systemfinds a security-related vulnerability in a deployed government system, the reporting, resolution,and possible public announcement of that vulnerability should follow these guidelines.
The “public” is anyone who might be impacted by or needs to take action for (e.g., mitigation or
remediation) a specific vulnerability. For some vulnerabilities, the public might be the entire
world (e.g., when an advisory about a vulnerability is placed on a public website like NVD). At
other times, the public might be more constrained, such as the user base of a government system.
The “external coordinator” (EC) refers to any vulnerability disclosure entity not within the FCB
or the VDPO that receives the source vulnerability report. The EC may be a private, academic, or
non-profit vulnerability program with no relation to the Government or be another VDPO within
the Government. It also may be the developer of commercial or open-source software that is usedin or by the government system.
Existing vulnerability disclosure programs within the Federal Government predate theseguidelines, and the publicly available policies and guidelines for these programs appear to belargely compliant with the ISO/IEC standards. Appendix C provides a partial list of suchprograms, as well as links to their websites, policies, and procedures. NIST also maintains a listof examples and actual policies and procedures on the Vulnerability Disclosure Guidance project
webpage. 1 Although this site is updated as more resources become available, it is not intended to
be an exhaustive list of all government VDPOs and FCB guidance.

1

See https://csrc.nist.gov/projects/vdg.

4

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Usage of Document Terminology
In the context of this document, the term “vulnerability” refers to a security vulnerability in an
information system. It does not refer to other kinds of vulnerabilities that may pertain to, forexample, physical security, economic security, or foreign policy issues.
The terms “should” and “should not” indicate that – among several possibilities – one isrecommended as particularly suitable without mentioning or excluding others, that a certain
course of action is preferred but not necessarily required, or that (in the negative form) a certain
possibility or course of action is discouraged but not prohibited. The terms “may” and “need not”
indicate a course of action permissible within the limits of the publication. The terms “can” and“cannot” indicate a possibility and capability, whether material, physical, or causal.
This document leverages the ISO/IEC standards as much as possible in forming vulnerability
disclosure guidelines for the Federal Government. Federal vulnerability disclosure programs
should follow, to the extent possible, the terminology used in this document to facilitate
interoperability in communications (e.g., using the same names for the various actors), as well as
for internal efforts of identification, assessment, and the minimization or elimination ofvulnerabilities. When a needed term is not defined in this document but does exist in the
ISO/IEC standards, the term from the standards should be used. A glossary of the major terms
used in this document is provided in Appendix B.

5

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Federal Vulnerability Disclosure Coordination Body
The Federal Coordination Body (FCB) is a group of cooperating government entities that operate
at the federal level to ensure vulnerability disclosure coordination services for all government
agencies and may also provide services to non-government industry sectors (e.g., health care).
Members of the FCB utilize their resources and capabilities to:•

Receive source vulnerability reports,•

Coordinate and investigate to identify vulnerable systems,•

Route findings reports to appropriate entities, and•Produce advisories about vulnerabilities.

The coordination process is summarized here and described in detail in the subsequent sections.

Fig. 2. Federal vulnerability disclosure coordination process

6

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Each FCB member should, at a minimum, perform the three high-level functions shown in Fig.
2. Prior to operation, the FCB members should have developed the capability to receive source
vulnerability reports, determined the scope of their operations, and established federal andindustry contacts. Some additionally support a technical analysis capability.
The remainder of Fig. 2 addresses the operational aspects. In operation, the FCB receives thesource vulnerability reports and investigates them to determine validity and prioritize resource
allocations. Vulnerability reports that do not identify government-only systems may be routed to
an industry vulnerability coordination group and/or be delivered directly to the appropriate EC,
such as a software developer.
The FCB works with the VDPO closest to the affected system to identify the specificvulnerability. If the vulnerable software or service is not government-owned, the FCB forwards
the report to the appropriate developer or to an industry vulnerability coordination group. The
FCB may then work with the relevant VDPO to produce an advisory about the impact of thevulnerability on applicable government systems. If the software or service is governmentdeveloped or supported, the FCB will submit a findings report to the applicable VDPO forvulnerability verification and remediation. The FCB will aid the relevant VDPO if requested andper resource availability. Finally, the FCB may publish an advisory on the vulnerability if theagency – more specifically, the relevant system owner – determines that the vulnerability may
have a public impact.
It is not expected that there will be a large number of FCB members. Rather, the FCB may
include agency operational units with special mission expertise not aligned with existing FCB
members. Each FCB member supports a defined subset of the Government, minimizing theoverlap of scope as much as possible. In addition, the FCB members expend resources engaging
and coordinating with industry to fix vulnerabilities within industry products that are used by theGovernment. Most agencies will leverage the services provided by an FCB member, will notthemselves be part of the FCB, and will instead establish their own VDPOs to handle thevulnerabilities discovered within their own systems.
Preparation
FCB members need to develop several foundational policies and capabilities, including theability to receive source vulnerability reports, coordinate securely with reporters, determine thescope of services for federal systems, and – optionally – develop a technical vulnerability
analysis and mitigation team.
2.1.1. Create Source Vulnerability Report Receipt Capability
Each FCB member should develop the ability to receive source vulnerability reports from
reporters, maintain a database of received reports, and engage in secure communications (e.g.,using a report tracking system). 2 The expectation for communication with the reporter should beestablished, including the initial acknowledgment, status updates, and agreed-upon method ofcommunication. The actual receipt of a source vulnerability report may take multiple forms (e.g.,email, web forms, or a phone hotline) and should be stated in a public policy. It is also2Additional guidance for creating a vulnerability reporting mechanism is provided in [ISOIEC_29147], Sections 6.2.1 and 6.2.2.

7

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

recommended that a list of VDPOs supported by the FCB member along with a link to theirexternal vulnerability disclosure policies be made publicly available. This allows the reporter toboth choose where to send the report and know which VDPOs work with the FCB member.
Section 3.2.1 provides guidance on the creation of vulnerability disclosure acceptance policies.
Source vulnerability reports should include a description of the product or service affected; how
the potential vulnerability can be identified, demonstrated, or reproduced; and what type offunctional impact the vulnerability allows. Due to the sensitivity of the information, agencies
should provide mechanisms for confidentially receiving additional information within the reports(e.g., web forms, bug or issue tracking systems, vulnerability reporting services, email
addresses). To facilitate verification of the vulnerability, agencies should design reporting
mechanisms for assessing the validity, technical severity, scope, and impact of vulnerabilities.
This information could include:•

Product or service name and affected versions•

An identified host or its network interface•

Class or type of vulnerability, optionally using a taxonomy like CWE (Common
Weakness Enumeration)•

Possible root cause (or CVE if known)•

Proof-of-concept code or other substantial evidence•

Tools and steps to reproduce the vulnerable behavior•

Impact and severity estimate•

Scope assessment and other products, components, services, or vendors thought to beaffected•

Disclosure plans (specifically, embargo and publication timelines)

When applicable, the source vulnerability report should also indicate whether the vulnerability
affects multiple systems, their commonality, and if the other system owners have been notified.
2.1.2. Determine Scope and Obtain Contacts
Prior to the receipt of any vulnerabilities, each FCB member will determine which government
VDPOs fall within the scope of their services. The FCB member will then obtain and maintain alist of VDPO contacts within the relevant government agencies that receive and handle source
vulnerability reports. Each FCB member should develop the capability to forward reports to
VDPOs and to engage in ongoing communications to enable coordination. Lastly, FCB members
may engage with industry-tied vulnerability coordination entities (e.g., CERT/CC 3) to facilitate
coordination with non-government software and/or service providers.

3

CERT/CC can be found at https://www.kb.cert.org/vuls/report/.

8

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

2.1.3. Develop Technical Analysis Capability
The FCB may develop technical vulnerability analysis and remediation capabilities to triage theimportance of incoming source vulnerability reports, verify the existence of reported
vulnerabilities, and assist the VDPO closest to an affected system with analysis and remediation
efforts. They could be used, for example, to address severe vulnerabilities applicable to multiple
VDPOs and to assist smaller VDPOs that may not have sufficient resources to assess andremediate vulnerabilities.
Receive Source Vulnerability Report
An FCB member receives source vulnerability reports from reporters who are both internal andexternal to the Government using the policies and capabilities developed in Section 2.1. If thereport is not within scope or cannot be verified, the FCB member should inform the reporter
and/or forward the report to an appropriate FCB member or EC. If the report is determined to bewithin scope, a dialogue should be maintained between the FCB member and the reporter toenable the exchange of additional and clarifying information. If the reporter intends to publicly
announce the vulnerability, the FCB can work with them to develop a disclosure schedule (e.g.,coordinating public disclosure with patch distribution).
While the FCB receives source vulnerability reports for all government systems, a reporter may
choose to report directly to a vulnerable system’s VDPO. 4 In this case, the applicable VDPO will
coordinate with the FCB (as appropriate) to notify other impacted agencies, request technicalassistance, and produce advisories. VDPOs also provide a copy of all received reports to theircorresponding FCB member for entry into the FCB reporting database.
Triage and Prioritize Source Vulnerability Report
FCB members should prioritize source vulnerability reports depending on the vulnerability’s
apparent:•

Ease of exploitation,•

Exposure of government systems to the vulnerability, and•Technical severity of impact on the users of the affected software or services.

For calculating vulnerability severity and ease of exploitation, FCB members should use adocumented vulnerability scoring methodology (e.g., the Common Vulnerability Scoring System[CVSS] 5). This score should be customized with the environmental factors of expected
government system exposure and user impact in order to calculate the priority of all received
reports.
Coordination with the VDPOs by the FCB may be required to determine the likely scope ofgovernment resources impacted by the reported vulnerability. This prioritization optimizes
resource allocation and determines the urgency for addressing a report. A vulnerability in asoftware library or other shared resource may affect multiple government systems with differing
4
5

The reporter-to-VDPO relationship is covered in Section 3.
The CVSS can be found at https://www.first.org/cvss/ and https://www.first.org/cvss/specification-document.

9

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

levels of technical severity. For the purposes of prioritization, the highest calculated severity 6
should be used.
Determine the Reported Vulnerable System
Through collaboration with the VDPOs, the FCB member should identify the owners of thesystem in which the reported potential vulnerability may exist. If the report does not apply to agovernment system (i.e., the report pertains to non-government authored software not used by
the Government), it should be forwarded to an appropriate EC. This could be an industry-focused
vulnerability handling organization or the responsible vendor. Further FCB involvement may not
be necessary after notifying the reporter of the resolution.
Identify the Reported Vulnerable Software
If the reported vulnerability does pertain to the system of a VDPO, the FCB should support the
VDPO in identifying any affected government IT systems and the potentially vulnerable
software within that system. The source vulnerability report may identify a vulnerable service(e.g., a government web server) without specifying what underlying software is vulnerable.
Many products are complex systems that include or are dependent on other products orcomponents. Therefore, the initial analysis may not result in a clear understanding of which
products are affected by the vulnerability. It may take multiple iterations of discovery andresearch before a determination can be made that the vulnerability exists within governmentproduced software or commercial or open-source software used by the Government.
If the potentially vulnerable software is commercial or open source (i.e., non-government
developed software that appears to affect government systems), the FCB member or VDPO
should identify the software owner and forward the report to that EC. If that is not possible, thereport should be sent to an industry-focused vulnerability handling organization. Credit should
be given to the original reporter if requested. The FCB should monitor the progress of thevulnerability verification and remediation and update both the reporter and the affected VDPOs
regarding the resolution status of the vulnerability.
Verify and Remediate Vulnerability
If the potentially vulnerable software is in government-developed or supported software, the
FCB will transfer control of the received source vulnerability report, augmented with theadditional findings to date (e.g., specific vulnerable system), to the VDPO closest to the affected
system. The VDPO will then lead the vulnerability handling resolution in compliance with theirinternal vulnerability disclosure policy (verifying and mitigating the vulnerability), as describedin Section 3.2.1. The VDPO should inform the FCB member of their status in resolving thevulnerability, and the FCB member should record this in their vulnerability reporting database.
The FCB may offer technical assistance based on prioritization of the vulnerability and theavailability of resources.
6
Note that this deviates from the [ISOIEC_30111] standard, which recommends using the severity of the most common configuration used. This
does not imply that the standard is incorrect but that it reflects a different focus. This guidance pertains to deployed government systems, while
the ISO standard is designed for software products that may be deployed widely in many different configurations.

10

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Determine Whether to Publish an Advisory
For every verified vulnerability, a determination must be made as to whether to issue anadvisory, the target audience of that advisory, and which advisory service should be used. An
advisory is typically issued when a remediation has been developed and deployed (e.g., when apatch is released). However, extenuating circumstances may require more than one advisory. If atemporary mitigation will prevent a vulnerability from being exploited, then an advisory
describing the mitigating steps should be issued with appropriate notation. When thevulnerability can be remediated, an additional advisory should be issued.
2.7.1. Determine Whether Public Disclosure is Warranted
For each vulnerability identified in government systems, the VDPO in whose system thevulnerability exists should determine whether or not public disclosure is warranted. If thevulnerability exists in multiple agency systems, the FCB should coordinate the response andpublication with the stakeholders.
Public disclosure may be considered if:•

The specific vulnerability is not publicly known (i.e., does not have a CVE number);•

The vulnerable system is used by the public (i.e., outside of the Government);•

There is a risk that personally identifiable information (PII) or other sensitive information
has been exposed;•

The specific vulnerability relates to a defect or flaw in the affected product, which could
impact the security of users outside of the VDPO’s agency (especially if code isvulnerable); or•

The public is at risk of harm in some way or needs to take some action to secure
themselves (e.g., install a patch, update software, or change their passwords).

Public disclosure may not be necessary or recommended if the vulnerability does not affect the
public. For example, publication is likely unnecessary if government staff have already fixed thevulnerable system and have found no evidence that the vulnerability was exploited. Advisorysystems can then focus on vulnerabilities that require user action for continued security andprivacy.
If the use of commercial or open-source software is responsible for a vulnerability withingovernment systems, then the FCB should work toward the creation of a public advisory for thevulnerable software. This advisory may not be published using a specific government system
advisory service but rather one that addresses software industry vulnerabilities (e.g., the CVElist). The FCB should consider releasing a separate government advisory if the public wasaffected by the existence of the vulnerabilities in government systems (e.g., sensitive information
was leaked, or a patch needs to be applied).
In some cases, a reporter will advise the Government about a vulnerability for which it is not
appropriate to create an official advisory. This may preclude them from receiving public credit
for the service provided. In these rare cases, a bug bounty program with publicly accessible logs

11

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

may be helpful to both financially remunerate the reporter and provide a public place to givethem credit.
2.7.2. Produce Advisory
The FCB should be the primary focal point of government vulnerability advisories. However,this should not preclude an agency from releasing advisories for vulnerabilities in their systems
or communicating with appropriate stakeholders. 7 Advisories should publish or disclose
information about identifying and remediating the vulnerability with a brief, high-level summaryof the vulnerability to help users understand the salient points of the findings report and quickly
determine if the advisory applies to their environment.
For actively exploited vulnerabilities without available remediation, advisories could inform
users of the current threat and the steps to take in order to reduce risk. When other products sharevulnerabilities with other products and/or systems, authors should coordinate the timing ofadvisory releases with those product and/or system owners. The advisory elements should
contain sufficient information to enable the target audience to decide if the vulnerabilities are
relevant and how to remediate them. The timing of the release of advisories should balance risk
with potential disruption to users. For example, batched or scheduled releases may minimize
disruption.
Advisory authors should also consider the needs of the intended audience and produce advisories
that are effective in terms of informational content, distribution mechanisms, and presentation
format. The typical audience includes users who are responsible for identifying vulnerable
systems and performing remediation. Advisories may include sections for specific audiences,such as further remediation advice for developers, system administrators, or end users.
Audience-specific language in an advisory is optional.
The following elements should be considered for inclusion in an advisory:•

Advisory identifiers and vulnerability identifiers should include the product name;version information; a reference to a known, supported, and affected product, as well as
instructions to verify the version of the product; and a unique and consistent identifier tominimize confusion with different advisories or vulnerabilities. Advisory authors shouldchoose a common, shared vulnerability identification system, such as CVE. However, theinformation should not give too much detail to avoid enabling exploitation of thevulnerability. Helpful information to describe affected products can include:o Common or historical product names
o Version numbers or stringso Class or type of vulnerabilities (e.g., CWE taxonomy)o File hashes

o Proof-of-concept code to safely test for the existence of the vulnerability

7

Specific requirements for creating a vulnerability advisory mechanism are provided in [ISOIEC_29147], Section 7.

12

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines•

The advisory should contain the date of the initial publication and possibly other dates(e.g., revision history). Advisories should use date and time references in accordance with
[ISO_8601].

•

The description of the potential impact or consequence of the vulnerability should, at aminimum, explain the potential behavior that the vulnerability allows. The information
could include security violations, access or privilege gains, likely subsequent impacts,
and common attack scenarios. A technical severity rating system used in the advisory
should be documented and the documentation referenced from the advisory. Existing
technical severity rating systems, such as CVSS, should be leveraged to the extent
possible.

•

The remediation element should include information about actions that affected users
should take to remediate the vulnerability. The advisory may also provide mitigating
measures to protect affected products or services until a remediation is implemented.
References to additional or related information may be added and should use original orsource material and common cross-references, such as CVE, where applicable.

•

The advisory should provide contact information, and methods for communicating
advisories to users should be established and maintained. Best practices may vary (e.g.,
websites, mailing lists, feeds, automatic update mechanisms, posts on public vulnerability
discussion forums).

•

If the reporter wishes to be publicly recognized, the advisory should acknowledge thereporter for reporting the vulnerability.

•

The advisory should also include the copyright, terms of use, and redistribution of theadvisory.

2.7.3. Government Advisory Services
The Federal Government maintains advisory services to reduce risks to both the cybersecurity
and economic security of the United States, including federal agencies that serve the public andall economic actors in the Nation. The computer security industry also maintains a variety ofboth free and paid vulnerability advisory services. The Federal Government participates in theadvisory services ecosystem to ensure the provisioning of accurate and comprehensive
vulnerability listings.
Below is a partial list of government vulnerability advisory resources available as of the writingof this document.
2.7.3.1.

National Cyber Awareness System

The National Cyber Awareness System (NCAS) contains five products that provide information
on vulnerabilities and related threats [CISA] to technical users:
1. Current Activity – provides details on the most frequent, high-impact types of security
incidents currently being reported

13

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

2. Alerts – provides timely information about current security issues, vulnerabilities, andexploits
3. Bulletins – provides a weekly summary of the newest vulnerabilities
4. Analysis Reports – provides in-depth analysis on new or evolving cyber threats
5. Industrial Control System (ICS) – provides timely information about current security
issues, vulnerabilities, and exploits
2.7.3.2.

National Vulnerability Database

NIST maintains the National Vulnerability Database [NVD], which is the U.S. Government
repository of standards-based vulnerability management data. It contains a database of almost all
publicly disclosed vulnerabilities – more specifically, all vulnerabilities included within the
Common Vulnerabilities and Exposures (CVE) dictionary [CVE]. NVD staff members analyze
vulnerability descriptions to provide succinct and machine-readable information, such as
vulnerable software versions, informational references, vulnerability attributes, underlying
software flaw types, and technical severity scores.
Stakeholders in Federal Vulnerability Disclosure Coordination
Every government agency is a stakeholder in federal vulnerability disclosure coordination, andeach should have at least one VDPO or be supported by a VDPO through an agreement with
their parent agency. Orchestrating coordination among VDPOs is a primary role of the FCB.
FCB membership may change and expand over time.
Technical Approaches and Resources
The FCB should leverage an existing technical infrastructure for vulnerability disclosure to theextent possible during the vulnerability management coordination process. This section
recommends the use of certain technologies to enhance vulnerability coordination activities. As
the reporting of vulnerabilities matures, the FCB may recommend alternative technologies thatsupersede the guidance in this section.
The CVE naming scheme should be used when referencing publicly disclosed vulnerabilities.
The CVE website is focused on providing unique identification for each vulnerability to maintainthe CVE list. It is not intended to act as an advisory service. When referencing a CVE
vulnerability, the NVD link should be used since it provides an analysis of each CVE and any
referenced information. FCB members should also be prepared to submit CVEs by becoming
CVE Numbering Authorities (CNAs) or Authorized Data Providers (ADPs).
The technical severity of all vulnerabilities could be rated using the Common Vulnerability
Scoring System’s (CVSS) base score equations. 8 Its scores reflect an estimated technicalseverity 9 for the vulnerability in relation to the worldwide information technology infrastructure.

89

A calculator for such scores is available at https://www.first.org/cvss/calculator/3.1.
While useful, the severity may be higher or lower for any instance of a vulnerability in a particular environment.

14

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

When possible, the underlying software flaw for each vulnerability should be documented, andeach CVE should be mapped to one or more security elements in the [CWE] list.
The NIST Bugs Framework is a complementary system that provides:…factoring and restructuring of information contained in Common
Weakness Enumeration (CWE), Software Fault Patterns (SFP), Semantic
Templates (ST) and numerous other sources. The goal is to categorize
the types of weaknesses unambiguously, allowing similarities anddifferences to be easily explored and examined. [NIST_TBF]
Most vulnerabilities are described using a textual description, which may not be machinereadable. This approach may also leave out important details because a structured data
framework is not being followed. To address this, NIST has created the Vulnerability Data
Ontology or Vulntology project, which provides an ontology “to characterize vulnerabilities andprovide a granular and intuitive structure for that information” and “is intended to be a drop-in
replacement for a vulnerability description” that is structured and machine-readable[NIST_VULN].

15

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Vulnerability Disclosure Program Offices
This section describes the duties and operation of a Vulnerability Disclosure Program Office(VDPO) and how it should work with the FCB and reporters to assess potentially vulnerable
systems and software. After verifying the merit of source vulnerability reports, VDPOs should
support system owners with the tasks of vulnerability verification, mitigation and/or remediation,
and advisory publication.
Vulnerability Disclosure Program Office Description
VDPOs should ideally be implemented as part of an information technology security office(ITSO) or existing program. ITSOs already have security oversight and support duties for all
systems, which benefits a VDPO by providing needed communications and contacts to all
systems (e.g., the system owners and their security officers). The role of the VDPO will, in turn,benefit an ITSO with the management of reported vulnerabilities.
A VDPO may be an office with its own dedicated personnel or a virtual office with duties androles assumed by members of the operating unit’s ITSO. At a minimum, it will consist of staff
who perform coordination and oversight duties and engagement with vulnerability disclosure
reporters. However, the VDPO may extend to provide technical services to system owners to
support their efforts in verifying and remediating vulnerabilities. In this case, the VDPO may
include more technically oriented developers or systems administrators with security expertise.
Vulnerability Disclosure Program Office Structural Requirements
A VDPO is a key unit of an information technology security office that focuses on vulnerability
reporting management. Its structural requirements include:
1. Development of source vulnerability report acceptance policies and the capability toreceive source vulnerability reports
2. Monitoring of source vulnerability reports
3. Processing and resolution of source vulnerability reports
a. Identification of potentially vulnerable systems and software
b. Verification of a source vulnerability reportsc. Oversight and support for the mitigation or remediation of verified vulnerabilities
4. Development of vulnerability disclosure handling proceduresFig. 3. VDPO structural requirements

16

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

These elements are explained in detail in the subsequent sections. The VDPO should consider
basing its specific policies and processes on guidelines and procedures used by the FCB andsimilar VDPOs. It does not have to develop or implement these policies and processes inisolation.
In performing these duties, a VDPO will implement the vulnerability disclosure standard[ISOIEC_29147]. It will also provide oversight and support for system owners who perform thevulnerability handling duties described in [ISOIEC_30111]. This document augments rather thanreplaces the requirements and recommendations provided in these standards to address systems
and software development utilized by the U.S. Government. 10
3.2.1. Development of Source Vulnerability Report Acceptance Policies
Each VDPO is urged to adopt the generic policy of their associated FCB member, withmodifications as appropriate. 11 Existing agency policies can be found in Appendix C. A publicly
available external policy as well as an internal policy should be developed. In alignment with
[BOD20-01], the external policy should detail the methods by which to report a vulnerability to
the affected system’s ITSO, as well as expectations for the acknowledgement and resolution ofvulnerability disclosure reports. It should also describe the rules of engagement to be followed
when probing agency systems for vulnerabilities and how deeply to probe upon the discovery ofa vulnerability. This is particularly relevant to security researchers, whether or not it is tied tobug bounty programs. The policy should include a commitment to not recommend or pursue
legal action against the reporter if the rules are followed, as well as information on eligibility for
public recognition and/or a potential bounty (i.e., financial payout), if available.
The internal policy governs the rules and procedures for handling, coordinating, and resolving
received vulnerability reports; the mechanisms used to track the reports; and the expectations forcommunication with reporters and other stakeholders. Expected response and remediation
timelines for handling vulnerability reports should be specified, as well as a procedure to follow
when working with the FCB to publish advisories and distribute remediations (e.g., patches) tousers of vulnerable agency software. The policy may also specify the levels of testing required
for the remediation of agency systems and any remediation hurdles that may exist (e.g., forlegacy systems).
3.2.2. Monitoring of Source Vulnerability Reports
VDPOs should monitor their reporting mechanisms for new reports and communications related
to existing reports. VDPOs should also monitor public sources for vulnerability reports and theorganizational communications channels that are likely to receive them, such as customer service
and support.

10This publication is intended to be used in conjunction with [ISOIEC_29147] and [ISOIEC_30111]. It is recommended that organizations using
this publication obtain the standards in order to fully understand the context of the vulnerability disclosure guidelines.
11
Additional guidance for creating vulnerability disclosure policies is available in [ISOIEC_29147], Section 9.

17

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

3.2.3. Processing and Resolution of Source Vulnerability Reports
Each VDPO should develop the ability to communicate and coordinate with their FCB member
to resolve vulnerability reports, which requires the development of both technical andpersonnel/procedural capabilities. If the FCB member provides technical mechanisms tostreamline this process, the VDPO should use the provided mechanisms. It is also possible toprocure commercial VDP services, particularly for reporting, tracking, and researcher
communications.
If a VDPO chooses to conduct its own vulnerability research and testing, it should forward all
pertinent information to its FCB member for inclusion in an FCB vulnerability report database.
This capability may be used to generate vulnerability reports for internally discovered
vulnerabilities (i.e., reporters within the agency) or for external reports sent directly to the ITSO
closest to the affected system (i.e., reporters that notify an IT system of a vulnerability in thatsystem). By doing this, agencies can choose to handle vulnerability disclosure duties themselves
for their own systems while keeping their associated FCB member apprised of incoming reports
and leveraging them for vulnerability advisory publications.
VDPOs should implement operational security throughout the process of receiving andcommunicating vulnerability reports. Reporting mechanisms and ongoing communications
should be secure and restrict unauthorized access to sensitive, non-public vulnerability
information. The internal operational security should also restrict non-public vulnerability
information and any PII obtained about reporters to staff and organizational units on a need-toknow basis.
3.2.4. Development of Vulnerability Disclosure Handling Procedures
Each VDPO should develop and maintain internal vulnerability handling procedures for how itwill investigate and remediate vulnerabilities in coordination with external and internal
vulnerability disclosure policies. The internal vulnerability handling procedures should define
who is responsible at each stage of the vulnerability handling process and how they should
handle reports about potential vulnerabilities. It should include the guidance, principles, andresponsibilities for managing potential vulnerabilities in products or services; a list of internalorganizations and roles responsible for handling potential vulnerabilities; safeguards to preventthe premature disclosure of information about potential vulnerabilities; and a target schedule for
remediation development.
VDPO policies may leverage FCB-provided templates (created to encourage a uniform approachwithin multiple agencies). They should, to the extent possible, use the same vulnerability
disclosure terminology, technical severity ratings, technologies, and standards utilized by theirassociated FCB member.
3.2.5. Vulnerability Disclosure Program Office Operational Duties
This section provides details on the steps that VDPOs should take to receive, process, andresolve vulnerability reports. This guidance applies primarily to report handling in the U.S.
Government environment. Fig. 2 and Fig. 4 work together to describe the coordination between
an FCB member and a VDPO in the vulnerability disclosure process.

18

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Figure 4 shows the VDPO’s operational duties.

Fig. 4. Process flow specification for VDPO operational duties

3.2.5.1.

Receipt of Source Vulnerability Reports

The VDPO should send a receipt confirmation to the reporter when it receives a source
vulnerability report and work with the system owners to identify the potentially vulnerable
systems and software. Every source vulnerability report should have a priority rating assigned by
the FCB member that is used to optimize resource allocations and determine the urgency of
19

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

handling each report. A VDPO may choose to perform the prioritization prior to communicatingwith its FCB member, or it may work with the FCB to determine priority. 12
3.2.5.2.

Identification of Potentially Vulnerable Systems and Software

The first step to addressing a source vulnerability report is to identify the potentially vulnerable
technologies and the IT systems to which the report belongs. To enable this, each VDPO should
maintain a current list or database of contacts for each system within its purview. In some cases,
a VDPO that has received a source vulnerability report may need to coordinate with multiple
system owners (or their security officers) to determine which system or software is potentiallyvulnerable. This step does not involve verifying the existence of the vulnerability but merely
identifying to which system the report belongs.
Many products are complex systems that include or are dependent on other products orcomponents. Therefore, the initial analysis may not result in a clear understanding of which
products are affected by the vulnerability. It may take multiple iterations of discovery andresearch before a determination can be made that the vulnerability exists within governmentproduced software or commercial/open-source software used by the Government.
3.2.5.3.

Oversight and Support for the Verification of a Source Vulnerability
ReportThe VDPO closest to the affected system should support the system owner (or their security
officer) in verifying the existence of the vulnerability. If the VDPO or the associated FCB
member has technical resources available to assist system owners in verifying vulnerabilities,
those resources may be utilized upon request by the system owner.
The investigation of a possible vulnerability often involves attempting to reproduce theenvironment and behavior described by the reporter. The analysis can also include correlating
similar or related reports, assessing technical severity, and identifying other affected products.
The product, subcomponent, and methods of exploitation should be documented. If the initial
analysis shows that the vulnerability exists in the system’s product or service, further
investigation is needed, including a root cause analysis. The investigation may extend to related
products that utilize the same services or components to assess the extent of the impact, theoverall severity of the vulnerability, and the likelihood of exploitation. This information may
influence the prioritization of follow-up activities.
If a vulnerability is discovered in non-government-developed software that is used by agovernment system, the source vulnerability report should be routed to the FCB for coordinationand handling. If it is determined that no vulnerability exists, the entity that originally received thesource vulnerability report (likely an FCB member but possibly the VDPO) should respond to
the reporter and explain the finding. The reporter may then provide additional details provingthat a vulnerability exists and trigger further investigation. If the source vulnerability reportcannot be verified, it should be forwarded to the FCB for finalization in their database and any
final communication with the reporter. Even if a source vulnerability report cannot be verified, it
is still important to appropriately communicate with the reporter.
12

See Section 2.3 for guidance on report prioritization.

20

NIST SP 800-216
May 2023

3.2.5.4.

Federal Vulnerability
Disclosure Guidelines

Oversight and Support for the Remediation of Verified Vulnerabilities

Once the vulnerability has been verified, the VDPO will ensure that the system owner has
mitigated or remediated the discovered vulnerability. As with the verification step, if the VDPO
or an associated FCB member has technical resources to assist with vulnerability remediation,
they may be deployed upon request by the system owner.
In some cases, it may be effective to develop short-term mitigations (e.g., recommended
configuration changes) to be followed by more thorough mitigations or a remediation. A
mitigation or remediation approach may involve a patch, fix, upgrade, or configuration change toreduce exploitation of the vulnerability and should include appropriate documentation. A seriesof early communications may be necessary to alert the user base while the full solution is being
developed and tested for all of the affected platforms and services. Subsequent monitoring andtesting will also be needed to ensure that the solution resolved the vulnerability issue in a manner
acceptable to stakeholders without impacting the product’s functionality or introducing new
vulnerabilities. The VDPO should ensure that lessons learned are incorporated into thedevelopment process to reduce future vulnerabilities.
The VDPO should also notify the FCB if a vulnerability is found in an information system,
product, or service used by others (e.g., other agencies, organizations, or the general public).
Remediating such vulnerabilities typically requires the involvement of the product or service
owner (e.g., vendor, supplier, provider) to produce and distribute a patch or update. VDPOs may
also notify the product or service owner directly through existing support channels. In turn, theproduct or service owner should assist stakeholders in dealing with vulnerabilities until a producthas reached the end of service. If the product or service owner chooses not to remediate all
supported versions, a reasonable upgrade path to a version that has remediations should be
provided.
After the vulnerability remediation release, monitoring of the stability of the product or service
should continue. The responsible VDPO should update remediations as appropriate until further
updates are no longer needed. The information gained during the root cause analysis should be
used to update development life cycle elements to prevent similar vulnerabilities in new or
updated products or services.
Proposed remediations and communications may need consultation from legal review to ensurethat the responsible agency complies with internal policies, laws, and existing contracts.
3.2.5.5.

Publication of Vulnerability Advisories

Section 2.7 provides guidance on whether or not an advisory should be produced for a
remediated vulnerability. The owner of the system that contained the vulnerability should makethe determination in coordination with the VDPO. If the vulnerability involves multiple
government systems (e.g., because they all used the same vulnerable library), then the applicable
FCB member should make the decision. Advisories published only to the users of a system canbe made at the system level with the support of the VDPO. Public advisories should be madeusing an established FCB advisory service. Advisories that only target the user base of a system
might be made by the system owner within the system itself (coordinated with the VDPO towhom that system is assigned).

21

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Management Considerations
This section describes management considerations for creating one or more VDPOs.
3.3.1. Leadership Support
Support from leadership is critical in this endeavor and should include communications about theimportance of the program. Top management should ensure that the vulnerability handlingprogram’s objectives are compatible with the organization’s strategic direction and integrated
into the organization’s existing processes. Roles should be assigned along with resources toempower the implementation of the program. Communication from leadership should emphasize
support for a continuous improvement process and include a mechanism to report progress toupper management.
Agency reporting of their cybersecurity status to leadership should include metrics related to the
VDPO. This will keep leadership aware of progress with the agency’s vulnerability disclosureand remediation process.
3.3.2. Staffing Needs
The use of existing information security operations and compliance staff is strongly encouraged.
The VDPO’s staff need to have a strong grasp of the nature of reported vulnerabilities tocoordinate with appropriate parties, handle sensitive information, and confidentially interact withpartners and stakeholders. Management should designate roles and assign appropriate
authorization to allow for accountability and enable the program’s successful implementation.
These positions may include a champion to act as a change agent to foster communication andpromote stakeholder buy-in at all levels.
3.3.3. Leveraging Existing Processes
Existing operational processes across multiple programs can be leveraged to support thevulnerability process, though they may vary and need to be aligned. A gap analysis may benecessary to identify essential policy components to enable intra-agency and inter-agency
programs to share and collaborate. As part of the effort for continual improvement, a mechanism
should be implemented to allow for regular assessment and feedback on the effectiveness of thedeveloped process, as well as provide data for insights, improvements, and lessons learned.
3.3.4. Integration of Contractor Support into the VDPO
Policy considerations pertaining to the handling, resolution, and correction of vulnerability
disclosure information should be included in any contracts that support a federal information
system in order to mitigate or resolve the vulnerability.
3.3.5. Customer Support and Public Relations
Handling vulnerabilities requires a holistic approach that engages aspects beyond engineeringand technology. Customer service and public relations are equally important. If a disclosed
22

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

vulnerability is a severe or widespread issue, coordination with public relations may be needed toprepare for contact from news media. Organization planning should consider facilitating closeworking relationships and supporting customer service to handle and respond to security
vulnerabilities. These capabilities may vary from a confidential means of communication withstakeholders to the escalation of questions from advisories for a coordinated response.

23

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

References[BOD20-01]

Cybersecurity & Infrastructure Security Agency (2020) Binding
Operational Directive 20-01 – Develop and Publish a Vulnerability
Disclosure Policy. Available at https://www.cisa.gov/binding-operationaldirective-20-01[CISA]
Cybersecurity & Infrastructure Security Agency (2020) National Cyber
Awareness System. Available at https://us-cert.cisa.gov/ncas[CVE]
MITRE (2021) Common Vulnerabilities and Exposures (CVE). Available
at https://cve.mitre.org/[CWE]
MITRE (2021) Common Weakness Enumeration (CWE). Available athttps://cwe.mitre.org/[CYB_IMPR_ACT] IOT Cybersecurity Improvement Act of 2020, Pub. L. 116-207, 134 Stat.
1001. Available at https://www.congress.gov/116/plaws/publ207/PLAW116publ207.pdf[DOJ_VDP]
U.S. Department of Justice, Criminal Division, Cybersecurity Unit (2017)
A Framework for a Vulnerability Disclosure Program for Online Systems.
(U.S. Department of Justice, Washington, DC). Available athttps://www.justice.gov/criminal-ccips/page/file/983996/download[GSA_TTS_PDV]
U.S. General Services Administration, Technology Transformation
Services. Public Disclosure of Vulnerabilities. Available athttps://handbook.tts.gsa.gov/responding-to-public-disclosurevulnerabilities/[ISO_8601]
International Organization for Standardization (2010) ISO 8601-1:2019 –Date and time – Representations for information exchange – Part 1: Basic
Rules (ISO, Geneva, Switzerland). Available athttps://www.iso.org/standard/70907.html[ISOIEC_19770]
International Organization for Standardization/International
Electrotechnical Commission (2015) ISO/IEC 19770:2015 – Information
technology – IT asset management – Part 2: Software identification tag(ISO, Geneva, Switzerland). Available athttps://www.iso.org/standard/65666.html[ISOIEC_27002]
International Organization for Standardization/International
Electrotechnical Commission (2013) ISO/IEC 27002:2013 – Information
technology – Security techniques – Code of practice for information
security controls (ISO, Geneva, Switzerland). Available athttps://www.iso.org/standard/54533.html[ISOIEC_27017]
International Organization for Standardization/International
Electrotechnical Commission (2015) ISO/IEC 27017:2015 – Information
technology – Security Techniques – Code of practice for information
security controls based on ISO/IEC 27002 for cloud services (ISO,Geneva, Switzerland). Available athttps://www.iso.org/standard/43757.html[ISOIEC_27034]
International Organization for Standardization/International
Electrotechnical Commission (2011) ISO/IEC 27034-1:2011 –Information technology – Security Techniques – Application Security –24

NIST SP 800-216
May 2023[ISOIEC_27035][ISOIEC_27036][ISOIEC_29147][ISOIEC_30111][NIST_TBF][NIST_VULN][NVD][OMBM-20-32]

Federal Vulnerability
Disclosure Guidelines

Part 1: Overview and Concepts (ISO, Geneva, Switzerland). Available athttps://www.iso.org/standard/44378.html
International Organization for Standardization/International
Electrotechnical Commission (2016) ISO/IEC 27035-1:2016 –Information technology – Security Techniques – Information security
incident management – Part 1: Principles of incident management (ISO,Geneva, Switzerland). Available athttps://www.iso.org/standard/60803.html
International Organization for Standardization/International
Electrotechnical Commission (2013) ISO/IEC 27036-3:2013 –Information technology – Security Techniques – Information security forsupplier relationships – Part 3: Guidelines for information andcommunication technology supply chain security (ISO, Geneva,
Switzerland). Available at https://www.iso.org/standard/59688.html
International Organization for Standardization/International
Electrotechnical Commission (2018) ISO/IEC 29147:2018 – Information
technology – Security techniques – Vulnerability disclosure (ISO, Geneva,
Switzerland). Available at https://www.iso.org/standard/72311.html
International Organization for Standardization/International
Electrotechnical Commission (2019) ISO/IEC 30111:2019 – Information
technology – Security techniques – Vulnerability handling processes (ISO,Geneva, Switzerland). Available athttps://www.iso.org/standard/69725.html
National Institute of Standards and Technology (2021) The Bugs
Framework (BF). Available athttps://samate.nist.gov/BF/Home/Approach.html
National Institute of Standards and Technology (2021) Vulnerability Data
Ontology. Available at https://github.com/usnistgov/vulntology
National Vulnerability Database (2020). Available at https://nvd.nist.gov/
Office of Management and Budget (2020) Improving Vulnerability
Identification, Management, and Remediation. (The White House,
Washington, DC), OMB Memorandum M-20-32, September 2, 2020.
Available at https://www.whitehouse.gov/wp-content/uploads/2020/09/M20-32.pdf

25

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Appendix A. List of Symbols, Abbreviations, and Acronyms
CNA
CVE Naming Authority
CVE
Common Vulnerabilities and ExposuresCVSS
CVE Vulnerability Scoring System
CWE
Common Weakness Enumeration
FCB
Federal Coordination Body
ISOInternational Organization for Standardization
NCAS
National Cyber Awareness System
NVD
National Vulnerability Database
VDPO
Vulnerability Disclosure Program Office
VDP
Vulnerability Disclosure Policy

26

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Appendix B. Glossary
bug bounty
A method of compensating individuals for reporting software errors, flaws, or faults (“bugs”) that might allow for
security exploitation or vulnerabilities.
external coordinator (EC)Any vulnerability disclosure entity that receives a vulnerability report that is not within the FCB or the VDPO; theEC may be a commercial vulnerability program with no relation to the Government or a separate VDPO within the
Government, or it may be the developer of commercial or open-source software.
federal coordination
A set of aligned activities across the Federal Government, including identifying and engaging stakeholders,
mediating, communicating, and other planning to support vulnerability disclosure.
Federal Coordination Body (FCB)
A group of cooperating entities that collectively provide high-level vulnerability disclosure coordination among
government agencies; the FCB represents the primary mechanism by which vulnerabilities should be reported to theGovernment and for the Government to produce advisories about government vulnerabilities.
mitigation
The temporary reduction or lessening of the impact of a vulnerability or the likelihood of its exploitation.
product owner
Person or organization responsible for the development, modification, operation, and/or final disposition of softwareor hardware used in an information system.
publicAny entity or person who might be impacted by or need to take action for a specific vulnerability; intended to beloosely interpreted.
remediation
The neutralization or elimination of a vulnerability or the likelihood of its exploitation.
reporterAny entity that reports a vulnerability to the Government and that may be an entity outside of the Government,
within the Government, or within the specific system that has the vulnerability.
system owner
Person or organization responsible for the development, procurement, integration, modification, operation,
maintenance, and/or final disposition of an information system.
Vulnerability Disclosure Program Office (VDPO)
The entity with which an agency coordinates internally to resolve reported vulnerabilities.
Vulntology
NIST Vulnerability Data Ontology, a methodology for characterizing vulnerabilities to enable automated analysis.

27

NIST SP 800-216
May 2023

Federal Vulnerability
Disclosure Guidelines

Appendix C. Examples and Resources for Federal Vulnerability Disclosure
Programs and Policies
This section contains a partial list of references for federal agency vulnerability disclosure
programs. This material is provided to enable agencies to leverage the work of their peers indeveloping and deploying their own programs. This said, these programs were created anddeployed prior to the release of this guidance, and thus, the referenced material may or may notfollow the guidance in this document or in the associated ISO standards. Additional and updated
references can be found at https://csrc.nist.gov/projects/vdg.
Agency/Title

Description

Link

Department of Defense (DoD)
Vulnerability Disclosure Program

Single program office for reporters
to disclose vulnerabilities they
discover on any publicly available
DoD information system

https://www.dc3.mil/Missions/V
ulnerabilityDisclosure/VulnerabilityDisclosure-Program-VDP/

General Services Administration(GSA) Vulnerability Disclosure
Policy

GSA handbook describing their
triage process for reported
vulnerabilities along with handlingand coordination instructions.

https://handbook.tts.gsa.gov/resp
onding-to-public-disclosurevulnerabilities/

Department of Homeland Security(DHS) Vulnerability Disclosure
Framework

DHS template for agencies to guidethem in creating a vulnerability
disclosure policy.

https://cyber.dhs.gov/bod/2001/vdp-template/

Department of Justice (DOJ)
Vulnerability Disclosure
Framework

Step by step guidance for DOJ
agencies instructing them on how tocreate a vulnerability disclosure
program.

https://www.justice.gov/criminal
ccips/page/file/983996/download

Department of Commerce (DOC)
Vulnerability Disclosure Policy

Policy used for DOC vulnerability
disclosure.

https://www.commerce.gov/vuln
erability-disclosure-policy

National Telecommunications andInformation Administration(NTIA), Vulnerability Disclosure
for Safety Critical Industries

Discussion on how to create avulnerability disclosure policy forsafety critical systems.

https://www.ntia.doc.gov/files/nti
a/publications/ntia_vuln_disclosu
re_early_stage_template.pdf

NTIA and FIRST, Multi-Party
Coordination and Disclosure

Discussion of vulnerability
disclosure coordination acrossmultiple stakeholder communities.
It provides a low-level evaluation ofvulnerability coordination issues
along with detailed scenarios.

https://www.first.org/global/sigs/
vulnerabilitycoordination/multiparty/guidelines-v1.1

United Kingdom (UK) National
Cyber Security Center’s
Vulnerability Disclosure Toolkit

Toolkit to help agencies startvulnerability disclosure processes.

https://www.ncsc.gov.uk/information/vulnerability-disclosuretoolkit

28