This is a copy of the vulnerability disclosure policy for 18F and the Technology Transformation Service (TTS). The official document lives in GitHub. If you would like to comment or suggest a change to the policy, please open a GitHub issue.

Vulnerability disclosure policy

As part of a U.S. government agency, the General Services Administration (GSA)'s Technology Transformation Service (TTS) takes seriously our responsibility to protect the public's information, including financial and personal information, from unwarranted disclosure.

We want security researchers to feel comfortable reporting vulnerabilities they've discovered, as set out in this policy, so that we can fix them and keep our information safe.

This policy describes what systems and types of research are covered under this policy, how to send us vulnerability reports, and how long we ask security researchers to wait before publicly disclosing vulnerabilities.

Guidelines

We require that you:

  • Make every effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction or manipulation of data.

  • Only use exploits to the extent necessary to confirm a vulnerability. Do not use an exploit to compromise or exfiltrate data, establish command line access and/or persistence, or use the exploit to "pivot" to other systems. Once you've established that a vulnerability exists, or encountered any of the sensitive data outlined below, you must stop your test and notify us immediately.

  • Keep confidential any information about discovered vulnerabilities for 90 calendar days after you have notified us.

Scope

This policy applies to the following systems:

  • cloud.gov and the following subdomains: account.fr.cloud.gov, api.fr.cloud.gov, ci.fr.cloud.gov, community.fr.cloud.gov, dashboard.fr.cloud.gov, login.fr.cloud.gov, logs.fr.cloud.gov, metrics.fr.cloud.gov. Any other subdomain of cloud.gov and all customer applications are excluded from this policy.
  • login.gov and the following subdomains: demo.login.gov, int.login.gov, dev.login.gov, qa.login.gov, pt.login.gov, staging.login.gov, dm.login.gov, prod.login.gov, dashboard.demo.login.gov, dashboard.qa.login.gov, dashboard.dev.login.gov. Any other subdomain of login.gov is excluded from this policy.
  • vote.gov
  • analytics.usa.gov
  • calc.gsa.gov
  • micropurchase.18f.gov
  • 18f.gsa.gov

Any services not expressly listed above, such as any connected services, are excluded from scope and are not authorized for testing. Additionally, vulnerabilities found in non-federal systems from our vendors fall outside of this policy's scope and should be reported directly to the vendor according to their disclosure policy (if any). If you aren't sure whether a system or endpoint is in scope or not, contact us at tts-vulnerability-reports@gsa.gov before starting your research.

The following test types are not authorized:

  • User interface bugs or typos.
  • Network denial of service (DoS or DDoS) tests.
  • Physical testing (e.g. office access, open doors, tailgating), social engineering (e.g. phishing, vishing), or any other non-technical vulnerability testing.

If you encounter any of the below on our systems while testing within the scope of this policy, stop your test and notify us at tts-vulnerability-reports@gsa.gov immediately:

  • Personally identifiable information
  • Financial information (e.g. credit card or bank account numbers)
  • Proprietary information or trade secrets of companies of any party

Authorization

If you make a good faith effort to comply with this policy during your security research, we will consider your research to be authorized, will work with you to understand and resolve the issue quickly, and GSA will not initiate or recommend legal action related to your research.

Reporting a vulnerability

We accept and discuss vulnerability reports at tts-vulnerability-reports@gsa.gov or through this reporting form. (GSA uses Google Apps internally, so either contact method will go into the same system.) Reports may be submitted anonymously. Note: We do not support PGP-encrypted emails. For particularly sensitive information, use the TLS-encrypted web form.

Reports should include:

  • Description of the location and potential impact of the vulnerability.
  • A detailed description of the steps required to reproduce the vulnerability. Proof of concept (POC) scripts, screenshots, and screen captures are all helpful. Please use extreme care to properly label and protect any exploit code.
  • Any technical information and related materials we would need to reproduce the issue.

Please keep your vulnerability reports current by sending us any new information as it becomes available.

We may share your vulnerability reports with US-CERT, as well as any affected vendors or open source projects.