When you do a pentest what is your recommendation to the client on how to handle/interpret the report?

What I frequently see is that identified issues - especially issues related to self developed software - are not fixed properly. The easiest example is the XSS, which is "remediated" by s/// (replace exactly the XSS String from the report with nothing).

This fix is obviously not a good one - on the one hand because the XSS still exists and on the other hand because this bug is a clear indication that the concept of handling user input is not secure in any way. From my point of view this means that other XSS vulnerabilities are present even though I did not find them. Assuming that a tester finds all vulnerabilities is, in my opinion, unrealistic.

How do I get the client to think like this? E.g., I want the client to say "Oh, you found an XSS! We probably need some technology/process/architecture adaption... to get rid of this stuff as much as possible. Maybe let's use some web-framework and introduce a SAST solution."

I learned that the generic remediation text-blocks at the end of every report are not sufficient at all. What has proven quite effective are remediation workshops - basically discussing the results in a 2-3 day workshop and then supporting devs during implementation. Of course, only a small amount of customers are willing to pay for this (and I don't really have the resources).


Ultimately the responsibility for implementing the recommendations from a penetration test/security review, lie with the owners of the system.

As a consultant, you can make recommendations, so as with XSS you can recommend that the customer ensure they use a robust combination of input validation and output encoding to properly mitigate the risk and you can point out the weaknesses of blacklist filtering or other naive fixes like getting rid of specific characters.

However at the end of the day, you can't stop customers from taking this approach against your recommendations.

Of course, if you're internal to the organization you have more options in that you can try and get security standards for your development teams that lay out the correct way to avoid/reduce the incidence of security issues.


This is a issue in general with testing.

If you know why the test was done to begin with, use that.

For self developed software try guiding them into frameworks and lists like the OWASP, so they can see more of the whole picture/problem. It gives a hint to where they can go and teach them selves more. Costs is often an issue. So paying for workshop to educate them, may not be an option. (But do include it at the end!)

Referring to legal obligations or standards like ISO 27000-family, sometimes helps. Or if you are familiar with local law and standards.

Just remember, you are a technical personnel, not legal, so know your limits. "Known issue in the OWASP framework [this and that], and may be a breach of legal obligations given in ISO 27001 [more or less specific, depending on the issue]. Recommended fix includes revision of [bigger issue, as well as the little fix.]".

  • C, Tester.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.