# Reviewer Guides Below are guides for experts in the HackerOne Code community and are meant to facilitate clear expectations and tips for performing secure code review. Guides for Completing Reviews * [The basics of reviewing with PullRequest](https://docs.pullrequest.com/reviewing-with-pullrequest/) * [Security-Focused Reviewer Guide](https://docs.pullrequest.com/reviewer-documentation/security-focused-reviewer-guide/) * [Common Security Issues Found in Code Review](https://docs.pullrequest.com/reviewer-documentation/reviewing-for-security/) Guides for Using HackerOne PullRequest Interfaces: * [Accepting code reviews from Slack](https://docs.pullrequest.com/accepting-code-reviews-from-slack/) * [The Review Platform](https://docs.pullrequest.com/the-pullrequest-reviewer-platform/) * [Reviewer profile settings](https://docs.pullrequest.com/reviewer-display-name/) * [The PullRequest Reviewer Platform](https://docs.pullrequest.com/the-pullrequest-reviewer-tools/) Miscellaneous Guides: * [Reviewer Code of Conduct](https://docs.pullrequest.com/reviewer-documentation/reviewer-code-of-conduct/) * [Adding PullRequest as a Professional Experience](https://docs.pullrequest.com/reviewer-documentation/pullrequest-and-linkedin/) * [Reviewer Display Name](https://docs.pullrequest.com/reviewer-documentation/reviewer-display-name/) # Code Review Etiquette and Best Practices ## HackerOne Code Reviewer 101 HackerOne Code reviews will appear to the code author(s) as inline and pull/merge request summary comments - just like you would see from another team member**.** Think of yourself, the reviewer, as an extension of their development team at the code review level. In cases where you're reviewing for a new team or repository, **the best practice** **approach each code review as if you've recently taken professional ownership of the repository.** Be sure to thoroughly dive into the codebase with the tools you have available and take the time you need to provide a great review. Remember that HackerOne customers love the service because contributions from our community of engineers goes beyond things that are surface-level or "linter-like." Here are some code reviews that have been completed by our reviewers on public repositories: * [**ergo** by Ought Inc.](https://github.com/oughtinc/ergo/pull/61) * [**unity-cache-server** by Unity](https://github.com/Unity-Technologies/unity-cache-server/pull/36) * [**apps-android-commons** by Wikimedia Commons](https://github.com/commons-app/apps-android-commons/pull/2979) **Example:** ![](/files/itWGirRSVwvErkgbUbsa) ## How long will I be assigned a code review? Reviews remain assigned until the code changes the client has made are merged or closed. This provides an opportunity to maintain a dialog with the code author(s). If you come across a potential issue, but need a little more info, feel free to ask questions or for clarification. When asking questions for clarity, ensure that you provide a reason why you're curious. This can help reduce back and forth and time spent waiting for replies from our customer devs. **Example:**
The average length of time a code review remains active varies from team to team and the scope of the proposed code changes. This can be a few hours or even a few days. In some cases, a team's ability to merge will depend on the review. If that's the case, we'll let you know via prompt when you start working on it. ## What kinds of things should I be reviewing for? **Think of reviewing a customer's code as being brought in as a technical consultant.** We're highly selective of the engineers we admit into the network because reviewing code requires great judgment and extensive development career mileage. Our customers expect thorough review for high-impact items such as: security vulnerabilities and issues that can cause security vulnerabilities in the future if left unchanged (things like performance issues, opportunities to optimize performance, logical errors, architectural issues, etc.). Our highest priority is to find and report security vulnerabilities or risks found in the customer's source code before merge. As a general rule: it's always better to call attention to something that may be a concern than not. Review our guides on providing code review for security here: * [Security-Focused Reviewer Guide](https://docs.pullrequest.com/reviewer-documentation/security-focused-reviewer-guide/) * [Common Security Issues Found in Code Review](/reviewer-documentation/reviewing-for-security) **Examples:** ![](/files/-MACtC_UJpf5cz-7_rXQ) ![](/files/-MACuXOg-A9DeWVyDM9B) ![](/files/-MACuZWcQv-WzRULICfr) ## Handling context One of the biggest difference between reviewing code and what you're probably used to reviewing for your own team is that you won't have months of on-going familiarity and offline conversations about the codebase. We prioritize available pull requests to review based on reviews you've completed in the past, but from time-to-time, and at first, you'll be new to a codebase. HackerOne provides a number of tools to help fill in some of these gaps. You'll be able to access the entire repository by means of a code search tool, dependency manifests are always accessible as well as any README documentation, and we provide on-going notes for every organization and repository that are visible alongside the pull request description and title. Teams on the other side of the pull request understand that you don't have all of the context that they do, so **we encourage making thoughtful assumptions and prefacing that you can't confirm certain things**. Here's a good example: ![](/files/HhNPPkrES9B711D0YqBM) ## Submitting a great review Code reviews vary depending on a wide range of factors including a team's style of development, the complexity of the proposed changes, the code author's level of experience, the client's business goals, and many, many others. It's important to use good judgment with the context you have. Here are a few things we strongly encourage: * **Explain the "why" and your thought process** - Unless something is very obvious, it's a good practice to elaborate on why you've called attention to an issue. This will help the developers on the other side of the pull request understand your feedback. * **Be generous with code examples and links** - Add code snippets and links to sources when and wherever you can alongside issue descriptions.\ **Join existing conversations** - Other members of the organization may be involved in existing dialogs on a code review. If you have useful information to offer, feel free to join in! * **Follow up on changes** - Just like during any code review, it's important to check back up on changes that are made in follow-up commits. You'll be notified when updates are made and we strongly encourage posting a follow-up comment that you've looked at the latest commits - even if they contain no new issues. ## Things to AVOID in your reviews #### Reviews you submit through PullRequest should NOT be: * Limited to surface-level code and syntax. In almost all cases the code presented will successfully compile. Your review should focus on if there are more in-depth issues and to make sure the changes are *good*. * A "human linter." * Rushed in any way. Take your time and really dive in. There are a few things we ask our reviewers to *avoid*: * **Repeated pattern feedback and nit-picky "to-dos"** - While some nitpicks are important for maintainability, like having more descriptive variable names or keeping consistent whitespacing, a slew of inline comments addressing every instance makes for a code review that's hard to read. Depending on the review, these can often be addressed at a high level in a summary comment or leaving one inline comment with the line "ditto throughout." * **Framing feedback as a command** - Feedback that's not intended to be a terse command has a dangerous tendency to become perceived as such. Before submitting a review take the time to ensure you're erring on the side of gentleness. Framing a suggestion or feedback as a request accomplishes the same functional goal and is always better received. *(Example below)*
* **LGTM!** - While many code reviews won't contain any major items of concern, we encourage our reviewers to add high-level value when possible. The teams we work with look to PullRequest reviewers for guidance and an opportunity to learn and produce better code. This could be things like recommending a more robust or well-maintained library to replace one that's currently being used or calling attention to code that was executed particularly well (as mentioned above). * **Even if a code review is completely free of issues, your comments should clearly communicate that you've reviewed the change(s) thoroughly.**
![](/files/sevOsrCNDyol9ChzflWR) ## Remember to use your best judgment Always remember to put yourself in the position of the developer or team on the other end and consider what information you would find helpful if you were in their situation. If you ever have any questions always feel free or reach out directly to a PullRequest team member on Slack. # Security-Focused Review Guide ## Background HackerOne Code is a security-focused offering. This solution aims to address the growing need for developer-friendly security tools, providing on-demand security expertise to accelerate development cycles and reduce vulnerabilities before production. This enhances HackerOne's continuous vulnerability testing framework by adding a robust code review component, ensuring a more comprehensive security posture from development through production. **Note**: Some common security-related issues and some additional notes on reviewing for security can be found here: [Common Security Issues Found in Code Review](https://docs.pullrequest.com/reviewer-documentation/reviewing-for-security/). Basic code review best practices can also be found here: [Code Review Etiquette and Best Practices](/reviewer-documentation/reviewing-with-pullrequest) ### Customer Goals For our customers, keep these basic goals in mind: * Alert fatigue from noisy code scanners and AI. You, the humane in the loop, are an essential requirement for weeding through this noise and identifying only the concerns that matter, reducing the chance for false positives while also adding a layer of scrutiny before Merge. * You, the human expert in the loop, will give developers access to the security context they need to ship secure code, faster—without the false positives and bottlenecks. ### Reviewer Expectations In addition to the topics covered on [Code Review Etiquette and Best Practices](https://docs.pullrequest.com/reviewer-documentation/reviewing-with-pullrequest/) on how to provide a great experience for HackerOne's customers, please keep the following points in mind: * Keep feedback related to security concerns (these could be direct or indirect) * Raise feedback only on valid issues or bring attention to issues that could be valid, but require some clarification from the development team to determine validity * Focus on areas highlighted by our security automation and AI hot spots (See next section for more information on these), only raising issues that are valid (to the best of your ability based on context available) * Focus on other areas not highlighted by our automation that deserve additional scrutiny per your best judgement ## How to Complete a Security-Focused Review The reviewer interface for this type of review has been designed to ensure that reviewers are engaged have the tools you need to do the job more easily and with the right expectations. Completing a review can be done with the following three steps in mind. ### Step 1: Verify Automated Findings Review automated results raised by various automated Application Security Testing (AST) tools provided. The Automation Results Checklist enables you to skip directly to each automated security rule triggered.
For any automated results that are found to be invalid or false positives, please ignore them. Those that are found to be valid should be escalated using the **Convert to a comment** button. If you are unsure of the validity of an automated finding or you are missing some relevant context, raise the finding with a clarifying question and provide as much information as to why you think it could be a valid risk for the code author to consider.

