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
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.
- cloud.gov note: Response team members need to be on the cloud.gov whitelist for outside-of-business-hours email alerts. Each new response team member should tell the cloud.gov Product Lead, Director, or Deputy Director to add their email address to the whitelist.
The first responder monitors reports received from the public via emails to
email@example.com 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.
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.
- cloud.gov note: If the reported issue involves cloud.gov and is scored moderate or higher, the first responder must mention
@cg-teamin Slack and email
firstname.lastname@example.org, so the cloud.gov team can help determine impact and respond to incidents.
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
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:
- Not in scope: “Thanks for contacting us. However, this report falls outside of our scope as described at https://18f.gsa.gov/vulnerability-disclosure-policy/. [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.”
Otherwise, after filing the issue as described above:
- Quickly send an acknowledgement.
- Loop in any relevant program staff on the acknowledgement response, so they have a direct line of communication.
- 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 https://18f.gsa.gov/vulnerability-disclosure-policy/, 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.
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|
For systems owned by partner agencies or 3rd-party vendors
Notifications to partner agencies or vendors should do the following:
- Briefly describe the vulnerability
- Describe the potential harm
- 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.