18F / bug-bounty

OUT OF DATE: Internal documentation for TTS's bug bounty.
https://github.com/18F/tts-tech-portfolio/issues/49
Other
9 stars 5 forks source link

Adds suggested SLAs for high/med/low issues #20

Closed jacobian closed 7 years ago

alex commented 7 years ago

This may just be out of scope for a bug bounty, but if someone reports an issue that they believe to be actively exploited, should it be stated that it should be considered to be "high", even if the vulnerability itself would normally be classified at some other level?

(This is derived from Project Zero's rule around shorter disclosure timelines for actively exploited issues)

jacobian commented 7 years ago

@alex that's a good point, though probably out of scope for this doc. Though in scope for our own internal triage/validation process, which still needs to be written and published, so thanks :)

I think that's what @rice was getting at in #19 when he writes about some issues potentially being incidents: if something's being actively exploited, we'd view it as an official incident, which comes with its own requirements and would drive a higher SLA. Weather we should classify those bug reports as a higher-severity (and thus award them a higher bounty) is a super-interesting question, and something I want to think about more.

commit-dkp commented 7 years ago

Oh, never mind, forget issues are disabled on this repo! So then:

  1. What are the consequences of missing the required SLA?
  2. Do the recommended SLAs meet, exceed, or fall short of federal policy? If so, why?
  3. What should the consequences be for missing the recommended SLAs?
kimberbat commented 7 years ago

Worth noting that I started a triage process here that we can expand @jacobian - but out of scope for this issue. Just want to add the link for reference: https://handbook.18f.gov/responding-to-public-disclosure-vulnerabilities/