SAST conversion example

Review any code specifically outlined in pink. Our AI hot spots engine attempts to find risky areas of code and highlights any sections of code to draw attention to them. Each finding highlighted in pink should come with an explainer about why the code was flagged and the ability to convert that explainer to a comment. As with other automated findings, the expectation should be to only raise issues related to verified risk using the power of human experts! To report any valid findings here, simply click the icon and edit the to ensure the feedback is accurate and helpful.

Converting an AI finding to an inline comment

In the end, you bring the subject matter expertise to review our customers' code. If you feel there are other areas that deserve additional scrutiny in a security context, we encourage going outside of the automation. In the end, this should be a **faster** and more **focused** review, but we still want to ensure that we are thorough as reporting risks in code is our highest priority task. ### Step 2: Submit the Review Once the review is complete, make sure to submit it using the Review button in the top right of the review window. Submitting a summary comment is optional. If something was discovered during the review, expand on that issue, it's potential impact, and the urgency of resolving that issue prior to merge (if any) in the summary comment before submitting your review.
### Step 3: Follow Up Reviews Any new commits related to security feedback raised will receive another review. If it makes sense, use the relevant comment thread to engage further to suggest additional changes or indicate that changes made will resolve the issue. This process will continue until the change is ultimately merged or closed by the customer. # Common Security Issues Found in Code Review Security is is our main concern as we review customer code. Every HackerOne reviewer is expected to thoroughly examine the code in every review for security issues. This includes both the code that's part of a proposed change as well as any existing code in the review's files. Security issues can commonly be found using the help of automated tools, but also through manual code review. To take a look at some of the tools available for reviewers in our community, check out the following guide: [Security-Focused Reviewer Guide](https://docs.pullrequest.com/reviewer-documentation/security-focused-reviewer-guide/) **Common security-related issues caught by HackerOne reviewers include (but are not limited to) things like:** * Known security vulnerabilities associated with a project's dependencies (and packages bundled with those dependencies). * Credentials hard-coded in source code. * Missing authorization or able to access information across accounts if code is abused. * Areas vulnerable to SQL injection attacks. * Ineffective, or missing, encryption of sensitive information. * Use of insecure cryptography. * Cryptography methods not abiding by framework best practices. * Improper credential/role management. * CRLF injection and XSS vulnerabilities. Ensuring user-supplied data is sanitized/neutralized appropriately. * File systems vulnerable to directory traversal. * Opportunities for unwanted information leakage. * Committing real user data in tests. * Improper integration of 3rd party tools. {% hint style="info" %} Check out more common application security issues from OWASP [**here**](https://cheatsheetseries.owasp.org/). {% endhint %} As with any feedback comment, links to external resources/documentation are highly encouraged. # Reviewer Code of Conduct By engaging with the HackerOne Code platform, customers, fellow members, and HackerOne core team members, all reviewers agree to help empower our community by following the Code of Conduct (CoC). **Effective Date: Oct 1, 2022** ### Code of Conduct By engaging with the HackerOne platform, customers, fellow members, and HackerOne core team members, all Reviewers agree to help empower our community by following the Code of Conduct (CoC). The CoC is in addition to relevant items our [Terms of Use](https://www.pullrequest.com/terms/), [Privacy Policy](https://www.pullrequest.com/privacy/) and the executed agreements completed prior to activating your Reviewer status for eligibility to work on the platform.
Behave professionally Platform interactions should be at all times respectful and communicated in a professional manner and tone with a view to being beneficial to the review validation process. Creating unnecessary noise, leaving rude/terse comments, or spamming comments are some examples which can be considered unprofessional behavior. These actions are unhelpful for organizations seeking professional help and impact the reputations of the code review platform, you as a Reviewer on the platform, and fellow Reviewer members of the community. #### Slack Communication Reviewer Slack communication should follow the same guidelines as general CoC. Creating unnecessary noise, leaving rude or lewd comments or images, or spamming posts for an update are considered unprofessional behavior. If it is confirmed that a Reviewer account is tied to actions which amount to a breach(es) of our CoC, enforcement action may be taken. Reviewers are permitted to use the Slack channels based on the intention set in the channel name and description. Reviewers are permitted to post content such as job opportunities with 3rd party organizations in the #general channel. Reviewers should post support issues or suggestions for improvements in the #support or #suggestions channel respectively. Reviewers will be added to the language specific private channels on an as-needed basis.
We encourage a friendly community with discussions both related and unrelated to code review, but be respectful and remember that there’s a human on the other side of the screen. Some examples of inappropriate behavior: * Judging the question or the person asking the question (“this is a dumb question”). * Soliciting personal information (such as marital status, sexual orientation, phone number, address, etc). * Continued one-on-one communication after requests to cease. **Acknowledgment of communication styles & interpretations** We understand and acknowledge that the context of providing professional feedback for individuals' work in peer code review workflows has many nuances, and that the lines of constructive criticism vs. non-constructive criticism can be circumstantial. We also understand and acknowledge that individuals tend to receive professional feedback differently. **Any feedback provided to customers that is both reasonably related in subject matter and reasonably phrased, but received negatively (e.g., a code author takes offense) is NOT considered unprofessional behavior.** These situations will be evaluated on a case-by-case basis by core members of the HackerOne team.\ \ Examples of unprofessional behavior in the form of code review feedback: * 🚫 "The way you structured this component is dumb." * 🚫 "Are you seriously going to just print the user's SSN to the console?" * 🚫 "Wow this is bad. You need to just throw this away and try again." Examples of code review feedback which likely would *not* be considered unprofessional behavior: * ✅ "I have some concerns with the overall design of this component. As is, it doesn't follow conventional standards and best practices." * ✅ "Printing PII like the user's SSN to the console is a critical security issue. My assumption is it's left over from debugging." * ✅ "Unfortunately, the implementation of this feature is convoluted and error-prone. My opinion is that it would be more time-efficient to start from scratch. Here's the approach I would take..."
Do not disclose private repository details Private repository code review details including: organization name, repository name, scope, proprietary functionality, team composition, account information, or any other information considered confidential may result in enforcement actions. When collaborating with other Reviewer members or core HackerOne team members, be sure to use communication channels which are not accessible to any non-community members. This includes Slack and email.
Only communicate with customers through approved channels Only use approved communication channels unless the program has intentionally provided a contact method to the Reviewer and communication is facilitated via the code review platform or a medium approved and administered by a core HackerOne team member. Contacting customers “out-of-band” is a violation of this CoC. The code review platform (reviewer.pullrequest.com) is considered an approved communication channel; any others will either be explicitly specified in the code review platform or by a core HackerOne team member. **What if a customer contacts me outside of the code review platform?**\ If a customer contacts you outside of the code review platform, and in a way which is not approved or facilitated by a core HackerOne team member, please report it to any staff member in the PullRequest Reviewers Slack Workspace and/or to ****.
No unauthorized use of intellectual property Customers entrust our community to keep their code safe; any duplication or unauthorized extraction of intellectual property, including repository assets, is prohibited. \ \ This includes (but is not limited to): * Attempting to clone private repositories. * Extracting large blocks of logic to run on a local machine. * Gaining access to and using accounts or production credentials not approved per the organization.
No abusive language Any discrimination based on age, ethnicity, level of experience, nationality, personal appearance, race, religion, sexual or gender identity and orientation, physical appearance, political beliefs, or other protected classes is not tolerated. Hate speech, profanity, or any aggressive threats in comments or other communication methods is strictly prohibited. Violating this guideline includes posts on social media and other platforms. If it is confirmed that a Reviewer member account is tied to actions which amount to a breach(es) of our CoC, enforcement action may be taken.
No misuse or theft of intellectual property Any unauthorized use of intellectual property will not be tolerated. This includes assuming the work of other Reviewer community members as your own.
Do not disclose organization information, confidential information or personal data without express written authorization Disclosing organization information without previous authorization is not permitted. This encompasses social media, blog posts and any other disclosure methods. This category also includes threats of disclosure. Enforcement actions will be escalated based on severity, means, and sensitivity of the disclosure
No extortion or blackmail Any attempt to obtain material gain by coercion is not permitted and may amount to a criminal offense.
No unauthorized impersonation / social engineering Any unauthorized attempts to socially engineer another party through impersonation of a core HackerOne employee, another member of the Reviewer community, an organization member or a falsified identity will not be tolerated.
Code of Conduct definitions **“Confidential Information”:** means any information made available through the HackerOne platform or programs, including but not limited to vulnerability information, confidential information and know-how (including but not limited to ideas, formulae, compositions, processes, procedures and techniques, research and development information, computer program code, performance specifications, support documentation, drawings, specifications, designs, business and marketing plans, and customer and supplier lists and related information. **“Reviewer”** means an individual using the HackerOne code review platform to provide code review services. **“Code Review Submission”** means comments and documents and related materials evidencing a Reviewers activities related to a merge request, including, but not limited to: source code, collaborator comments, and comments from other members of the Reviewer community. **“The Mediation Team”:** is a cross-functional group of stakeholders led by senior HackerOne support staff. **“Personal Data”:** is information that relates to an identified or identifiable individual. If it is possible to identify an individual directly from the information you are processing, then that information may be Personal Data. **Examples of Personal Data (not exhaustive)** * A person’s name; * IP address; * Cookie Identifier; * Email addresses; * Telephone numbers; * Physical addresses; * Date of birth; * Health history; * Ethnicity; * Sexual Orientation; and/or * Financial information: e.g. Banking information – credit card numbers, account numbers, sort codes
## Enforcement Actions The Reviewer Code of Conduct is enforced in accordance with the action guidelines below. **Please note that HackerOne reserves the right to escalate the severity of enforcement and sanctions in accordance with the nature of the offense and irrespective of previous offenses. Depending upon the severity of the offense, sanctions may include, without limitation, longer temporary bans, immediate removal from the Code Review Platform and/or a permanent ban.**
IncidentFirst OffenseSecond OffenseThird OffenseFourth Offense
Unprofessional behaviorWarning2nd WarningFinal WarningTemporary Ban
Unauthorized duplication of private repository assetsFinal WarningTemporary Ban (2-3 weeks)Temporary Ban (3 months)Account Removal
Discussing confidential information without approvalFinal WarningTemporary Ban (2-3 weeks)Temporary Ban (3 months)Account Removal
Contacting customer team members out-of-bandFinal WarningTemporary Ban (2-3 weeks)Temporary Ban (3 months)Account Removal
Abusive language or harassmentFinal WarningTemporary Ban (2-3 weeks)Temporary Ban (3 months)Account Removal
Extortion and BlackmailAccount Removal
Unauthorized impersonation / Social EngineeringAccount Removal
**Statutory timeline of warnings**: When a **Warning** is issued in accordance with this Code of Conduct, HackerOne considers that warning to be applicable for 12 months. Warnings which are over 12 months old expire and are not typically assessed when reviewing the severity of new warnings. **See something, say something**: If you see another Reviewer violating these rules, please reach out to our team. \
# Reviewer Terms and Conditions Terms and Conditions as of Oct 1 2022 **Effective Date: Oct 1, 2022** Welcome to HackerOne! By signing up as a Reviewer, you are agreeing to the following terms and the [General Terms and Conditions](https://www.hackerone.com/terms/general), which are incorporated by reference. A Reviewer is a hacker, security researcher, or anyone who is willing to help companies and other organizations find bugs and vulnerabilities in their technology. ### Your Use of HackerOne Platform You may use the HackerOne Platform to participate in Programs and submit Reviewer Submissions provided you comply with the Terms. ### Definitions Some of the capitalized terms used in these **Reviewer Terms and Conditions** are defined the [**General Terms and Conditions**](https://www.hackerone.com/terms/general). * **Reviewer**\ A member of the code review community who has completed on-boarding requirements and is eligible to earn on the HackerOne code review platform. These are typically senior-level software engineering professionals. When comparing to the larger HackerOne community, they’re similar to “hackers”, “researchers”, or "finders". * **Code Review Network**\ The community of on-boarded reviewers. * **Marketplace**\ This is used to describe the two sides of the on-demand code review platform: customers submitting code to the code review platform to be reviewed, and the reviewer network of engineers performing the code review. ### Conduct Our Platform operates for the benefit of the Reviewers and Customers. HackerOne is passionate and proud of the unique ethical environment that it has created. Accordingly, all users of the Platform must conduct themselves in a professional, respectful, and courteous manner when interacting with HackerOne and/or each other. All Reviewer must use the Platform properly. Any inappropriate behavior by a Reviewer (or that which is deemed to violate the spirit of the environment) will not be tolerated by HackerOne. In such circumstances, HackerOne, may at is sole discretion terminate a Reviewer’s use of the Platform. For further information on our approach, please visit HackerOne's [**Code of Conduct for Finders**](https://www.hackerone.com/policies/code-of-conduct). ### Reviewer Submissions By making any Reviewer Submission available to a Customer, you agree to the Program Policy. HackerOne's [**Vulnerability Disclosure Guidelines**](https://www.hackerone.com/disclosure-guidelines) are superseded by individual Program Policies in the event of a conflict. You represent that neither the Reviewer Submissions nor any use of Reviewer Submissions by the Customer will infringe, misappropriate, or violate a third party's intellectual property rights, or rights of publicity or privacy, or result in the violation of any applicable law or regulation, including export control laws. ### Rewards You will be awarded earnings for submitting Reviewer Submissions to a Customer for a particular Program, if the submitted Reviewer Submissions meet the Customer's requirements described in the Program Policy. HackerOne will process Earnings(s) that are monetary payments on behalf of Customer, and will typically remit the Earnings payments to you within ten (10) business days. HackerOne is not responsible for delays in payment outside of HackerOne's reasonable control. You may remain anonymous by using a pseudonym. To be eligible to receive a Reward, however, you must provide HackerOne with accurate, complete, and up-to-date information about you, including your address, tax identification number (if applicable), and any other information that HackerOne reasonably requests, to allow HackerOne to legally send any Earnings to you and file any appropriate tax form following year end. If you do not provide this information to HackerOne, any Earnings that would otherwise be paid to you will be paid to a charity of HackerOne's choosing. Where relevant, you are solely responsible for paying any and all taxes related to the Earnings payments. HackerOne will not be liable in any way for any Program, including any errors or omissions in any Program Policy, or any loss or damage incurred as a result of your reliance on any Program Policy. ### Independent Parties/Transactions Depending on your location you may be a contractor, or part-time employee of HackerOne who wishes to participate in Code Review Programs and connect with the Customer through the Services. Nothing in the Terms is intended to render HackerOne and you as joint venturers, partners. Customers are NOT Affiliates, employees, contractors, or agents of HackerOne, but are independent third parties who want to participate in Programs and connect with you through the Services. You agree that any legal remedy that you seek to obtain for a Customer's actions or omissions or other third parties regarding a Customer's Program, including Reviewer Submissions, will be limited to a claim against the particular Customer or other third parties who caused harm to you, and you will not to attempt to impose liability on HackerOne or seek any legal remedy from HackerOne with respect to those actions or omissions. Any contract or other interaction between a Customer and you, including with respect to any Program Policy, will be between the Customer and you **only**. HackerOne is not a party to such contracts and disclaims all liability arising from or related to such contracts. ### Ownership and Licenses HackerOne does not claim any ownership rights in any Reviewer Submissions. You agree that HackerOne may collect statistical and other information about Reviewer Submissions and use that information for HackerOne’s benefit. Except for any Reviewer Submissions, HackerOne and its licensors exclusively own all right, title, and interest in and to the Services and content contained on the Services, including all intellectual property rights. The Services and HackerOne content are protected by copyright, trademark, and other laws of the United States and foreign countries. By making any Reviewer Submission available to a Customer through the Services, you hereby grant to HackerOne a perpetual, irrevocable, non-exclusive, transferable, sub-licensable, worldwide, royalty-free license to use, copy, reproduce, display, modify, adapt, transmit, and distribute copies of that Reviewer Submission, for the sole purpose of providing the Services. By making any Reviewer Submission available to a Customer through the Services, you hereby grant to the Customer a perpetual, irrevocable, non-exclusive, transferable, sub-licensable, worldwide, royalty-free license to use, copy, reproduce, display, modify, adapt, transmit, and distribute copies of that Reviewer Submission. HackerOne hereby grants to you a revocable, non-exclusive, non-transferable, non-sub-licensable, worldwide, royalty-free license to use the HackerOne Platform and access and view the content that HackerOne makes available on the HackerOne Platform solely in connection with your permitted use of the HackerOne Platform. HackerOne may change or discontinue all or any part of the HackerOne Platform, including your access to it, at HackerOne's discretion. ### Authority If you are using the Services on behalf of a company (such as your employer), or a Customer or other legal entity, you represent that you have the authority to bind that company or other legal entity to the Terms. If you are a minor (in the United States, that means under 18 years old), your parents or legal guardian must agree to the Terms on your behalf, and we may require additional information confirming that agreement by your parents/legal guardians. # Reviewer Display Name ## Your display name Your HackerOne Code display name, along with a `24x24px` thumbnail of your profile photo, will be appended to the end of the comments you add in code reviews. This is so that the development teams receiving fulfilled code reviews have a way to uniquely identify the reviewers who submitted specific comments and reply back.
Reviewer display names may appear a variety of other places: such as a list of which reviewers are currently assigned to a code review job or on pending comments that have not yet been posted. ## Updating your display name Your display name & profile photo can be updated from the [PullRequest Reviewer Settings page](https://app.pullrequest.com/reviewer/settings/profile). ![Reviewer Profile Settings](/files/-LavN95TcAsjOwaFlOsY) Reviewer profile display names will default to the user's first name and last initial. {% hint style="info" %} **Example**: "Vanessa Smith" will default to "Vanessa S" {% endhint %} ### Display name guidelines All display name change requests are subject to HackerOne approval and are usually reviewed within 24 hours. HackerOne reserves the right to reject a display name change for any reason. A staff member will reach out to you directly if you change request was rejected. # Adding PullRequest as a Professional Experience As a member of the HackerOne reviewer network, you're more than welcome to add PullRequest to any public-facing profiles where listing professional experience is appropriate. For example, you're welcome to use PullRequest as an experience on LinkedIn under your work **Experience**, as a **Certification**, or both. Understandably, teams interested in using PullRequest are interested in getting an idea of what types of software professionals will be reviewing their code. Having PullRequest listed in your experience can be very effective for ensuring prospective clients that reviewers in our network are highly experienced, talented software engineers. This said, *this is not an expectation*. HackerOne values your privacy and preferences. ## Adding PullRequest to your Work Experience (LinkedIn) You're welcome to add PullRequest to your **Experience** list on your LinkedIn profile. Since there are a variety of types of engineers in our network, you're free to use a title that you believe represents your expertise in a relevant way. (e.g., "Software Engineer", "Developer", "Code Reviewer", "Security Specialist"). {% hint style="info" %} **NOTE:** If PullRequest finds your designation to be misrepresentative, a member of our team may contact you to make modifications. {% endhint %} ![](/files/-Lt7L5taGCl8eJI2TpTq) ## Adding the PullRequest Reviewer Certification (LinkedIn) ![](/files/-Lt7N996wPk2JNC6twoK) Click to open the [LinkedIn certification entry](https://www.linkedin.com/profile/add?startTask=pullrequest_reviewer) and add your language(s) reviewed or simply "Reviewer" ![](/files/-Lt7NVQL8Yh0v4a_yefZ) The certification name is **"Certified Reviewer:"** followed by any of the major programming languages & frameworks you review for. The issuing organization is **"PullRequest"** -- it will autocomplete as you start to type. Link "Credential URL" to the reviewer page: Click "Save" and you're done!