question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Update Third-party Triage Process Documentation

See original GitHub issue

What 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 the Triage they are: Acceptance, Rejection, and Need more information. The Common Response templates in HackerOne are acknowledge the report, acknowledge the report + triage and Duplicate. The responses in the process outline should match with the Common 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 asserts If 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 the Triage section does.
  • The Publication process documentation section contradicts the Correction follow-up sections assertion that With 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 that If 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 the Publication section is broken.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:5 (5 by maintainers)

github_iconTop GitHub Comments

2reactions
ronperriscommented, Mar 1, 2019

@sam-github Yep, working on that list!

1reaction
lirantalcommented, Mar 2, 2019

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 😃

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found