Update Third-party Triage Process Documentation
See original GitHub issueWhat I expected
The steps for triage should be clear and in alignment with the settings in HackerOne.
What I experienced
- HackerOne requires a
Change State
>Triaged
action to be take in 2 business days, this step is not documented in the process. - The process outlines three possible
responses
during theTriage
they are:Acceptance
,Rejection
, andNeed more information
. TheCommon Response
templates in HackerOne areacknowledge the report
,acknowledge the report + triage
andDuplicate
. Theresponses
in the process outline should match with theCommon Responses
in HackerOne. - The process requires the asset field to be set by the team member triaging the vulnerability. This not currently possible in most cases because only 2 out of 11 team members currently have the
Program
permission enabled in their accounts in HackerOne. - The process document references a missing article on
How do I triage a report?
. - The
Correction follow-up
process documentation section incorrectly asserts that vulnerabilities will be made public if and only if the maintainers are unreachable. The program documentation on HackerOne assertsIf no fix is available after 45 days, the advisory will timeout and will be made publicly available.
. - The
Correction follow-up
process documentation section incorrectly asserts that the package maintainer can choose a release date for the publication of the vulnerability report and that the vulnerability will not be disclosed automatically after 45 days. This is not consistent with the documentation on the HackerOne program page. - The
Correction follow-up
process documentation section should state which fields need updating, just like theTriage
section does. - The
Publication
process documentation section contradicts theCorrection follow-up
sections assertion thatWith the package maintainer, they define a release date for the publication of the vulnerability. Ideally, this release date should not happen before the package has been patched.
when it states,Within 45 days after the triage date, the vulnerability must be made public.
- The link to the CVSS v.3 documentation is broken in the
Publication
section. - The
Publication
section contradicts the HackerOne program documentation when it asserts thatIf a patch is being actively developed by the package maintainer, an additional delay can be added with the approval of the triage team and the individual who reported the vulnerability (this is a simple vote where each member of the triage team and the vulnerability reporter have 1 vote each).
- The CVE request email is a broken link in the
Publication
section. - The
HackerOne: How does public disclosure work?
link in thePublication
section is broken.
Issue Analytics
- State:
- Created 5 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
How to set up a Bug Triage Process? - BrowserStack
Understand how and why every software company needs to have a bug triage process for finding anomalies in the product or service offerings....
Read more >Triage a self-identified issue
After an issue has been identified and submitted by employees or business users via the Service Portal, the issue triage process begins.
Read more >Bug triage - Moodle Developer Resources
The triage process should help ensure that we appropriately manage all reported issues - bugs as well as improvements and feature requests.
Read more >HITRUST ThirdYParty Risk Management (TPRM) Methodology
This document outlines HITRUST's TPRM Qualification Methodology, ... Risk Triage (RT) – The third party is classified or tiered according to the level...
Read more >Bug triage - MoodleDocs
Bug triage is a process where tracker issues are screened and prioritised. Triage should help ensure we appropriately manage all reported ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@sam-github Yep, working on that list!
Always great to have fresh eyes on our processes, good stuff! Perhaps it’s worth to handle each of them in a separate PR/issue so we can have focused discussions, otherwise it is easy to derail 😃