Through My Lens.
How I see security, teams, and the craft of building things that last. Observations from the trenches, opinions I've changed my mind on, and patterns I keep seeing.
A Different Set of Eyes
Security expertise tells you what to look for. Perspective helps you see what others missed.
Internal security teams are constantly moving - reviewing application changes, APIs, infrastructure, detection rules, vulnerabilities, compliance, governance, and everything in between. With hundreds of changes happening across an organisation, it's unrealistic to expect an internal team to find everything.
That's where Bug Bounty and Vulnerability Disclosure Programs can make a real difference.
External researchers bring something incredibly valuable: a different perspective. They aren't familiar with your assumptions, your architecture, or the way you expect a feature to work. They look at your product differently, and sometimes that's exactly what you need.
But how you engage with them matters just as much.
Reward good research with meaningful bounties, recognition, or even simple gestures like goodies. More importantly, treat researchers as extended members of your security team, not as people pointing out what you missed.
They found something your team didn't. That's not a failure.
That's another set of eyes helping you make the company safer.
When Security Becomes Invisible
The best security controls are often the ones engineers don't even notice.
If an engineer has to remember to run a security scan, check a policy, validate a configuration, or raise a security ticket every time they make a change, eventually something will be missed. Not because people don't care, but because security that depends on perfect human behaviour doesn't scale.
That's where automation comes in.
The goal of security automation isn't to replace people. It's to remove repetitive decisions from people.
Build the control into the pipeline. Make the secure configuration the default. Block what shouldn't happen. Automatically detect what can't be blocked. Give engineers feedback at the point where they can actually do something about it.
I'd rather build a system where an engineer naturally does the secure thing than build a process that constantly reminds them to do it.
That, to me, is the real maturity of security automation:
When security is built well, engineers don't work around it. They simply work.
Beyond the Resume
I've changed the way I think about hiring.
Earlier, I placed a lot of weight on security fundamentals-certifications, CVEs, bug bounty rankings, tools, and technical depth. They're important, but I've come to see them as the starting point, not the differentiator. They tell me what someone knows today, but not necessarily how they'll grow tomorrow.
Today, I look for curiosity, ownership, communication, and the ability to learn.
I pay close attention to how someone approaches a problem they don't know the answer to. Do they ask thoughtful questions? Can they break down an unfamiliar problem? Are they willing to say, "I don't know, but here's how I'd figure it out"?
Over time, I've realised these traits compound.
Hiring isn't just about assessing what someone knows. It's about understanding how they think, how they learn, and who they can become.
Building Security Culture
I believe security culture is fundamentally misunderstood.
It's often reduced to annual training, compliance checklists, and awareness campaigns. I've seen those approaches work on paper and fail in practice.
What actually matters is what happens when Security isn't in the room.
Do engineers ask security questions before they start coding? Do product teams think about abuse cases while designing a feature? Does leadership reward teams for making secure decisions, even when those decisions require more time or effort?
That's culture.
Culture isn't what people do because Security asked them to. It's what they do because they believe security is part of their job.
When that mindset takes root, security becomes almost invisible - embedded in how products are designed, code is written, and decisions are made.
I might be wrong about this, but I think there's a simple test:
Can your security team take a week off without everything falling apart?
If not, security may still be a dependency - not yet a culture.