The Security Afterthought: Why You Won’t Care Until You’re on the Front Page
Or: Why Your Security Culture Needs to Grow Up Before Your Company Does
I don’t have a war story for you.
Every other post on this blog opens with a scene — a moment, a meeting room, a specific detail that puts you right there in the middle of something going wrong. Not this one. This one starts with a confession: I’ve never been part of a serious security incident. Fraud incidents, yes — but that’s different. My second job in e-commerce was taking a thriving startup from a garage to PCI DSS compliance. Two jobs before that, I was working in semiconductors on ISO compliance. I know more about security and compliance than many engineers on our current security and compliance teams right now, and I’ve managed to dodge bullets my entire career. Near misses, sure. Found things before hackers did — or before bug hunters could claim a bounty on them. But I’ve never had to sit across from a CISO explaining how customer data ended up on a paste site at 2 AM.
And honestly? That scares me more than having a story would.
Because the absence of a crisis doesn’t mean the absence of risk. It means I’ve been lucky, careful, or both — and luck is not a strategy that scales.
Robert Mueller, the former Director of the FBI, put it bluntly at the RSA Cyber Security Conference: “There are only two types of companies: those that have been hacked, and those that will be.”
But this post isn’t about scaring you. It’s about building a security culture that grows with your company, starting from literally one person. Because here’s what I’ve learned across decades of compliance work: when a compliance request lands on your desk, most engineers groan. They see checkbox theatre — something that ticks an auditor’s box so the insurance claim holds up if things go sideways. And I’ll tell you, most of those requirements are actually useful. They’re generally rooted in lessons you wish you never have to learn first-hand, because learning first-hand means you’re neck-deep in it.
When You’re Small, You Need a John
Every organisation has someone who reads security blogs for fun. Someone who knows what the OWASP Top 10 actually means, who gets a bit too animated about new CVE disclosures, whose eyes light up when a zero-day drops the way most people’s light up for a Champions League final.
We had one. His name was John.
Most organisations either ignore this person, overload them, or lose them. When you’re small — one or two teams, maybe a dozen engineers — you can’t afford a dedicated security team. But you can find that one engineer who’s always thinking about this stuff in the back of their mind, even though it’s not their day-to-day. Their day-to-day should be the product. Don’t hire a total zealot who won’t be productive on anything else. But if they’re a little less productive on feature work because they’re the person who catches the authentication flaw in code review, or who asks “but what happens if someone sends a malformed token here?” — that’s not a cost. That’s a bargain.
Your first move isn’t to hire a security team. It’s to find your John and give them legitimate space to operate.
Let them run a lunch-and-learn. Let them add a SAST scanner to one pipeline as a proof of concept. Let them be the person who reviews the authentication flow on that new feature. This isn’t a formal role. It’s recognising that someone already cares and giving them permission to act on it.
The worst thing you can do is have a John and suppress them because “security isn’t a priority right now.” Because the subtext of that statement is: “We’ll make it a priority after something goes wrong.” And by then, John has either left for a company that listens, or been so thoroughly demoralised that they’ve stopped raising the flag entirely.
Building Culture Beyond One Person
John can’t scale alone, and you don’t want a single point of failure for something this important. Ironic, isn’t it — building redundancy into your systems while having exactly zero redundancy in who cares about keeping those systems secure.
This is where you start making security part of how your teams think, not just what one person does.
Onboarding that actually means something. New engineers should understand your threat model in week one. Not a forty-slide compliance deck that someone made three years ago and hasn’t updated since — a real conversation about what you protect, what your attack surface looks like, and where the bodies are buried. Not all engineers understand the basics like SQL injection or privilege escalation, and that’s fine. That’s what onboarding is for. Having real examples of past vulnerabilities as part of your onboarding material isn’t just a good idea — it’s those bodies I mentioned. Show them the scars so they know where not to step.
Hack your own stuff. Run an internal hack day. Let engineers try to break their own services. If you have multiple teams, have them hack each other’s systems. This does two things: it finds real vulnerabilities, and it builds empathy for what attackers actually do. An engineer who has exploited an XSS vulnerability in their colleague’s service never forgets to sanitise input again. There’s a visceral difference between reading about a vulnerability in a textbook and watching your own code fold like a cheap chair when someone actually tries to exploit it. And if you’re worried about your team’s skills — maybe you don’t have a John yet — hire a consultancy to send some experts to pair with your people. The knowledge transfer from a single day of guided hacking is worth more than a year of security awareness slides.
I know CTF events are popular, and they have their place, but I find they’re too far removed from the real work for non-security engineers. Hacking your own stuff is closer to the metal, more immediately relevant, and frankly, more fun. There’s something deeply satisfying about finding a vulnerability in a service your mate built and sending them a screenshot with a suitably smug message.
Make it social, not punitive. The moment security becomes about blame is the moment people start hiding problems. Frame it as a puzzle, a challenge, something interesting — because it genuinely is. Security is one of the few engineering disciplines where you’re actively trying to think like an adversary. That’s inherently fascinating if you let it be, and thoroughly demoralising if you turn it into a game of “whose fault is this.”
After the Apollo 1 disaster killed three astronauts, NASA Flight Director Gene Kranz stood in front of his team and delivered what became known as the Kranz Dictum. He didn’t assign blame. He didn’t fire anyone. He said: “Somewhere, somehow, we screwed up. It could have been in design, build, or test. Whatever it was, we should have caught it.” Then he told them to write “Tough and Competent” on their blackboards, and never erase it.
That’s a security culture. Not “who did this,” but “how do we make sure this never happens again.” The distinction matters more than most leaders realise.
Scaling With Automation
This is where we prevent security from becoming a tax on velocity. And here’s the key reframe: if security slows you down, you’ve implemented it wrong.
Security automation should feel like guard rails on a mountain road — you barely notice they’re there until they save your life. Not like a toll booth that charges you eight minutes every time you want to merge code.
What goes into the pipeline:
Dependency scanning for your packages — tools like Dependabot, Renovate, or Snyk that catch known vulnerabilities in your supply chain. Docker image scanning for vulnerabilities in your containers. SAST running in parallel with your build, not blocking it. Pre-commit hooks catching secrets before they hit the repo — because the number of API keys and database passwords that have been committed to version control in the history of software engineering would make you weep. And external scanning tools for your public-facing surfaces, with pen tests on a regular cadence.
But here’s the thing most people miss — automation will only get you so far. A scanner that finds two hundred vulnerabilities and dumps them into a backlog isn’t security. It’s noise. Which is exactly why culture comes first in this post. The automation serves the culture, not the other way around.
And you need to watch what the automation is doing to your teams. Track false positive rates. Track pipeline stability and the time impact on every build. A security scanner that adds eight minutes to every build and produces sixty percent false positives will actively erode the security culture you’re trying to build. Engineers will learn to ignore the alerts, which is categorically worse than not scanning at all. You’ve trained your people that security warnings don’t matter. Good luck undoing that.
Measuring What Matters
You should be doing this from the start, building your measurement capability slowly as you roll deeper into security with growth. You don’t instrument everything on day one. You start with what John sets up, refine as you build culture, and by the time you’re ready for a formal security team, you’re handing them real data instead of asking them to start from scratch.
Time to Discovery is arguably your most important leading indicator. How long did a vulnerability exist before you found it? Git tells you when it was introduced. Your security tooling tells you when it was detected. The gap between those two dates is your exposure window — the amount of time an attacker could have exploited something you didn’t know about. Shrink that gap relentlessly.
Time to Resolution — how long between finding a vulnerability and fixing it? Break this down by severity. Your P1s should be hours to days. Your lows might be weeks. The point is having a conscious policy rather than “whenever someone gets to it,” which is how most teams operate and is another way of saying “never.”
Security Incidents in Production is the ultimate lagging indicator, but tricky to use as a measure of success. High and critical incidents are — hopefully — rare enough that you can’t derive trends from them. Medium and low incidents are more common but harder to benchmark externally. You almost need to track this just to establish your own baseline and trend direction, not to compare against some external standard that probably doesn’t map to your context anyway.
Automation Effectiveness is the metric that keeps your tooling honest. For each scanning tool: true positive rate, false positive rate, pipeline time impact, pipeline stability impact. This tells you whether your automation is helping or generating noise. A tool with a high false positive rate is actively training your engineers to ignore alerts — which, as I mentioned, is the worst possible outcome.
The broader point: these metrics build over time. They’re a compounding investment. The earlier you start, even crudely, the more powerful the story you can tell when you need to justify security investment to leadership.
When You’re Ready for a Real Security Team
This usually happens at hundreds of engineers. It’s usually a small team. But it depends entirely on your business context — if you’re a fintech, a security team might be your second or third hire after your founding engineers. If you’re building a content platform, you might get further before you need dedicated headcount.
But here’s the argument that matters: a security team that inherits a culture is fundamentally different from a security team that has to create one.
The former are partners and enablers. They walk into an organisation where engineers already think about authentication flows, where dependency scanning is part of the pipeline, where people voluntarily attend hack days and actually enjoy them. The security team’s job becomes amplifying and formalising what already exists. In Team Topologies terms, they’re an enabling team — they make everyone else better at security rather than being the only people who care about it.
The latter — the security team that has to create a culture from scratch — become gatekeepers and blockers. Not because they want to, but because they have no other lever. When nobody else cares, the only way to enforce security is to stand in the way of things and say no. And nobody likes the team that says no. So they get resented, their recommendations get ignored or worked around, and you end up with security theatre: a team that exists so leadership can say “we have a security team” while the actual security posture remains unchanged.
Give the security team the measurements you’ve built. Let them take ownership of the metrics, the tooling, the processes. Their job isn’t to be the only people who care about security. Their job is to make everyone else better at it.
The Uncomfortable Truth
You probably have three or four vulnerabilities in your system right now that would make you deeply uncomfortable if you knew about them. The only question is whether you find them or someone else does.
Security isn’t a feature you ship. It’s not a sprint goal or a quarterly OKR you can mark complete and move on. It’s a discipline — a way of thinking that either permeates how your organisation builds software, or doesn’t. And if it doesn’t, no amount of tooling, compliance checklists, or penetration tests will save you when it matters.
Start with your John. Build a culture where security is interesting, not punitive. Automate intelligently, not comprehensively. Measure what matters, even crudely at first. And when you’re ready, formalise it with a team that inherits a culture rather than being asked to build one from the ashes of an incident.
Because the alternative is learning these lessons the hard way. And trust me — reading about PCI DSS compliance requirements in a quiet office is considerably more pleasant than reading about your company’s data breach in the morning news.
Now, if you’ll excuse me, I need to go check when we last rotated those API keys. I’m sure it was recent. Fairly sure. Mostly sure.