Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:
Every week, I scroll through my LinkedIn feed for inspiration. Sometimes, I’m hoping to catch wind of a major security incident; other times, I’m just looking for interesting posts. Recently, I found myself reading a string of posts, all sharing a similar sentiment: that much of the security industry is focused on the wrong problems. There’s too much theater over substance and too much noise over signal:
To be honest, I agree, but not because those risks don’t matter. It’s because many of them aren’t the right problems to prioritize today. Security, like every other discipline, faces constraints. We don’t have infinite time, resources, or attention. Every hour spent chasing down a low-priority CVE or purchasing yet another compliance tool is an hour not spent tackling systemic product risks, reducing credential blast radius, or fixing IAM misconfigurations.
The Real Effectiveness Problem
My frustration isn’t with any one post or issue, but with the pattern. We discuss security problems in isolation, without enough context or nuance. It’s easier that way, but it's also a trap. We end up treating every issue as urgent and worth fixing, which leads to bloated roadmaps, unclear priorities, and security teams that lose credibility with the business. I’ve talked about this issue before, where it seems like there’s so much activity in security with new tools and awareness, but why don’t things feel like they are getting better?
We’ve gotten away with this for a while. For the last decade, security was largely underfunded. That scarcity created a mindset of always asking for more, often without a clear sense of ROI. But in recent years, many companies have increased their security budgets, and I think we’re now seeing the other side of the pendulum swing: overinvestment without results.
There are more vendors, more dashboards, and more headcount, but has security become proportionally more effective? In most companies, no.
One of the most powerful things a security team can do is say, "This isn't worth fixing right now." That statement builds credibility. It shows that you understand tradeoffs and are thinking like a business owner.
For instance:
It’s okay to miss some security incidents, especially if the ROI of trying to detect them is low.
It’s okay to de-prioritize fixing low-severity CVEs.
It’s okay to delay a third-party risk review if the vendor isn’t accessing anything sensitive.
The point isn’t to ignore risk but to be intentional about what you focus on.
Take identity and access management (IAM). Over 80% of breaches involve compromised credentials. That tells me we should over-invest here: strong auth, short-lived credentials, good session management, and tight privilege boundaries.
Where Security Is Overinvested
Let’s start with the obvious: there are too many tools. This has been a recurring theme in my blog, where I have said that having more tools has made security easier, but there are too many tools now, that’s made security distracting and has taken up unnecessary cognitive load.
Most security stacks are cluttered with vendors solving overlapping or low-leverage problems. Posture management, appsec scanners, code security overlays, and observability add-ons. Many of them promise coverage, but deliver little actionable value.
This is especially true in categories like:
Compliance automation and third-party risk tools: Helpful at first, but quickly become checkbox exercises. It feels like something you can build easily with enough engineering support.
SAST/SCA tools: Many produce noisy results, don’t integrate well into engineering workflows, and require excessive tuning.
Detection tools with bespoke stacks: Why does security need its own data pipeline? Use what your engineers use. Datadog, Snowflake, or BigQuery can absolutely support security use cases.
These tools often feel like a workaround for poor relationships with engineering. Instead of collaborating, security teams buy (not even build!) parallel infrastructure. That increases cost and reduces leverage.
Most importantly, tooling isn’t a solution or strategy by itself. Tools should help you solve problems faster, but in security, they often become the end instead of the means.
Every tool comes with administrative overhead: alerts to triage, integrations to build, and configs to tune. Some tools require whole teams to maintain. That’s not cost-effective.
In fact, sometimes it’s cheaper to build a simple solution in-house with AI assistance. Between open source, LLM copilots, and infra-as-code, small teams can move fast again. Buying a tool should be a last resort, not the first instinct.
What Should We Invest In?
Problem-solving, and the people who can do it.
Historically, security was solved with fewer tools. Now, we seem to be solving less with more. We’ve over-rotated toward management of tools, of dashboards, of people and under-rotated on engineering/building.
I’ve said before: security needs to build again. And that means:
Hiring engineers who can dive into systems and fix things.
Giving security teams the time and space to go deep on core problems.
Measuring outcomes, not activity.
We shouldn’t optimize for the size of the security org or how many risks we can surface. We should optimize for how many meaningful risks we can reduce.
Of course, not all tools are bad. Some categories are worth investing in, particularly those that:
Free up time: Compliance automation, reporting workflows, IAM delegation, etc.
Leverage unique data: EDRs and email security tools can be effective if they see a wide dataset across customers.
Aren’t strategic to build: Let someone else solve the horizontal problems so your team can focus on the business-specific ones.
Tools should give you leverage. But they should also fade into the background. They aren’t the strategy, just part of the implementation.
We’re already seeing this across other orgs. The rise of AI is flattening engineering organizations with fewer layers, more builders, and leaner teams that ship faster. Security should follow suit.
That doesn’t mean going back to the days of one security person doing everything. But it does mean resisting the urge to build sprawling empires of tickets, dashboards, and reports. A great security org looks more like a platform team, which is deeply integrated with engineering, enabling others, solving hard problems, and scaling through automation.
That means:
Building guardrails that reduce risk without blocking velocity.
Focusing on product-specific issues, not just generic security concerns.
Avoiding friction by offering solutions, not just problems.
Final Thought
Security is ultimately a resource allocation problem. We will never have the budget, headcount, or tooling to chase every possible issue and risk, so we need to focus.
That focus doesn’t come from vendor roadmaps or compliance checklists. It comes from talking to engineering, understanding product risk, and deciding what actually matters. It’s time we invest accordingly.