Skip to main content
U.S. flag

An official website of the United States government

Dot gov

The .gov means it’s official.
Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you’re on a federal government site.


The site is secure.
The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

Public disclosures of vulnerabilities

When someone in the public alerts you to a potential vulnerability in our systems, you need to act quickly. There are four steps in this process:

  1. Triage the vulnerability
  2. Determine an incident
  3. Respond to reporter
  4. Remediate

Triage the vulnerability

In order to respond quickly to reports submitted by the public (aka reporter), the TTS Tech Portfolio will monitor incoming reports and initiate response accordingly. This role has been designated first responder and monitors reports received from the public via emails to, through this reporting form or the Vulnerability Disclosure platform.

The first responder will then provide a brief overview of the issue in #vuln-disclosure and @ (mention) all appropriate personnel. At this point, potential impact must be determined quickly to ensure appropriate steps are taken to remediate the reported issue.

Scores of low, medium, high and critical are based on the CVSS 3.0 scoring.

Each metric above receives a single score on potential impact from the following list:

Rating CVSS Score
None 0.0
Low 0.1 - 3.9
Medium 4.0 - 6.9
High 7.0 - 8.9
Critical 9.0 - 10.0

A score of none means that the report falls outside of scope, or is negligible, or doesn’t contain enough information. If the report is none, jump to the response step.

Determine an incident

In the case of an incident, the responder has determined the vulnerability has already impacted system confidentiality, integrity, or availability. The responder immediately follows the security incident process.

If the first responder is unable to make a determination of risk severity, the responder should immediately post in the #incident-response Slack channel and seek counsel from other responders, as well as @-ing the lead of the affected product or service.

Reply to the reporter

If the report impact is none, send the appropriate message:

  • Not in scope: “Thanks for contacting us. However, this report falls outside of our scope as described at [Add additional details as helpful.]”
  • No impact: “Thanks for sending us this report. However, we have determined that the impact of this issue is not significant. Please feel free to provide additional information that indicates the issue is of higher severity, and we’ll be happy to re-evaluate it.”
  • Not enough information: “Thanks for sending us this report. However, it does not contain enough information for us to reproduce the issue and evaluate its severity. If you can send us additional information, we’ll be happy to evaluate the issue.”


  1. Quickly send an acknowledgement.
  2. Loop in any relevant program staff on the acknowledgement response, so they have a direct line of communication.

The acknowledgement text could be something like:

Thanks for sending us this report. We’re taking action internally to evaluate and reproduce this report. I’m connecting you with the relevant technical staff so that you can communicate directly as needed.

As a reminder, our policy, which can be read at, asks for 90 days from the date you sent your report before you disclose this report publicly.

Remember to CC this email to any relevant program staff or TTS Tech Portfolio leads.


Valid vulnerabilities need to be resolved in the following timeline:

Risk Value Corrective Action Deadline
Critical For Internet-accessible IP addresses: within 15 calendar days of initial detection.
  For all other assets: within 30 calendar days of initial detection.
High Within 30 calendar days of initial detection
Moderate/Medium Within 90 days of initial detection
Low No specific deadline unless defined by the GSA OCISO

Source: GSA Vulnerability Management Process guide, Appendix B. These values will also appear in the RA-5(d) control of your System Security Plan (SSP).

Reports for non-TTS Systems

If you know the alert applies to a system TTS doesn’t have responsibility over, please either submit the report to US-CERT if there is helpful context you can add to it, or direct the public contact to submit the report to US-CERT themselves.

Notifications to partner agencies should do the following:

  1. Find a POC
    1. Look for security@[] or VDP form
    2. Using the list of security contacts
    3. Reach out through professional network
  2. Describe the potential harm
  3. Recommend a course of action