increasing the clarity on the vulnerability reporting process #1736
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
quinnkeast
reviewed
Oct 8, 2020
Co-authored-by: Quinn Keast <qkeast@sourcegraph.com>
|
Notifying subscribers in CODENOTIFY files for diff 37fd5a6...499d569.
|
ElizabethStirling
approved these changes
Oct 8, 2020
nicksnyder
reviewed
Oct 8, 2020
There was a problem hiding this comment.
Update dead link to this page: https://sourcegraph.com/search?q=r:sourcegraph/about+how+to+report&patternType=literal&utm_source=omnibox
| | Type of Response | Time to Response | | ||
| | :------------- | :----------: | | ||
| | First Response| 2 days | | ||
| | Time to Triage | 10 days | |
There was a problem hiding this comment.
I don't think it is clear to the reader what "triage" means.
|
|
||
| ## How we respond to security vulnerability reports | ||
|
|
||
| When we receive [a report of a security vulnerability](#how-to-report-a-security-vulnerability), a member of our security team determines if a reported vulnerability should be investigated by an engineer. |
There was a problem hiding this comment.
This self-referential link is dead.
|
|
||
| We will send payment to a valid PayPal account. We will ask you for the name and country associated with your PayPal account. | ||
|
|
||
| **Timelines** |
There was a problem hiding this comment.
In the first section you say we respond within 2 US business days, but it is unclear in this table whether these are also all US business days.
Co-authored-by: Nick Snyder <nick@sourcegraph.com>
Co-authored-by: Nick Snyder <nick@sourcegraph.com>
Co-authored-by: Nick Snyder <nick@sourcegraph.com>
Co-authored-by: Nick Snyder <nick@sourcegraph.com>
quinnkeast
approved these changes
Oct 13, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Our vulnerability reporting process is reasonably clear, but the guidelines for getting a higher value vulnerability report need some tweaking. I felt that:
Vulnerability reporting really does deserve it's own top-level page, like other organizations.
The 1 day (to respond) timeline is far too quick - and having now viewed several other organization, I have data on that. The result is a table containing expectations as a response - an experiment to see if others find it easier to understand (as I do).
We ought clarify what constitutes a higher quality vulnerability report.
Please provide comments, I'd like to turn this into a higher value page, as I think it can help us get down the path to higher value vulnerabilities. Finally, I validated our amounts with the few organizations I found possible. Paypal and Github have maximums of $30K. This, along with our existing bounty pay outs lead me to feel that our existing amount is well positioned given our size and scale as a result.