Retesting is essential after the initial pentest to ensure vulnerabilities are fixed. Here’s how the HackerOne platform helps you collaborate with your pentesting team and use our tools for retesting.
Retesting Support
After the testing phase of the pentest concludes, retesting support will become available through a remediation period as part of the post-testing phase. Learn more about pentest phases here.
The duration of the remediation period varies depending on the type of pentest conducted. In most cases, it is either 30 or 90 days. During this period, you may request retests on vulnerabilities an unlimited number of times at no additional fee.
Retesting Individual Reports Or All Reports
The HackerOne platform lets you request retests on individual vulnerability reports, all unresolved findings at once, or any combination during the remediation period.
Here is a sample timeline for retesting that involves 4 separate findings:
Pentest results: Pentest concludes with 4 open findings reports.
Patch for report #1: A patch is released for Report #1 while the team investigates the others. A retest request can be initiated immediately for Report #1.
Retest report #1: The pentesting team confirms Report #1 is fixed, updating its status to Resolved.
Patches for reports #2, #3, and #4: A few weeks later, updates addressing Reports #2, #3, and #4 are released. Retest requests are submitted for these reports.
Retest reports #2 and #3: The assessing team confirms that Reports #2 and #3 are fixed and no longer reproducible, updating their statuses to Resolved. Report #4 remains open.
Further update for report #4: An update is released for Report #4, and a second retest request is submitted.
Retest report #4: The pentesting team finds the issue in Report #4 is still observable. It remains Open.
Final update for report #4: Another update is released for Report #4, and a third retest request is submitted.
Final retest report #4: The assessing team confirms the issue in Report #4 is fixed and no longer reproducible, updating its status to Resolved.
Read this document to learn more about report states.
The HackerOne platform enables retesting on individual vulnerability reports. You can request pentesters to retest a vulnerability at any time after it’s reported, even during the testing phase. For instance, if a hotfix addressing the vulnerability is released within a day of the report submission, you can submit a retest request while the pentest is still ongoing.
Retesting After the Remediation Period
You can keep working with your pentest team to retest vulnerabilities after the remediation period ends as long as your service with the HackerOne platform is still active.
You can set a fee (minimum $50 USD) for the team to retest findings. When the request is accepted and fulfilled, the payment will be charged to your payment source, and the full amount will be transferred directly to the pentester.
To take this action, you must have a credit card on file or a pentester fee balance greater than $50 USD. This amount can vary. While some vulnerability findings may not require a higher fee, HackerOne recommends considering factors such as the effort needed for reproduction and the technical complexity when setting the amount.
How To Request A Retest
Sending The Request
To request a retest from the Timeline view, click the action picker drop-down (which defaults to Add comment) and select Request a retest.
You'll be prompted to add a comment with any relevant information the assessing team needs to know. Even a written confirmation that the fix was deployed in the testing environment can be helpful.
Click the green Request retest button to confirm. This action changes the status and sends a notification alert to the pentester who authored the report, as well as the rest of the assessing team. It also updates the report state from Triaged (Open) to Retesting (Open). Once claimed by a member of the pentest team, completion and results are usually available within 72 hours.
Retesting Results
Once the report has been retested, you'll see the results in the Timeline view. The results will explicitly state whether the issue is fixed or not fixed, and a summary of the retest activities will be included.
NOTE: Even if the fix is confirmed, the status will remain in Retesting (Open) until a member of your team approves it.
✅ If it’s fixed
The confirmation message will be:
Are you able to reproduce the vulnerability report? No, the fix works
❌ If it's still reproducible
The confirmation message will be:
Are you able to reproduce the vulnerability report? Yes
Approving/Rejecting Results
From here, you can Approve or Reject the results.
If the issue is fixed, you will see an Approve and Resolve button. Clicking this will change the report state from Retesting (Open) to Resolved.
If the issue is not fixed and is still reproducible, you will see an Approve button. Clicking this will change the report state from Retesting (Open) to Triaged (Open). From this state, you can request another retest later.
If there’s a reason the retest results cannot be accepted, click Reject. You will be prompted to provide a summary explaining why.
NOTE: Retest rejection is uncommon but can be used for various purposes. The most common cases include situations where the fix is confirmed (issue not reproducible), but more proof is needed, or if there's been a product update since it was reported and slightly modified steps to reproduce are needed.
Additional Remediation Tools
The HackerOne platform provides many additional tools to help you with remediation efforts and evidence of remediation following a pentest.
Hai: AI Copilot for Pentest Remediation
Hai is an intelligent co-pilot within HackerOne for vulnerability intelligence and management. Your organization administrator can enable Hai in Organization Settings > Hai.
Here are just a few of the ways Hai can help with remediation and prevention following a HackerOne pentest:
Instant creation of codified vulnerabilities as Nuclei templates or custom regex-based rules for SAST engines.
Fast, easy text extraction and analysis for image attachments.
Further remediation guidance in the context of additional technical stack and context information.
Allow it to query any of your past or concurrently running pentests to see if similar vulnerabilities were discovered on other assets.
Interpreting the likelihood of vulnerability impact if certain other conditions were to exist.
Propose strategic program improvements - secure SDLC, policies, security champions and more.
Provide further references to guide remediation, such as coding best practices, configuration hardening, patches, etc., within the context of the finding and how it was discovered.
On-the-fly research into public vulnerability databases, advisories, and exploitation details.
Thoughtful translation of technically complex security issues for a non-technical audience.
Re-analyze findings for approximate scores in various measurement frameworks (e.g., VISS, prior versions of CVSS).
Request Code Review
In addition to reproducing the vulnerability to confirm remediation, you can also Request a Code Review to verify that any source code updates adequately address the issue. This feature has no associated fees and is available for unlimited use both before and after the remediation period.
This option is especially helpful for:
Ensuring the issue does not introduce additional or unrelated risks while addressing the security risk.
Understanding if the issue could be isolated or systematic.
Reviewing a code-level fix that has been identified but is not yet available for runtime testing.
You can send a limited code snippet patch generated by git diff for review. When viewing a vulnerability report in the inbox, select Request Code Review from the action picker beneath the option to request a retest.
If selected, you'll be prompted with instructions for generating and submitting a code snippet for review.
Code snippet reviews are completed by HackerOne’s Code Reviewer Community, a group of rigorously vetted, specialized software engineers and security experts. Reviews are typically completed within 90 minutes.
The review results will be posted as internal comments on the report. This means the results will be visible to you and your internal team but not to the pentesters.
Export Report Timelines
Additional final PDF reports of the pentest can be generated to reflect the most current state of vulnerability findings, such as reports that have been retested and confirmed as fixed by the pentesting team. However, if you need additional evidence confirming remediation for specific vulnerability findings, you can export reports directly from the pentest’s vulnerability report inbox.
Supported formats include:
.pdf
.csv
.zip
.md
Vulnerability information, communications between pentesters and your team, state changes, and updates are included in the export as the report’s timeline with timestamp records.
When exporting content as a PDF file, you can choose to export the timeline events visible only to your internal team or to all participants, including pentesters.