A pentest report is the start of the work. Here is what the end should look like.

A pentest report identifies weaknesses, but the true value lies in the follow-up document that details what was fixed, how it was fixed, and proof that the fix worked. To make this document clear and comprehensive, it should contain six key elements for each finding:

1. What the issue was, including a stable ID, the specific weakness (e.g., CWE-601), and the file and line number.

2. Confirmation that the issue was within the agreed scope for remediation.

3. Evidence that the finding was indeed addressed, such as a pull request detailing the changes made and why.

4. Verification of who made and reviewed the fix, including the author and the team's merge.

5. Validation that the issue has been resolved by running a rescan after applying the fix.

6. The date of the fix's merge to ensure it was completed within the audit period.

A spreadsheet with these six columns, one row per finding, typically suffices for reviewers. This approach ensures transparency and accountability.

For example, during a recent rehearsal Fix Sprint on the OWASP NodeGoat app, sixteen issues were identified, fifteen of which were resolved through five pull requests. One issue, F-007, involved a committed TLS private key. Instead of simply deleting the file, which would leave the key exposed in the repository's history, the team recommends generating a new key and certificate, keeping them outside the repository, removing the file, and rewriting history if the repository was or is public.

In cases where a finding cannot be fully closed, it is documented as "explained," clarifying the appropriate actions taken. The final scan of the merged code after fixes should reveal only the remaining unaddressed issue(s), providing a clear audit trail.

The full evidence pack, including the CSV of findings, is publicly available. Three common mistakes in closing findings are to delete evidence, merge without a rescan, or combine multiple fixes into a single large pull request. Each finding should have its own pull request for easier review and traceability.

The Railo Fix Sprint methodology revolves around this structured record. After receiving findings, you agree on which issues are in scope. Within a week, the team returns a pull request per weakness, with rule-based fixes for common patterns and manual reviews for others. Every fix is followed by a rescan, and your team reviews and merges the changes.

The final evidence pack contains one row per finding, as outlined above. The service is priced at $1,500 for one repository, with no changes made to your repository without your review, and no execution of your code on our side. If you have a report to close or wish to schedule a Fix Sprint, contact Zarif Latif at zarif.latif@railo.dev with the subject "Railo Fix Sprint" or book a 15-minute session at cal.com/railo.