General Services Administration Bug Bounty Program

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

Security researchers should feel comfortable reporting vulnerabilities discovered, as defined in this policy, to afford GSA the opportunity to remediate the findings for the purpose of ensuring confidentiality, so we can fix them and keep our information safe.

The GSA looks forward to working with the security community to find vulnerabilities in order to keep our businesses and customers safe.

Philosophy

The GSA expects to evolve its structure over time and welcome feedback on areas for improvement. The following criteria guide our thinking:

• Common Practices: Wherever it makes sense, the GSA desires to learn from and follow industry common practices in bounty programs. We will deviate only when there is a clear and specific need.
• Competitive: We seek to provide competitive bounty amounts. Leveraging HackerOne platform data, new services will be introduced with median or higher reward levels and typically increase over time.
• Open: Our intent is for each service to be open to public participation. We will start with private programs only as a stepping stone toward a publicly available program.
• Responsive: The GSA is composed of many autonomous technical teams. Only teams that commit to and maintain positive levels of responsiveness to researchers will be included.

#Vulnerability Disclosure Policy Participation in this program is governed by the Vulnerability Disclosure Policy of the General Services Administration. Please fully review the linked policy prior to your participation.

Response Targets

GSA will make a best effort to meet the following SLAs for hackers participating in our program:

We’ll try to keep you informed about our progress throughout the process.

Disclosure Policy

• Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.
• Follow HackerOne's disclosure guidelines.

Program Rules

Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.

• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
• When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).
• Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
• Social engineering (e.g. phishing, vishing, smishing) is prohibited.
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.

Rewards

The bug bounty program of the General Services Administration is special in that it aims to cover numerous individual services that have been developed to address a diverse range of public use cases. Our strategy is to rotate services into scope at regular intervals. Our rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of GSA.

Exclusions and known issues

Our goal with this program is to fix issues with meaningful impact. Thus, we exclude certain types of issues because they have low (or no) security impact to us, and/or are known issues that we're comfortable with. These issues are unlikely to be eligible for an award, and will usually be considered invalid for the purposes of our program:

When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug.

The following issues are considered out of scope:

• Violations of secure design principles that are not part of exploitable vulnerabilities.
• Clickjacking on pages with no sensitive actions.
• Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
• Logout CSRF
• Attacks requiring MITM or physical access to a user's device.
• Previously known vulnerable libraries without a working Proof of Concept.
• Comma Separated Values (CSV) injection without demonstrating a vulnerability.
• Missing best practices in SSL/TLS configuration.
• Any activity that could lead to the disruption of our service (DoS).
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
• Rate limiting or brute-force issues on non-authentication endpoints
• HTTP OPTIONS/TRACE methods enabled.
• Missing best practices in Content Security Policy.
• HTTP/TLS configuration issues without demonstrable impact, such as:
  • TLS configuration issues such as BEAST, BREACH, renegotiation attacks, insecure cipher suites, etc.
  • Missing HTTP security headers
  • Lack of Secure or HTTPOnly cookie flag.
  • Missing best practices in SSL/TLS configuration.
• Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
• Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]
• Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).
• Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.
• Tabnabbing
• Open redirect - unless an additional security impact can be demonstrated
• Issues that require unlikely user interaction
• Reports about missing rate limiting where other mitigations exist (for example, brute force attacks against login pages already protected by MFA).
• Username enumeration on login or forgot password pages.
• Overly broad permissions on editing wikis (or other non-software non-production areas) associated with our source code repositories.
• Use of a known-vulnerable library without evidence of exploitability Presence (or absence) of application/browser autocomplete or save-password flags.
• Lack of "security speedbumps" when leaving sites/applications.
• Non-sensitive information disclosure (i.e., server versions, software stack, etc) on error message pages, 404 pages, and so forth.

Scope

The General Services Administration is comprised of many autonomous technical teams operating multiple services. While the services below offer bounties, all others do not offer bounties. Please review this scope section carefully before proceeding. If you wish to be notified when additional services are introduced to scope, please click "Notify me of changes" at the bottom of this page.

1. cloud.gov Platform
   • Description: The core of cloud.gov is a Platform as a Service built specifically for government work. We are highly interested in vulnerabilities with an impact on the underlying platform or that lead to privilege escalation between customer environments. To get started, we recommend reviewing the cloud.gov overview, documentation, diagrams, and code repositories
   • Assets: cloud.gov, account.fr.cloud.gov, admin.fr.cloud.gov, alertmanager.fr.cloud.gov, api.fr.cloud.gov, ci.fr.cloud.gov, dashboard.fr.cloud.gov, diagrams.fr.cloud.gov, grafana.fr.cloud.gov, idp.fr.cloud.gov, login.fr.cloud.gov, logs.fr.cloud.gov, logs-platform.fr.cloud.gov, nessus.fr.cloud.gov, opslogin.fr.cloud.gov, prometheus.fr.cloud.gov, ssh.fr.cloud.gov, dashboard-beta.fr.cloud.gov
