Security teams love to talk about coverage: percentage of repos scanned, percentage of endpoints with EDR, percentage of services behind SSO. What almost nobody tracks is the metric that actually predicts whether any of that coverage holds up under pressure: friction. Every security control adds steps to a developer's day, and every added step is a small bet that the value outweighs the annoyance. When that bet loses — when a scanner blocks a deploy at 6pm on a Friday, when a CLI wrapper adds 40 seconds to git push, when MFA prompts fire every time a laptop sleeps — developers don't file a ticket. They route around it. In March 2024, the xz backdoor was caught not by a security tool but by a Microsoft engineer annoyed that SSH logins were 500 milliseconds slower than usual. That's friction working for security, by accident. Most of the time it works against it, silently, and nobody measures the difference.
What Actually Counts as "Friction" in a Developer Workflow?
Friction is any point where a security control adds time, context-switching, or uncertainty to a task a developer was already going to do. It's not just "the tool is slow" — it's the cumulative tax of interruptions. A pre-commit hook that adds 3 seconds is friction. A SAST scanner that takes 12 minutes on a PR that used to merge in 90 seconds is friction. A secrets-scanning bot that flags false positives on 1 in 4 commits is friction that compounds, because developers learn to dismiss the next 3 alerts without reading them. GitHub's own 2022 developer survey found that engineers lose an average of 8.5 hours a week to inefficient processes and tooling, and security tooling is consistently named as one of the top three offenders alongside CI flakiness and code review delays. The point isn't that controls should be free — it's that unmeasured friction accumulates until someone quietly disables the pre-commit hook with --no-verify and nobody notices for six months.
Why Do Developers Bypass Approved Security Tools Instead of Just Complaining?
Because bypassing is faster than escalating, and escalating rarely gets a fix shipped before the sprint ends. A 2023 GitGuardian survey found that 75% of developers admitted to disabling or working around a security tool at least once, most commonly a linter, a pre-commit scanner, or a VPN requirement that broke local development. This isn't rebellion — it's the path of least resistance under deadline pressure. The --no-verify flag exists precisely because Git assumes hooks will occasionally need to be skipped, and once a developer discovers it solves their immediate problem, it becomes muscle memory. The same pattern shows up with corporate VPNs: when a mandatory VPN adds 200-400ms of latency to every API call during local development, engineers install split-tunnel workarounds or route through personal hotspots — not because they don't care about security, but because a broken local dev loop costs them the entire afternoon. Friction that isn't measured gets solved by the person experiencing it, using whatever tool is fastest, and that tool is rarely the security team's.
How Much Adoption Failure Comes From Rollout Timing Rather Than the Tool Itself?
A significant share, and it's almost entirely avoidable. Okta's own incident history is instructive here: MFA fatigue attacks against Uber (September 2022) and Cisco (May 2022) succeeded not because MFA is weak, but because employees had been trained by months of poorly-timed, unexplained push notifications to tap "approve" reflexively just to make the interruption stop. That's a rollout failure disguised as a technology failure — the control was sound, but the friction of constant unexplained prompts trained exactly the wrong behavior. Compare that to phased rollouts with number-matching MFA, which Microsoft reported cut fatigue-attack success rates dramatically after making broad by late 2022 specifically because the added step (typing a two-digit code) restored intentionality to the approval action. The lesson: the same control can produce opposite security outcomes depending on whether the friction is designed to prompt thought or just designed to be tolerated.
Can Tool Adoption Failure Be Measured Before It Causes a Breach?
Yes, and the leading indicators show up weeks before an incident, not after. Time-to-first-bypass, percentage of scans run with --skip or equivalent flags, the ratio of alerts triaged versus dismissed, and the delta between a tool's stated adoption rate (installed) versus its functional adoption rate (actually blocking bad commits) are all measurable today with commit metadata and CI logs most orgs already have. The 2021 Codecov supply chain compromise went undetected for roughly two months (December 2020 to April 2021) partly because the modified Bash Uploader script was flagged by some internal checks that engineering teams had learned to route around due to prior false-positive fatigue. If someone had been tracking dismissal rate as a metric — not just scan coverage — the anomalous script modification pattern would have been a statistical outlier worth a second look, not just one more alert in a queue with a 90% dismissal rate. Friction metrics turn "the tool didn't catch it" into "the tool caught it and got ignored," which is a completely different, and more fixable, problem.
What Happened When ua-parser-js Showed Why Low-Friction Compromise Beats High-Friction Detection?
In October 2021, three versions of the popular npm package ua-parser-js (used in an estimated 8 million weekly downloads at the time) were compromised to install a cryptominer and credential-stealing malware, and it propagated through CI pipelines before most teams's dependency-scanning tools even flagged the version bump. The attack succeeded because automatic dependency updates were configured for low friction — that's the entire selling point of tools like Dependabot and Renovate — while the security review of what changed inside a patch version was, for most teams, effectively zero friction in the wrong direction: nothing stopped, nothing questioned, nothing reviewed. The incident is a clean illustration of the core tension: friction removed from developer workflows for velocity is friction that has to be re-inserted somewhere else in the pipeline, deliberately, or it simply doesn't exist. Teams that had SBOM generation and provenance checks wired into their CI caught the compromised versions within hours; teams that relied on scan-after-merge caught it during the next quarterly audit, months later.
Does More Security Tooling Always Mean Less Friction-Driven Risk?
No — past a certain point, adding tools increases friction-driven risk by fragmenting developer attention across more places to get an alert wrong. A 2023 IBM Cost of a Data Breach report noted that organizations using more than 50 security tools scored lower on average threat detection and response capability than those using a more consolidated stack, largely attributed to alert fatigue and tool-switching overhead. Each additional scanner, each additional login, each additional Slack bot posting findings is one more surface where a developer decides "I'll deal with this later" and later never comes. The goal isn't zero tools or zero friction — some friction is the entire point of a control, like requiring a second approver on a production deploy. The goal is knowing, per control, whether the friction it introduces is buying proportional security value, and cutting the ones that are pure tax.
How Safeguard Helps
Safeguard treats friction as a first-class security signal instead of an assumed cost of doing business. Instead of just reporting on scan coverage, Safeguard instruments the actual developer interaction with security controls across the software supply chain — commit hooks, CI gates, dependency approvals, SBOM generation — and surfaces where bypass rates, dismissal rates, and time-to-workaround are climbing before they turn into blind spots. That means visibility into which pipelines are running with security checks silently skipped, which dependency updates are merging with zero review because reviewer fatigue set in months ago, and which teams have quietly forked their own faster, unmonitored path around a mandated control.
On the supply chain side specifically, Safeguard's provenance and SBOM tooling is built to add verification without adding developer-facing latency — checks run in parallel with existing CI rather than blocking it, and findings are prioritized by exploitability so engineers aren't triaging noise, which is precisely the failure mode that let incidents like ua-parser-js and Codecov linger. For compliance-driven teams working toward SOC 2 or similar frameworks, Safeguard also gives security and platform leadership a friction dashboard alongside the compliance dashboard, so a control that's technically "deployed" but functionally bypassed by 80% of engineers doesn't get counted as coverage it doesn't actually provide. The result is a supply chain security posture measured by what's actually happening in the pipeline, not what's nominally installed in it — which is the only version of that measurement that predicts what happens during the next incident.