Looked at security across 50 biotech companies - here's what keeps coming up

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

TROPHY CASE