2. code.gov
   • Description: The Federal Source Code Policy is designed to support reuse and public access to custom-developed Federal source code. It requires new custom-developed source code developed specifically by or for the Federal Government to be made available for sharing and re-use across all Federal agencies. It also includes an Open Source Pilot Program that requires agencies to release at least 20% of new custom-developed Federal source code to the public.
   • Assets: *.code.gov
3. data.gov
   • Description: Data.gov is a rich resource for civic hackers, tech entrepreneurs, data scientists, and developers of all stripes. We are highly interested in vulnerabilities that may impact the integrity of any data, such as any issues with our Data Harvesting processes. As an open data platform, there is negligible confidential information hosted on data.gov.
   • Assets: www.data.gov, federation.data.gov, sdg.data.gov, labs.data.gov, catalog.data.gov, inventory.data.gov, static.data.gov, admin-catalog-bsp.data.gov, GSA/data.gov, GSA/datagov-deploy
4. api.data.gov
   • Description: api.data.gov is a free API management service for federal agencies. Our aim is to make it easier for agencies to release and manage APIs.
   • Assets: api.data.gov
5. cloud.gov Pages (formerly Federalist)
   • Description: cloud.gov Pages is an open source static site web publishing service for the United States federal government. We are highly interested in vulnerabilities that impact the integrity of production content or enable a malicious user to impact sites outside of their granted permissions. To get started, we recommend reading the main Pages document and the instructions on Running Federalist Locally. The site at https://cloud.gov itself is a sample deployment of Pages.
   • Assets: federalist.18f.gov, federalist-proxy.app.cloud.gov, cloud-gov/pages-core, cloud-gov/pages-builder,cloud-gov/pages-proxy,cloud-gov/pages-build-container
6. fedramp.gov
   • Description: The Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. FedRAMP enables Agencies to rapidly adapt from old, insecure legacy IT to mission-enabling, secure, and cost effective cloud-based IT.
   • Assets: www.fedramp.gov, marketplace.fedramp.gov
7. login.gov
   • Description: login.gov is a single sign-on service offering the public secure and private access to participating government programs. We welcome external review of our privacy-protection measures. Our main application code is available for public inspection in an open-source repository. Our goal: make sure that at every step users know their privacy is being protected by design. Our developer documentation is a great place to get started. NOTE: If you encounter Personally Identifiable Information (PII) during your testing, please STOP and notify us immediately.
   • Assets: *.login.gov, https://github.com/18F/identity-idp,https://github.com/18F/identity-saml-sinatra, https://github.com/18F/identity-saml-rails
8. search.gov
   • Description: Powering over 2,000 search boxes on Federal websites. Check out the Help Manual to get started learning about this service.
   • Assets: *.search.gov *.search.usa.gov
9. Vulnerability Disclosure
   • Description: While only the assets listed above are eligible for bounties, we welcome disclosures of vulnerabilities in wider set of assets through our Vulnerability Disclosure Policy. The full set of assets in scope for disclosure are listed below, and in our Vulnerability Disclosure Policy.
   • Bounty Tier: Not Eligible
   • Assets: Please see our Vulnerability Disclosure Policy for the full list of assets covered by this policy.

Note: "subdomain hijacking" (taking control of a subdomain that was otherwise unused, such as by taking advantage of a dangling CNAME to a third party service provider) is in-scope for bounty awards, when the affected hostnames are within the second-level domains that appear in our in-scope list. These reports will always be considered low-severity unless there is further demonstrated impact.

Any out of scope submissions may be re-routed to the GSA Vulnerability Disclosure Program.

Eligibility

If you submit a qualifying, validated vulnerability, you may be eligible to receive a bounty award subject to the terms below:

• While we welcome the submission of any vulnerability that impacts in-scope services, we may not be able to award a bounty for submissions where the root-cause vulnerability was introduced by an upstream library or a third party SaaS / PaaS / IaaS system.
• You are not currently nor have been an employee or contractor of the U.S. General Services Administration (GSA) within 12 months prior to submission
• You are not a family or household member of an employee or contractor of the U.S. General Services Administration (GSA) as described above
• You must meet all HackerOne Bug Bounty eligibility requirements, such as not being subject to trade restrictions or export sanctions as determined by the U.S. Office of Foreign Assets Control (OFAC).
• If you are a federal employee, you are reminded that you may be required to seek approval from your supervisor and/or ethics office for any outside positions or compensation.
• If you are a current federal employee or the spouse or dependent child of a federal employee, you are reminded that Federal Employees are covered by the Standards of Ethical Conduct for Employees of the Executive Branch. 5 CFR Section 2635. Included in these restrictions is the prohibition against use of nonpublic information for personal gain.
• If you are an employee of a federal contractor or subcontractor, you are reminded that information you receive in your employment is for your use in your employment. You may be prohibited from disclosing that information by a Non-Disclosure Agreement.

Thank you for helping keep GSA and our users safe!