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. File an issue
  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.

File an issue

For vulnerabilities categorized as low, an Issue should be created in the corresponding GitHub repo or project management tool for the affected system by the product or service team.

For vulnerabilities of medium or high issue must be filed in the private repository. If the issue is also an incident, it must be filed security incident repository.

The first responder is responsible for following up GitHub issue to assure they are satisfied that the issue has been resolved (whether remediated or marked wont fix or false positive).

The TTS Tech Portfolio should be included in all issues for tracking purposes.

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

Reply to the reporter

If the report impact is none, 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.

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.

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

Notifications to partner agencies should do the following:

  1. Find a POC

    i. Using the list of security contacts

    ii. Reach out through professional network

  2. Describe the potential harm
  3. Recommend a course of action

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

Notifications to vendors should do the following:

  1. Look for security@[] or VDP form
  2. Describe the potential harm
  3. Recommend a course of action