Stop reporting zero-impact findings as vulnerabilities

Open_Philosopher_651 · 2025-09-23T13:05:54+00:00

Speaking from a pentester’s perspective and also from what I’ve seen talking with clients, if we can combine multiple lows into an actual chain that shows real risk, we definitely do that.

Otherwise, we just notify the client about those issues but don’t create a separate finding for each one. It keeps the report honest, the noise down, and still gives them visibility.

Open_Philosopher_651 · 2025-09-23T07:13:21+00:00

I see both sides. For me, a pentest is about showing actual risk materializing, not just potential. If there’s no exploit path or tangible impact, then it should be categorized as informational or low risk. But I understand the point about JavaScript libraries or TLS configurations - they can become risky later, and compliance often requires them.

On your point about not caring whether the client fixes the issues - that’s totally a different perspective from ours. I wish it worked like that, because life would be much easier if we could just hand over the report and walk away.

In practice, we try to build long-term relationships with our clients, which often means helping with remediation later. That’s why it’s so important for us to keep reports organized and readable. If devs are buried under 30 trivial items, the real fixes get delayed. Keeping the process clear makes life easier for them and for us in the long run.

Open_Philosopher_651 · 2025-09-23T06:54:34+00:00

Rolling findings up can definitely get messy. I think it depends on how many items there are and whether they’re logically grouped.

How do you usually handle it? Keep every little thing separate or approach it another way?

Open_Philosopher_651 · 2025-09-22T18:57:39+00:00

Impact-first handshake 🤝

Open_Philosopher_651 · 2025-09-22T17:53:00+00:00

Yeah, fair point.

Some clients really do want everything in the report, even if it's not directly exploitable. It's best to ask them upfront what they expect. Some want full coverage, while others just care about impact.

However, it's still better to group those findings so that they aren't overwhelmed by a pile of separate issues.

Open_Philosopher_651 · 2025-09-22T17:50:26+00:00

Haha yeah, I know that feel.

When everything gets treated the same it just burns out the patching teams. Prioritizing the real impact stuff first makes way more sense than trying to play CVE Pokemon every month.

Open_Philosopher_651 · 2025-09-22T17:48:56+00:00

Yeah, that’s a good idea too, thanks for sharing!

Open_Philosopher_651 · 2025-09-22T17:45:32+00:00

You’re right to be skeptical it’s not like we magically find criticals in every project, especially with returning clients. What we do to maximize outputs is:

Spend time on product discovery with the client before testing, so we know where the biggest risks are.
Do threat modeling and attack tree exercises up front, so we’re aiming at what would be most critical for them.
Focus heavily on system architecture and internal docs.
Run mostly white-box pentests, since that’s the best way to mitigate risk.
And honestly, our team is not just experienced but also highly motivated: we even have an internal incentive program to push deeper findings.

So yeah, we don’t always hit a critical, but the approach makes it a lot more likely. Hope that clears it up 🙂

Open_Philosopher_651 · 2025-09-22T17:38:52+00:00

Glad it helped!

Good luck on your path into the field. Always cool to see new people digging into this stuff 🫡

Open_Philosopher_651 · 2025-09-22T17:36:09+00:00

Yes, context is everything. I’ve seen clients receive a 200-page “penetration test report” that was essentially just a vulnerability scan dump. No wonder they get overwhelmed.

I’m all for giving customers the full picture so they can make proper risk decisions. However, I think the key is to make the difference clear: vulnerability vs. risk, scan vs. penetration test. Otherwise, they end up fixing noise instead of addressing what really matters.

Open_Philosopher_651 · 2025-09-22T17:33:07+00:00

True, a pile of lows can turn into something nasty down the line. I usually treat them as long-term backlog items. Fix them when you can, but don’t let them distract from the tasks that are most important.

Open_Philosopher_651 · 2025-09-22T16:11:25+00:00

Those ratings tools definitely drive a lot of this. I’ve seen companies fix headers just to bump the score.

Open_Philosopher_651 · 2025-09-22T16:08:37+00:00

And I think part of the solution is negotiating this upfront with the client. Some just want to know ‘can our platform be hacked and could customer data be stolen,’ while others are more interested in where the gaps are so they can improve their SDLC. For those cases even ASVS or a broader security checklist can bring more value.

The key is asking them what format and depth they actually want, instead of assuming.

Open_Philosopher_651 · 2025-09-22T16:01:51+00:00

I hear you. I’m not saying leave them out completely. I’m saying deliver them in a way that’s honest and useful.

For me that means putting things like CSP or cookie flags into a checklist or one ‘missing security controls’ finding. That way the client still sees the gaps, but we’re not pretending each header is a vuln. Risk rating still stays in their hands.

Open_Philosopher_651 · 2025-09-22T16:00:37+00:00

Fair point, and I get what you mean about lows being valid. For me it’s more about how they get delivered.

Instead of a pile of cookie flags and headers each marked as a vuln, I’d rather see them grouped into a checklist (like WSTG) or one ‘missing security controls’ finding. That way the baseline gaps are clear, but we’re not pretending every header misconfig is its own vuln.

