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

This page is out of date

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

In order to respond quickly to reports submitted by the public, the TTS Tech Portfolio team has designated a small group of folks who will monitor incoming reports and initiate response accordingly. This role has been designated first responder and will be assigned in #vuln-disclosure with an @ (mention). Barring schedule conflicts, the role will rotate weekly. The First Responder schedule is posted in the #vuln-disclosure channel topic.

The first responder monitors reports received from the public via emails to or through this reporting form. The report is reviewed and the responder categorizes risk according to the potential impact on system confidentiality, integrity, or availability. 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.

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

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

Scores of low, moderate, and high are subjective.

In the case of an incident, the responder has determined for any reason that 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 TTS Tech Portfolio Lead of the affected product or service.

2. File an issue

For vulnerabilities categorized as low, an Issue should be created in the appropriate GitHub repo or project management tool and assigned to the appropriate TTS Tech Portfolio Lead to prioritize further.

For vulnerabilities of medium, high, or incident, an issue must be filed in the private security incident repository and assigned to the appropriate TTS Tech Portfolio Lead.

Regardless of where the issue is filed, the first responder should advise the TTS Tech Portfolio Lead on next steps.

The first responder is responsible for closing out the GitHub issue once they are satisfied that the issue has been resolved (whether remediated or marked wont fix or false positive).

The first responder will communicate directly with the TTS Tech Portfolio Lead, who is responsible for communication with the system’s engineering team throughout the remediation lifecycle.

3. Respond to reporter

If the report is n/a, send the appropriate message:

Otherwise, after filing the issue as described above:

  1. Quickly send an acknowledgement.
  2. Loop in any relevant program staff on the acknowledgement response, so they have a direct line of communication.
  3. Ensure an alert is set so that we get pinged well before the 90-day mark, at which point our request for confidentiality will expire.

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 infrastructure leads. They assume responsibility for further communication and resolving the issue.

The last thing you should do is set an email alert via Google Calendar at the 77-day (11 weeks) mark from the date the reporter sent the email, so that, if no response or resolution has yet been made, the team has about 2 weeks to bring the issue to resolution and close out the issue with the reporter.

4. Remediate

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).

For systems owned by partner agencies or 3rd-party vendors

Notifications to partner agencies or vendors should do the following:

  1. Briefly describe the vulnerability
  2. Describe the potential harm
  3. Recommend a course of action

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.