Bug Bounties, Pentests, and Showing Impact

After my detour through the OWASP Top 10:2025, I resumed the Practical Bug Bounty course from TCM Security and Intigriti. This section compared bug bounty hunting with penetration testing, and one word kept coming up in my notes: impact.

What can someone actually do with the behavior I've found, and why would that matter to the application or its users?

That question belongs in both types of testing. The difference is what I've been asked to assess and what the recipient expects from the report.

The assignment changes the report

A bug bounty program sets the assets, activities, and types of findings it will accept. A researcher might spend their time on one feature or follow one promising issue across several in-scope components. The submission usually explains a particular vulnerability, how to reproduce it, and its impact.

A penetration test has an agreed scope, testing window, and set of deliverables. The client may need coverage across several roles and workflows, a review of security controls, or evidence supporting a particular compliance requirement. That can make configuration weaknesses and lower-severity findings relevant to the final report, even when a bounty program would not reward them.

The course's comparison between testing part of an application and reviewing the whole application is useful for understanding those different goals. In practice, both are bounded by scope. A pentest might cover only an API or a payment workflow, and a bounty program might include many applications.

Neither approach guarantees that every vulnerability will be found. The report needs to explain what was tested and what was left outside the assessment.

A possible weakness still needs context

The course lists several findings that may have little value as standalone bug bounty submissions: weak password policies, missing account lockout, unlimited login attempts, account enumeration, outdated software, cookie settings, ciphers, and certificates.

I read that list as a reminder to investigate the context rather than assume a category is always harmless or always severe.

For example, a visible software version is a lead. To turn it into a supported vulnerability claim, I would need to establish what is actually deployed, whether a relevant weakness applies, and whether the affected behavior is reachable within the authorized scope. The version string alone doesn't answer all of those questions.

The same care applies to login behavior. A missing account-lockout message doesn't establish that all protections are absent. Other controls may limit attempts or respond to suspicious activity. Testing those controls also needs to stay within the program's rules, rather than generating excessive traffic to prove a point.

HackerOne's core ineligible findings guidance gives a concrete example of this distinction. It generally excludes theoretical issues and certain hardening observations without clear impact, while allowing programs to specify exceptions. The policy for the actual program still needs to be read before testing or submitting anything.

Reporting more should still mean reporting accurately

A pentest can have a broader reporting brief. HackerOne's pentest reporting guidance, for example, includes observations such as missing security headers, weak password policies, and vulnerable outdated software.

That doesn't give every observation the same severity. A useful report separates what was observed, what was demonstrated, and what remains uncertain. It also explains the risk in the context of the application instead of assigning a dramatic impact to every scanner result.

Compliance is another possible reason for the engagement, but it needs a defined requirement. A pentest report can contribute evidence to an assessment; completing a pentest alone doesn't establish compliance with every applicable standard.

Questions to carry into testing

For a finding, I can work through a short set of questions:

Is the target and test technique authorized?
What behavior can I reproduce, using safe test data?
What access or conditions does it require?
What effect have I demonstrated, and what am I only proposing?
What would address the cause?
What regression test would show that the fix still works later?

The course's emphasis on impact helps keep the explanation practical. A recipient needs enough evidence to understand the problem and decide what to do about it. Whether I'm writing a bounty submission or contributing to a broader assessment, that is more useful than a list of alarming labels.

The next part of these notes covers the Security Headers and SSL Labs checks I ran against my own sites, including what the grades tell me and where their coverage ends.

Sources and further reading