AppSec Is Drowning in Noise — What Are We Actually Protecting?

Search for a command to run...

No comments yet. Be the first to comment.
I am in no way an authority or an expert on this topic; I am merely expressing my thoughts on a subject I am extremely passionate about and wish to improve. Areas where I would like to see improvement: Failure to plan ahead Most companies don’t under...
I was working on a new app and came across Matt Pocock's /grill-with-docs skill that works as a structured interrogation tool that stress-tests your plan against your project's domain model, cross-ref

Building a normalised finding schema across six scanners and an MCP layer that lets developers, security engineers, and CI pipelines query, fix, and verify vulnerabilities, all from the tools they already have open.

Why the assumption that CI/CD is a trusted internal tool has already cost organisations dearly

Part 1 - Lab setup, attacker simulation, and finding exploitable misconfigurations

Securing AI: Microsoft Shares Key Research Findings

Application security was supposed to be a safety net. Lately, it feels more like quicksand.
Modern AppSec teams are swamped by an endless stream of alerts. The report found on thehackernews.com prompted me to think about this issue (https://thehackernews.com/2025/05/new-research-reveals-95-of-appsec-fixes.html). OX Security reports that 95–98% of these are non-actionable, with only 202 out of nearly 570,000 alerts per organization representing true, critical issues. Let that sink in: almost everything flagged isn’t actually worth doing anything about. It's no wonder security professionals are burning out — we’ve built systems that demand constant vigilance but rarely deliver clarity.
Here's the uncomfortable truth: when security becomes a bottleneck, the business sees it as friction. Not value.
The consequences of alert fatigue are multifaceted:
Burnout and Turnover: Continuous exposure to non-critical alerts leads to desensitization and burnout among security.
Delayed Response to Real Threats: Critical vulnerabilities may be overlooked amidst the noise, increasing the risk of breaches.
Erosion of Trust: Developers may become skeptical of security tools that frequently flag non-issues, leading to friction between development and security teams.
Automation helps. But it doesn’t solve everything. There are still massive blind spots:
Many tools focus narrowly on code-level issues, overlooking systemic risks such as insecure architecture decisions, poor secrets management, or improper access controls at the infrastructure level.
Tools may fail to consider the business context—what’s a critical flaw in one app might be low-risk in another.
Third-party dependencies and open-source libraries introduce supply chain risks that are difficult to detect with conventional static or dynamic analysis.
These blind spots emphasize the need for human judgment, threat modeling, and cross-functional collaboration to build a more complete and effective AppSec strategy.
If AppSec is going to deliver real value — to the business, to engineering, and to security teams themselves — it might be time to rethink how we approach it. Here are some ways organizations can begin to shift from reactive noise to meaningful impact:
Start prioritizing risk, not just volume
Instead of treating every alert equally, consider building a risk-based approach that looks at exploitability, business context, and asset criticality. This doesn't have to mean building a complex scoring system — even simple prioritization rules, based on known business priorities, can help teams focus their time more effectively.
Embed security earlier — but with empathy
“Shift left” doesn’t just mean adding more scanners to your CI/CD pipeline. It means involving security in architecture discussions, design reviews, and sprint planning in a way that supports — not slows — developers. The goal is to make security feel like a partner in building, not a gatekeeper after the fact.
Make continuous learning a team habit
Security training shouldn’t be a once-a-year compliance exercise. Whether it’s monthly threat briefings, hands-on labs, or informal lunch-and-learns, finding lightweight, regular ways to upskill both engineering and security teams can go a long way. Peer-led sessions or gamified exercises can help make it stick.
Treat AppSec as an evolving product
Instead of managing AppSec like a static checklist, think of it as something iterative — like a product you’re building for internal teams. Collect feedback, measure adoption of security tooling and practices, and be willing to adjust based on what’s actually helping developers ship safer code.
Make better use of threat intelligence
Used well, it can help inform patching decisions, improve alert tuning, and provide early warning signs of emerging risks. Consider mapping external threat trends to your own systems and software stack — even just quarterly — to guide where to focus.
At its core, this isn’t just a tooling problem — it’s a focus problem.
AppSec was never meant to be about chasing every alert. The real goal is to protect the business by helping teams build and ship safely, without slowing them down. It's about enabling developers to move fast with confidence, while keeping risk to a minimum.
But somewhere along the way, we got buried in noise — dashboards, false positives, and endless triage that pull us away from what actually matters.
If we can cut through that noise and refocus on what counts, AppSec stops being a blocker — and starts showing up as the strategic partner that supports the company’s overall goals.