Collaborating with HackerOne Reviewers
Last updated
Last updated
The experts conducting security risk validation and code review are all members of our . They're software engineers with 5+ years of application security / engineering experience who are all thoroughly vetted and notably experienced in peer code review for pull/merge requests. Many are maintainers or core contributors of major languages, frameworks, and libraries.
All inline comments posted to pull or merge request are written by people - members of the Reviewer Network. A display name and avadar will be shown on these so you can distinguish between reviewers and know who you're working with over time (see below).
When a pull or merge request is assigned to a reviewer or team of reviewers based on possible risks detected, they'll typically be assigned to it until it is merged, closed, or network review is canceled.
After review feedback is posted, our reviewers can revisit it to answer your questions and review follow-up change commits.
The Reviewer platform tools are like an in-browser IDE built specifically for reviewing code. The files and changes are represented very similarly to how they'd be seen in a Git provider, but there are additional tools for gaining context - like searching the entire repository to examine relevant files that aren't part of the change set.
HackerOne reviewers have access to:
The pull/merge request diff and the contents of the files involved.
Metadata including the pull/merge request title, description, author username, branch names, event timestamps, and commit history.
Your repository's README.md file.
Any dependency management files such as package.json belonging to the repository.
These are referenced so reviewers can provide recommendations based on things like the version of a framework being used.
Any project-level notes provided by your organization, HackerOne staff, and other members of the Reviewer network who have worked with your team on prior pull/merge requests.
Reviewers DO NOT have access to any external resources that are not publicly accessible. Examples of things reviewers do not have access to include:
Other pull requests or issues in a private GitHub repository.
Project management tool links such as Jira tickets.
CI/CD tools such as CircleCI or Jenkins.
Any of your team's internal documentation that requires user login.
An IDE and your full repository.(Reviewers are not a custom configured IDE but can give you pointers on how to properly set yours for style)
The ability to commit their own corrections to your pull request.(Unless you are an OSS customer but this is generally not expected).
Just like for members of any development team reviewing teammates' code, a thorough description of the change, the intent of the changes, and any other relevant information will help reviewers provide great feedback and suggestions.
This includes screenshots, however these are only supported for Github Repositories!
The platform notifies reviewers whenever important updates are made. These include:
Comments that you've posted that require their attention.
New commits are pushed to address feedback.
When you request the changes are reviewed again.
HackerOne reviewers will receive a notification that they've been mentioned in a comment in several ways.
If you reply to a reviewer in an inline thread, any reviewer that participated in the thread will be notified.
If you post a comment that includes the reviewer's display name or string pullrequest (all one word, case insensitive) reviewers will be notified of your comment.
NOTE: To be notified by display name, the reviewer will need to be already assigned to the code review.
When you push additional commits to a pull or merge request branch that "outdate" comments posted by reviewers, they'll receive a notification that you've made a change that likely addressed one of their comments and that they should circle back and verify the new state.
After at least one feedback submission has been posted to your pull or merge request by reviewers in the network, you can send a notification to any reviewers assigned asking to re-review the changes.
This is useful if you've updated the branch to include additional changes that would otherwise not alert reviewers.
NOTE: We strongly recommend adding a comment to the pull or merge request, or update the description, letting reviewers know why you've sent this notification.
You can do this by accessing the and clicking the Notify reviewers of updates link.
Read more about code review statuses
