├── .github └── ISSUE_TEMPLATE │ └── general.md ├── .gitignore ├── CONTRIBUTING.md ├── ISSUE_TEMPLATE.md ├── LICENSE.md ├── README.md ├── canned-responses.md └── project-instructions.md /.github/ISSUE_TEMPLATE/general.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: General 3 | about: For general Tech Portfolio work 4 | title: "" 5 | labels: "g: initial" 6 | assignees: "" 7 | --- 8 | 9 | ## Background Information 10 | 11 | 12 | 13 | ## Implementation Steps 14 | 15 | 16 | 17 | - [ ] 18 | 19 | ## Acceptance Criteria 20 | 21 | 22 | 23 | - [ ] 24 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.pyc 2 | .cache 3 | .coverage 4 | .env 5 | .tox 6 | __pycache__ 7 | htmlcov/ 8 | staticfiles -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | ## Welcome! 2 | 3 | We're so glad you're thinking about contributing to an 18F open source project! If you're unsure about anything, just ask -- or submit the issue or pull request anyway. The worst that can happen is you'll be politely asked to change something. We love all friendly contributions. 4 | 5 | We want to ensure a welcoming environment for all of our projects. Our staff follow the [18F Code of Conduct](https://github.com/18F/code-of-conduct/blob/master/code-of-conduct.md) and all contributors should do the same. 6 | 7 | We encourage you to read this project's CONTRIBUTING policy (you are here), its [LICENSE](LICENSE.md), and its [README](README.md). 8 | 9 | If you have any questions or want to read more, check out the [18F Open Source Policy GitHub repository]( https://github.com/18f/open-source-policy), or just [shoot us an email](mailto:18f@gsa.gov). 10 | 11 | ## How to run tests 12 | 13 | ```bash 14 | $ pip install tox 15 | $ tox 16 | ``` 17 | 18 | ## Public domain 19 | 20 | This project is in the public domain within the United States, and 21 | copyright and related rights in the work worldwide are waived through 22 | the [CC0 1.0 Universal public domain dedication](https://creativecommons.org/publicdomain/zero/1.0/). 23 | 24 | All contributions to this project will be released under the CC0 25 | dedication. By submitting a pull request, you are agreeing to comply 26 | with this waiver of copyright interest. 27 | -------------------------------------------------------------------------------- /ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | **PLEASE DO NOT REPORT SECURITY ISSUES HERE!** 2 | 3 | This repo is for documents and policies related to TTS's bug bounty, not a place to report security issues. 4 | 5 | If you think you've found a vulnerability, please see our vulnerability disclosure policy for information on how to report issues: https://18f.gsa.gov/vulnerability-disclosure-policy/. 6 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | As a work of the United States Government, this project is in the 2 | public domain within the United States. 3 | 4 | Additionally, we waive copyright and related rights in the work 5 | worldwide through the CC0 1.0 Universal public domain dedication. 6 | 7 | ## CC0 1.0 Universal Summary 8 | 9 | This is a human-readable summary of the [Legal Code (read the full text)](https://creativecommons.org/publicdomain/zero/1.0/legalcode). 10 | 11 | ### No Copyright 12 | 13 | The person who associated a work with this deed has dedicated the work to 14 | the public domain by waiving all of his or her rights to the work worldwide 15 | under copyright law, including all related and neighboring rights, to the 16 | extent allowed by law. 17 | 18 | You can copy, modify, distribute and perform the work, even for commercial 19 | purposes, all without asking permission. 20 | 21 | ### Other Information 22 | 23 | In no way are the patent or trademark rights of any person affected by CC0, 24 | nor are the rights that other persons may have in the work or in how the 25 | work is used, such as publicity or privacy rights. 26 | 27 | Unless expressly stated otherwise, the person who associated a work with 28 | this deed makes no warranties about the work, and disclaims liability for 29 | all uses of the work, to the fullest extent permitted by applicable law. 30 | When using or citing the work, you should not imply endorsement by the 31 | author or the affirmer. 32 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # TTS Bug Bounty internal documentation 2 | 3 | Internal documentation for TTS's bug bounty. 4 | 5 | **Please [report bugs over on HackerOne](https://hackerone.com/tts); not in this repository!** This repo is for policy docs only. 6 | 7 | ### Public domain 8 | 9 | This project is in the worldwide [public domain](LICENSE.md). As stated in [CONTRIBUTING](CONTRIBUTING.md): 10 | 11 | > This project is in the public domain within the United States, and copyright and related rights in the work worldwide are waived through the [CC0 1.0 Universal public domain dedication](https://creativecommons.org/publicdomain/zero/1.0/). 12 | > 13 | > All contributions to this project will be released under the CC0 dedication. By submitting a pull request, you are agreeing to comply with this waiver of copyright interest. 14 | -------------------------------------------------------------------------------- /canned-responses.md: -------------------------------------------------------------------------------- 1 | # Canned responses to certain kinds of vuln reports 2 | 3 | ## cloud.gov customer apps 4 | 5 | ``` 6 | Hi {reporter}, 7 | 8 | Thanks for reporting this vulnerability to us! 9 | 10 | However, this is a customer application, and falls outside of the scope of our 11 | vulnerability disclosure program as described at 12 | https://18f.gsa.gov/vulnerability-disclosure-policy/. The scope for cloud.gov 13 | is described as: 14 | 15 | cloud.gov and the following subdomains: account.fr.cloud.gov, 16 | api.fr.cloud.gov, ci.fr.cloud.gov, community.fr.cloud.gov, 17 | dashboard.fr.cloud.gov, login.fr.cloud.gov, logs.fr.cloud.gov, 18 | metrics.fr.cloud.gov. Any other subdomain of cloud.gov and all 19 | customer applications are excluded from this policy. 20 | 21 | The domain you reported, {domain}, is outside of this scope. 22 | 23 | We'll do our best to contact the customer and pass your report on to them, but 24 | we can't guarantee anything about their response. 25 | 26 | Thanks again, we really appreciate your work and your report! 27 | 28 | {signature} 29 | ``` 30 | 31 | ## Out of scope 32 | 33 | ``` 34 | Thanks for your report, we appreciate your effort. 35 | 36 | However, this domain isn't in scope for Vulnerability Disclosure Policy (see https://hackerone.com/tts, and https://github.com/18F/vulnerability-disclosure-policy/blob/main/vulnerability-disclosure-policy.md). In the future, please limit your testing to domains explicitly listed in that scope. This is for your own safety: we want to be sure that everyone's on the same page about your activities being authorized. 37 | 38 | If possible, we'll make an effort to pass this on to the appropriate parties, but we can't guarantee any further follow-up. 39 | ``` 40 | -------------------------------------------------------------------------------- /project-instructions.md: -------------------------------------------------------------------------------- 1 | # Your Project's Bug Bounty 2 | 3 | Want to have a bug bounty for your project? This document outlines the 4 | instructions and requirement for joining. 5 | 6 | We aim for our bug bounties to be a win for everyone involved: the project, the 7 | researchers, and everyone that depends on our software. This means we have some 8 | rules designed to set you up for success. 9 | 10 | Please note that at the moment, we only have space in the program for **five** 11 | apps. So we may need to turn down some qualified programs. Sorry! 12 | 13 | ### How we'll prioritize among potential participants 14 | 15 | If we get more than five interested programs, we'll select for more mature 16 | programs. Our partner, HackerOne, has [a maturity model for vulnerability 17 | coordination](https://www.hackerone.com/blog/vulnerability-coordination-maturity-model) 18 | that we'll use to define "mature" for these purposes. It may be worth reviewing 19 | this model and thinking about where you fit in. 20 | 21 | ### Requirements To Join 22 | 23 | To guarantee that your project's participation in the bug bounty program is a 24 | success, we expect you to be willing to have: 25 | 26 | * **Dedicated staff**, on a possibly rotating basis, to responding to vulnerability 27 | reports and fixing reported issues. The staff need not be security experts, but 28 | for availability, you must have two or more staff dedicated to responding and 29 | they must be reachable through 30 | [#bug-bounty-partners](https://gsa-tts.slack.com/messages/C5JQCD9PH). 31 | 32 | * **A private GitHub repo for tracking vulnerability reports to resolution.** It 33 | could be an [issues-only repo](https://help.github.com/articles/creating-an-issues-only-repository/), or a full code repository, *but it must be private.* You may use the [security-incidents](https://github.com/18F/security-incidents) 34 | repo if you don't have a project-specific one. 35 | We'll ask you to track both individual vulnerabilities *and* more general 36 | vulnerability classes -- for example a reported cross-site scripting 37 | vulnerability must also generate a separate issue to find and fix all other 38 | related cross-site scripting vulnerabilities, and when found must also be 39 | tracked separately. 40 | 41 | * **Methods to inform parties impacted by a reported vulnerability**, which will 42 | depend on the nature of your project. For example, if your project is an 43 | interactive service, this could be a notice on the front page; if your project 44 | is a code library, this could be an update to the release notes. If your 45 | project features both or more, you must be able to inform each of your 46 | audiences. 47 | 48 | * Automated development practices that mitigate common classes of 49 | vulnerabilities. For example, for web apps, your project should a framework that 50 | automatically escapes output so that input doesn't have to be manually escaped. 51 | In other words, we'll want you to be confident that you've already covered 52 | the "low hanging fruit". 53 | 54 | * **Be listed in in the [18F Vulnerability Disclosure 55 | Policy](https://github.com/18F/vulnerability-disclosure-policy/blob/main/vulnerability-disclosure-policy.md)**. We can add you as part of your 56 | onboarding to the program, but you'll need to be OK to be listed. Note that 57 | this probably rules out any apps developed for partners, since we can't 58 | unilaterally take vulnerability reports for other agencies. 59 | 60 | * **Sufficient funding and staffing for at least three months** (and preferably 61 | nine months) of participation in the program. We want you to be able to 62 | guarantee you can fix any reported issues! 63 | 64 | * **Be comfortable with a fully-public bounty.** Our intent is for these bounties 65 | to be fully-public (that is, open to any researcher on HackerOne's platform). 66 | If you want, we can _start_ with a private, invite-only bounty (where 67 | HackerOne selects and invites a few highly-qualified researchers), but only 68 | as a stepping stone towards a fully-public bounty. 69 | 70 | In a nutshell, projects will have bugs reported to them, and their ability to 71 | deal with them gracefully will be the key to success. 72 | 73 | Your project needs to be mature enough to address any reported issues in a 74 | reasonable amount of time, and to ensure that it isn't having the same kind of 75 | issues reported over time. 18F's Bug Bounty Team is here to provide assistance, 76 | but not oversight! Your project will own all the responsibilities, from making 77 | sure the reports get a response, to making sure the incentives are properly 78 | aligned. 79 | 80 | ### SLAs Your Program Must Meet 81 | 82 | Projects that participate in the bug bounty program inherit an SLA: **Issues must 83 | be resolved within 90 (calendar) days of being reported.** 84 | 85 | Ideally "resolved" means "fixed" but note that "resolved" for the purposes of 86 | the bug bounty program could mean something else. For example, vulnerabilities 87 | that you determine will not be fixed within 90 days can be resolved by paying 88 | the reporter and communicating your plan. Also, note that bug bounty resolution 89 | is entirely separate from any federal policy and compliance with one does not 90 | confer compliance with the other. 91 | 92 | If you miss this SLA, that'll prompt a review of the SLA and your involvement 93 | with the bug bounty team. This review will do a few things: 94 | 95 | 1. Review this 90-day SLA with you and make sure that it is still aligned with 96 | everyone's goals. It is entirely possible that it might not be. The real 97 | world is complicated; the SLA may be an over-simplification. 98 | 99 | 2. Conduct a retrospective with the team that missed the SLA to determine if 100 | the reason for missing the SLA and how to avoid it in the future. If we can't 101 | make changes to meet the SLA in the future, then participation in the bug 102 | bounty would be put on hold. 103 | 104 | The Bug Bounty Team will notify you about unresolved reports on every half-life 105 | (i.e. Day 45, 22, 11, 5, 3, 2, and 1) to help you track issues as they get 106 | closer to the SLA. 107 | 108 | #### Suggested timelines 109 | 110 | Though the 90-day SLA above is the only _required_ timeline, we do (strongly) 111 | suggest that your program aims for faster remediation of more severe issues: 112 | 113 | * High severity: within 7 days 114 | * Medium severity: within 30 days 115 | 116 | If you miss these timelines, it should prompt you to deliver an update to 117 | stakeholders and to review the issue and decide whether it is appropriately 118 | ranked. If you consistently can't meet these timelines, that should prompt 119 | a conversation with the bug bounty team about why this is happening. 120 | 121 | #### Your Project's Participation 122 | 123 | Regardless of what level of maturity your project has, you can expect the 124 | following tasks to come your way: 125 | 126 | * __Validation__: As issues are reported, you'll need to review the reports to 127 | validate them. HackerOne will be performing initial triage to reproduce the 128 | issue and assign a severity. While they strive for accuracy, you know your 129 | application best and you play a critical role in the final validation of the issue. 130 | Some may contain all the information you need, others may be lacking and require 131 | follow-up. Some will be serious, others may be invalid. Some of the serious 132 | ones may qualify as a [security 133 | incident](https://handbook.18f.gov/security-incidents/). Sometimes you may see 134 | duplicates, serious or invalid. In any case, we recommend you validate issues 135 | within a week, if not daily. Validation is complete when you have enough 136 | information from the reporter to implement a fix and assign it a priority, or 137 | enough information to dismiss it as not a bug. 138 | 139 | * __Tracking__: Once you've qualified a report as a vulnerability, you'll 140 | need to track it to its conclusion. This is especially important for 141 | lower-risk vulnerabilities as they are at high risk of not being prioritized 142 | above other work. Tracking is complete when you have a permanent, searchable 143 | record of the decisions that were made leading up to the resolution, deferral, 144 | or acceptance of the bug. 145 | 146 | * __Communication__: Reporters expect updates on the issues they've 147 | reported. Usually, nothing more at the beginning than "thanks we got it, expect a 148 | fix $whenever", and then "ok it's fixed!" at the end. If something changes 149 | while the vulnerability is still open, though, you should communicate that to 150 | the reporter. You may also have to communicate with customers, partners, and 151 | others depending on the scope of the bug. Communication is complete once all 152 | of the impacted parties have been informed of the steps you've taken to resolve 153 | the bug, and any additional steps they may need to take in response. 154 | 155 | #### Time Commitment And Billing 156 | 157 | Time spent on those bug bounty tasks should be Tocked as `411 - TTS Acq / Customer Acq / Bug Bounty`, 158 | but time spent on actually resolving the issues should be Tocked to the project 159 | itself. In other words: if you're doing work that you would have done if 160 | _your team_ had discovered the bug, Tock it to your own project as usual. 161 | But if it's work you have to do specifically because the bounty program found 162 | the bug, Tock it to Bug Bounty. 163 | 164 | Expect to spend on the order of 4-8 hours a week on bounty management 165 | tasks. If at any point you're spending more, that might indicate something is 166 | wrong and you should let the bug bounty team know. 167 | 168 | ## Ready To Participate? 169 | 170 | **Yay!** Contact us in [`#bug-bounty`](https://gsa-tts.slack.com/messages/bug-bounty/) to start the conversation! 171 | --------------------------------------------------------------------------------