SAN FRANCISCO — July 6, 2026. Nearly two-thirds of developers say they have shipped code they knew contained an unresolved security warning, and more than half say they have disabled or ignored a security tool at least once in the past year because it slowed them down. Those are the headline findings from Safeguard's newly released 2026 Developer Security Friction Survey, a poll of 540 software engineers, tech leads, and DevOps practitioners across North America and Europe, fielded between April and May 2026.
The survey — one of the more granular looks yet at how security tooling actually lands on the people who have to use it every day — paints a picture that will feel familiar to anyone who has sat through a post-incident retro: security and developer velocity are still treated as competing priorities inside most SDLCs, and when the two collide, security usually loses. Not because developers don't care about it, but because the tooling asked of them frequently fails to respect their time, their workflow, or their judgment.
The Numbers Behind the Friction
The topline figures from Safeguard's survey are worth sitting with:
- 68% of respondents said their organization runs three or more distinct security scanning tools (SAST, SCA, secrets, container, IaC) across the SDLC, often with overlapping or contradictory findings on the same pull request.
- 61% reported that more than half of the vulnerability alerts they triage turn out to be false positives or non-exploitable in their specific code path.
- 54% said they had disabled, muted, or bypassed a security gate at least once in the past 12 months specifically because it was blocking a release without a clear justification.
- 47% said they spend more time each week investigating and dismissing security findings than they spend fixing genuinely exploitable issues.
- 39% said their organization has no clear, documented process for a developer to challenge or triage a finding — meaning the default behavior when uncertain is either to ignore it or escalate it, both of which add delay.
Perhaps the most telling data point: when asked to rank the qualities they most wanted from a security tool, "tells me if this is actually reachable/exploitable in my code" outranked "comprehensive coverage" and "fast scan speed" combined. Developers are not asking for less security. They are asking for security that is honest about what actually matters.
Where Friction Concentrates: SBOMs, Alert Fatigue, and Tool Sprawl
Three specific friction points recurred across open-ended survey responses.
Software bill of materials (SBOM) obligations are landing on engineering teams with little tooling support. With SBOM generation increasingly required by customers, regulators, and internal compliance mandates, 44% of respondents said they had been asked to produce or update an SBOM manually or with disconnected tooling in the past year. Fewer than a third said their organization had a way to continuously generate SBOMs as part of the build pipeline, let alone ingest and reconcile SBOMs received from vendors. The result is SBOM generation treated as a point-in-time compliance exercise rather than a living artifact — which means it's stale by the time anyone reads it, and someone has to redo the work at the next audit.
Alert fatigue remains the single largest driver of tool abandonment. This is not a new finding — security teams have talked about "alert fatigue" for years — but the survey's granularity shows it's specifically the undifferentiated volume of findings, not their existence, that erodes trust. Developers who received prioritized findings (ranked by actual exploitability or business impact) reported dramatically higher tool satisfaction than developers who received a flat list of every CVE matched against their dependency tree, regardless of whether the vulnerable function was ever called.
Tool sprawl compounds both problems. With multiple scanners producing overlapping findings in different formats, developers described spending time simply reconciling which tool's finding to trust, before they even got to remediation. One respondent's comment, echoed in similar language by several others: "I don't need five tools telling me about the same CVE five different ways. I need one tool telling me if it's actually a problem, and how to fix it."
The Cost of Ignoring Developer Experience
Security leaders sometimes treat developer friction as a soft, secondary concern relative to coverage and compliance. The survey data suggests that framing is backwards — friction is a leading indicator of security posture, not a side effect of it.
Organizations where respondents reported high friction (frequent false positives, no triage process, tool sprawl) were more than twice as likely to report having bypassed a release gate in the past quarter compared to organizations with lower reported friction. That correlation matters because a bypassed gate isn't a hypothetical risk — it's a real vulnerability, a real exposed secret, or a real vulnerable dependency shipped to production specifically because the process around catching it was too costly for developers to follow. Every friction point that pushes a security control toward being ignored is, functionally, a control that has already failed.
There's also a retention and morale dimension the survey surfaced almost as a footnote but which deserves more attention: 31% of respondents said friction with security tooling was a contributing factor in considering a job change, roughly on par with complaints about build times and CI reliability. Security friction isn't just a compliance risk anymore — it's an engineering experience problem with retention consequences.
What Security Leaders Should Take Away
Three practical conclusions fall out of this data for anyone running an AppSec or platform security program:
-
Prioritization is not optional. If a scanner cannot distinguish between "this CVE exists in a dependency" and "this CVE is reachable from code your service actually executes," it will train developers to distrust and eventually ignore its output — regardless of how comprehensive its CVE database is.
-
SBOM work has to be continuous, not episodic. Manual, point-in-time SBOM generation is a compliance checkbox, not a security control. Teams that automate SBOM generation into the build and can ingest and reconcile third-party SBOMs are the ones who can actually answer "are we affected by this" within hours of a new CVE, rather than days.
-
Remediation guidance beats remediation notification. Developers overwhelmingly said a fix suggestion or automated patch — even one they still had to review — was worth more to them than a well-written explanation of the vulnerability. Telling a developer what's wrong without telling them how to fix it fast is most of what generates friction in the first place.
None of these are radical ideas. What the survey adds is confirmation, at scale and from the people actually doing the work, that the industry's stated priorities (shift-left, DevSecOps, "security as code") only succeed when the tooling underneath them respects developer time as a finite and valuable resource.
How Safeguard Helps
Safeguard was built around the premise that this survey validates: security signal is only useful if developers can act on it quickly and trust it's real. Our reachability analysis engine filters vulnerability findings down to the ones an application can actually execute, cutting through the false-positive volume that respondents cited as their top source of alert fatigue. Griffin AI, Safeguard's investigation and remediation assistant, triages findings automatically and drafts context-aware auto-fix pull requests so developers spend their time reviewing a fix rather than researching one from scratch. Safeguard also automates continuous SBOM generation across every build and can ingest third-party SBOMs to reconcile your full software supply chain in one place, replacing the manual, point-in-time compliance exercise nearly half of surveyed developers described. Together, these capabilities are designed to close the gap this survey identifies — turning security tooling from a source of friction back into a trusted part of how software gets shipped.