Your pen test report just landed, and it has more findings in it than you hoped. That's normal. Almost nobody gets a clean report the first time, and the number of findings on its own tells you a lot less than you'd think.
Here's how to read it and where to start.
Severity is a starting point
Each finding comes with a severity rating: critical, high, medium, low, or informational. That rating is based on how bad it would usually be if someone exploited it. It's a good default, but you know things about your app that the tester doesn't.
For each finding, ask two questions:
- How easy is it to exploit? Can anyone on the internet do it, or does it need a logged-in user, a specific browser, or a lot of luck?
- What does it get the attacker? User data, admin access, money? Or just a version number?
A medium finding on your login page matters more than a medium finding on a marketing page nobody uses. Adjust accordingly.
The order I'd fix things in
1. Anything critical or high that touches auth or user data. Injection, broken access control, exposed secrets, ways to get into other people's accounts. Stop what you're doing and fix these. If a secret was exposed, rotate it first and clean up the code second.
2. Quick config wins. Missing security headers, cookies without Secure or HttpOnly, a server that announces its exact version, directory listing turned on. Most of these are one-line changes. Knock out a bunch of findings in an afternoon, and you'll also close off a lot of easy attack paths.
3. The rest of the high and medium findings. Put them in your tracker like any other bug, with an owner and a date. Two weeks for highs and a month or so for mediums is a reasonable target for a small team.
4. Low and informational. Use your judgment. Some are worth a five-minute fix. Some are "we know, and we accept it." Write down which ones you're accepting and why. An auditor or a customer may ask later, and "we decided not to, for this reason" is a perfectly fine answer.
If you think something's a false positive
Sometimes a finding doesn't apply. There's already a control the tester couldn't see, or the "vulnerable" component isn't actually used in a way that matters. That happens.
Don't just ignore it though. Reply and tell us why you think it doesn't apply. Either we agree and note it, or we explain what we saw. Either way it's documented, which is what matters when someone reviews it later.
Track the fixes
For every finding, keep a short record: what it was, what you did, when, and who did it. A ticket per finding is plenty. This matters most if you're doing SOC 2, since auditors want to see that findings actually got fixed, not just that you had a test.
Check your work
Once you've fixed things, verify them. For header and config issues you can run the free scan again and see the difference right away. For the bigger stuff, try to reproduce the original finding using the evidence in the report. If it doesn't work anymore, you're done with that one.
What to share and with whom
- Your team: the full report. They need the details to fix things.
- Your auditor: the full report and your fix tracking.
- Customers and prospects: the attestation letter. If they want more, the full report under NDA, along with a note on what's been fixed.
Don't post the full report anywhere public, and don't send it to everyone who asks. It's basically a list of weak spots, even after they're fixed.
One more thing
A report full of findings isn't a failure. It means the test did its job. The companies that should worry are the ones that never test, and the ones that test and then do nothing with the report.
Fix the important stuff, write down what you decided about the rest, and test again after your next big release.