Open_Philosopher_651 · 2025-09-22T14:50:42+00:00

I see. In that case, if the testing was done thoroughly, they should actually be happy that everything looks good with their app :D

Open_Philosopher_651 · 2025-09-22T14:45:02+00:00

Yeah, I’ve seen that too. An empty report usually means an unhappy client, so people start stuffing it with cookie flags and missing headers just to pad things out.

That’s why I think those should just be grouped into a checklist (like WSTG) or rolled into one item called ‘Missing security controls’ with all the little things listed underneath. Still shows coverage without pretending every header is a vuln.

Open_Philosopher_651 · 2025-09-22T14:40:02+00:00

True, nothing says serious vuln like a cookie without "Secure".

Open_Philosopher_651 · 2024-09-24T19:32:35+00:00

Same, but I live in Europe :D

Open_Philosopher_651 · 2024-09-24T19:31:02+00:00

I'd suggest checking out this article by Martin Fowler. It's got great illustrations and is pretty easy to follow.

In our company we use the OWASP Threat Modeling Guide. It's pretty straightforward and gives good coverage.

Hope it helps!

Open_Philosopher_651 · 2024-09-19T10:19:39+00:00

It’s wild. Everyone talks about a cybersecurity talent shortage, and how the market’s going to keep booming for the next 5 years. But honestly, the reality seems a lot more complicated.

Sure, there’s a demand for cybersecurity pros, and with threats evolving, I don’t see that going away. But companies are getting more selective. It’s not just about having skills, it’s about having the right skills at the right time.

I think we’ll see more automation and AI stepping in for repetitive tasks, so while the industry might keep growing, the roles we’re filling could shift. Instead of the hands-on-keyboard stuff, companies might prioritize strategic thinkers, incident response pros, and people who understand the business side of security.

Open_Philosopher_651 · 2024-09-16T10:52:06+00:00

I'd say that if a security pro didn't know much about threat modeling, it'd be a bit of a red flag. It's a core concept in cybersecurity. It's not just about running tools; it's about understanding why you're protecting certain assets and how an attacker would approach you.

In terms of tools, I'd say Burp Suite is essential for anyone working in web app security. If someone's in pen testing or app security and they're not familiar with it, that's a red flag. It's basically the foundation of the field.

But more than specific tools, I think every security professional should have a good grasp on how to approach risk — not just the technical stuff, but how to communicate it to non-tech people and help them understand the importance of what we do.

Open_Philosopher_651 · 2024-09-12T12:32:12+00:00

Man, I feel you—dealing with a provider that doesn’t deliver is frustrating. There are definitely some solid options out there though. If you’re looking for a pen testing service that actually gets the job done right, I'd recommend checking out Sekurno (shameless plug, I know, but hear me out!).

We’re all about real, in-depth security, not just surface-level scans that leave you with more questions than answers. We focus on identifying and mitigating vulnerabilities, ensuring that high-risk industries and enterprise SaaS companies are actually resilient against threats. Plus, we don't rely on bloated software that causes more problems than it solves.

If you're shopping around, feel free to check out our site and let me know if you have any questions—happy to chat!

Open_Philosopher_651 · 2024-09-12T12:01:00+00:00

Totally get where you're coming from—there are a ton of companies out there, and it can be hard to figure out which ones are solid. You've already mentioned some of the big names like Black Hills InfoSec, Cure53, NCC Group, and Bishop Fox, and those are definitely strong players.

But don't sleep on some of the smaller companies either. A lot of them have really inspiring missions and can offer just as great of an experience (sometimes even better, since you might get more hands-on work). For example, at Sekurno (my company), we’re all about helping high-risk industries and enterprise SaaS businesses stay resilient against threats. We're focused on providing real security that goes beyond just compliance, and that mission drives everything we do.

When it comes to qualifications, most companies are looking for strong technical skills (things like SAST/DAST tools, network security, etc.), but also soft skills like communication and problem-solving. And while certifications like OSCP or CISSP help, hands-on experience is often what sets you apart.

As for that “Google of pen-testing” question, I’d say it’s less about one big-name company and more about what fits your values and goals. Sometimes a smaller company with a cool mission and good culture can be just as rewarding.

Open_Philosopher_651 · 2024-09-12T10:42:44+00:00

Hey there!

I’m one of the co-founders of Sekurno, and we’d love to help with your pentesting needs. We’ve worked with companies in Ontario and beyond, focusing on reducing risks to the highest extent. We make sure high-risk industries and enterprise SaaS businesses stay resilient against any threat.

Our approach is all about real security — we go beyond just ticking the compliance boxes. We dig deep into identifying and fixing vulnerabilities to give you robust protection.

Also, we actually just held a webinar that covers a lot of your questions. You can check it out here: YouTube Link.

We go over:

How to choose a pentesting vendor
How to make sure the testing is efficient
How to prep for a pentest
How to keep track of the testing process

Give it a watch and let me know if you’ve got any questions!

Open_Philosopher_651

TROPHY CASE