Every CISO I’ve ever spoken to has a version of the same conversation at least once a quarter. A vendor calls. The pitch is some variation of: “Our platform finds vulnerabilities faster, with fewer false positives, and integrates with your existing workflow.” The demo looks good. The dashboard is clean. The marketing says it’ll reduce your mean time to remediation by 60%.
So the tool gets bought. It gets deployed. It starts generating findings. Hundreds of them. The security team triages what they can. The rest goes into a backlog. Six months later the backlog is longer than when they started, the developers have learned to ignore the alerts, and the CISO is having the same conversation with a different vendor about a different tool that promises to fix the problem the last tool was supposed to fix.
I want to be upfront: I’m not arguing that security tools are bad. Some of them are excellent. They solve real problems, and the market exists for good reason. What I’m questioning is the order of operations — and what happens when organisations buy tools before they’ve built the foundation those tools need to be useful.
The buying problem
The security tooling market has a product for every category. Static analysis, dynamic testing, software composition analysis, cloud security posture management, container security, API security. If you can name it, someone is selling it. Most of these tools do what they claim — they find things. That part works.
What doesn’t work is what happens after.
A scanner finds a SQL injection. It flags it as critical. The ticket goes to a developer. The developer looks at it, doesn’t recognise the code path, doesn’t understand the scanner’s output format, and has three sprint commitments due this week. The ticket sits. The next scan runs. The same finding appears again, plus twelve new ones. The backlog grows. The dashboard turns redder. The quarterly security report looks worse. Someone suggests buying another tool to help prioritise the findings from the first tool.
I’ve seen this cycle at organisations spending serious money on tooling and getting no measurable improvement in their actual security posture. The tools are running. The dashboards are full. The number of unresolved vulnerabilities stays flat or climbs.
The problem isn’t the tools. It’s that the tools were brought in to compensate for processes, policies, and team practices that didn’t exist yet. A CSPM tool that’s capable of powering proper risk management gets reduced to a ticket-flooding machine — dumping hundreds of findings into a ticketing system with no prioritisation, no business context, and no ownership. Teams then complain about missing details in the tickets instead of working on the actual risks. The tool can do more. But nobody set up the foundation for it to do its job.
This isn’t a tooling problem. It’s a buying problem. Organisations purchase tools because a peer company has one, or because a vendor demo looked compelling, or because an auditor asked “what tools do you use?” — and treat the purchase as progress. The tool becomes the strategy instead of a layer on top of one.
What happens when you start with the foundation
I had an engagement where the client’s CISO trusted me to run the security programme across their codebase. The starting state was bad — confirmed vulnerabilities across dozens of repositories, including issues that worked in both static and dynamic testing, APIs with no authentication at all, and extensive third-party library exposure.
There was budget for tooling. Enough for some platforms, not enough for others. But before committing to a purchase, I raised the same concern I’ve been describing in the paragraphs above — if the processes and practices aren’t in place first, the tool becomes a ticket-flooding machine regardless of how good it is. The recommendation was to set up usable policies and working practices, get the teams operating on a solid foundation, and then decide which tools — if any — would genuinely add value on top of what was already working.
The result: zero commercial tooling cost. Open-source tools covered what was needed for scanning and dependency checking. The budget that would have gone to platform licenses went into the work that actually moved the numbers — code reviews, threat models, developer enablement, and building a security culture that could sustain itself.
The answer was slower and less impressive-sounding than deploying a scanner, but it worked.
Code reviews. Manual, human, context-aware code reviews. Not “review against a checklist” — reviews where the person reading the code understood the business logic, understood the framework, and could explain to the developer not just what was wrong but why it was wrong and how to think about it differently next time. The difference between “this input is unsanitised” and “here’s what an attacker can do with this parameter given how your API handles authentication upstream” is the difference between a finding and an education.
Back then, all of this was manual. Every code review, every contextual explanation, every suggested fix — written by a human who knew the codebase. It worked, but it was labour-intensive in a way that made people ask whether it could scale. Today, LLMs have changed that equation. The kind of context-aware code analysis that used to require a senior security engineer spending hours in a codebase can now be partially automated — not the judgement, but the heavy lifting of understanding file relationships, mapping dependencies, and producing findings with enough context to be actionable. That’s the direction I’m building in with my own tooling, and it’s a direction the industry is moving in broadly. The workflow that proved itself manually is now becoming scalable.
Threat models written with the developers, specific to their applications. Not generic STRIDE templates — actual models of their specific architecture, their specific data flows, the specific ways their system could be abused. When a developer has sat through the process of modelling their own application’s attack surface, they start seeing those patterns in their own code before anyone points them out.
Secure coding guidelines that the developers helped write. Short, specific, tied to their stack, written in language that made sense to the people who’d be following them. Developers followed these because they’d had a hand in shaping them — not because an audit required it.
Suggested code fixes on every finding. Not “remediate this vulnerability” — actual code. Specific to their codebase, their language, their framework. Back when none of this could be automated, it was all manual work. But it meant the developer receiving a ticket could see exactly what needed to change, in context, and could push a fix within hours instead of spending days figuring out what the security team was even asking for.
What moved
Over the course of that engagement, the confirmed issue count dropped to a fraction of where it started. The classes of vulnerability that had been systemic — injection, missing authentication, unmanaged dependencies — were addressed at the root, not just patched individually.
You could have deployed a commercial scanner against those repositories at the end and it wouldn’t have told you much. Not because the tools would have been wrong — because there wasn’t much left to find.
A scanner can find a vulnerability. It cannot teach a developer to stop writing them. It cannot build the trust between a security team and a dev team that makes remediation feel like collaboration instead of punishment. It cannot look at a finding and say “this is critical in your environment because of how your upstream auth works, but it would be a non-issue in a different architecture.” All of that requires a human who understands the codebase, the business context, and the team.
That’s the foundation. Once it’s in place, tools become powerful — they amplify what’s already working. A SAST scanner running against a codebase where developers already understand secure coding patterns catches the edge cases that slip through, instead of drowning people in findings they don’t know what to do with. A CSPM tool deployed into an environment where teams already have risk management processes and clear ownership dashboards becomes a force multiplier, not a noise generator.
The order matters. Process first, then tools. Not tools first and hope the process follows.
The honest part
I’d be lying if I said this approach has no drawbacks.
It’s labour-intensive. Manual code reviews, custom threat models, hand-written fixes — that’s a lot of hours. It depends heavily on the quality and experience of the people doing the work. It worked at this engagement because there was time, trust, and sustained access.
The harder question — and one I haven’t fully answered — is whether this scales. Can you train developers well enough that the secure coding culture persists after the engagement ends? Can you build the process once and have it sustain itself? Or does it require someone in the room, consistently, holding the standard?
At that particular client, the answer so far is encouraging. The practices stuck. The codebase stayed clean. But it was one engagement, with one team, under specific conditions. I’m not going to claim it’s a universal model based on one data point, even a strong one.
Tools as a layer, not a strategy
The security tooling market is going to keep growing. New categories will emerge. Existing tools will get better. AI will make detection smarter and faster. None of that is bad. Some of it will be genuinely transformative.
But a tool deployed into an organisation without working processes, without clear ownership, without developer buy-in — that tool will produce dashboards, not outcomes. The gap between “finding a vulnerability” and “fixing it in a way that prevents the next one” is not a detection problem. It’s a knowledge problem, a relationship problem, and a prioritisation problem.
Get your basics right first. Build the processes and policies that work for your teams — not adapted from a vendor’s template, but built from how your teams actually operate. Then add tools as a layer to strengthen what’s already working. Don’t buy the shiny thing because your neighbour has it. Buy it because you’ve built the foundation for it to do its job.
The most expensive tool in the world can’t compensate for a process that doesn’t exist. The right tool on top of the right foundation is worth every penny.
Uncategorized 
Leave a comment