We've done a lot of customer discovery calls over the past year, and one pattern keeps showing up: the teams with the best security outcomes are not the ones with the most comprehensive scanning coverage. They're the ones whose developers actually use the security tooling. High adoption rates beat high detection rates every time, because a finding that gets fixed beats a finding that sits in a backlog indefinitely. This is the developer experience problem in application security, and the industry has been slow to take it seriously.
The Adoption Gap Nobody Measures
Most AppSec vendors report detection metrics: how many vulnerabilities found, what severity, how many CVEs in the database. Very few report adoption metrics: what percentage of developers open findings in the tool, what percentage take action within 7 days, what percentage of the engineering team can describe what the security tool does.
In our conversations with engineering and security leads at growing US tech companies, the adoption gap is real and large. At teams using traditional SAST-only tooling, fewer than 30% of developers actively engage with security findings. The rest route around the process — either the findings are suppressed at the manager level, they sit in a ticket backlog that nobody processes, or developers have learned that security gates can be bypassed with a comment in the PR. This isn't unusual. It's the median.
The gap exists because traditional security tools were designed for security teams, not for developers. The workflow assumes a security analyst who knows what CVE-2024-XXXXX means, can assess exploitability from a description, and has the organizational authority to prioritize fixes. But most engineering teams don't have that person embedded in their workflow. They have developers who need to ship features and have been conditioned to treat security alerts as noise — because historically, most of them were.
A security tool that is 95% accurate but used by 20% of developers will find fewer real vulnerabilities than one that is 85% accurate but used by 80% of developers. Adoption is the multiplier.
What Actually Drives Developer Adoption
We've looked at this closely enough to have some views on which factors drive adoption versus which don't. The data comes from usage patterns across teams that have deployed Runtimekindle, supplemented by structured interviews with both adopters and teams where adoption stalled.
Signal-to-noise ratio is the primary driver. Developers who receive 50 security findings per sprint and find 3 of them to be legitimate, actionable issues stop looking at findings. Developers who receive 6 findings and find 5 of them to be legitimate, actionable issues stay engaged. The threshold for sustained engagement is roughly 70% finding actionability — meaning at least 7 in 10 findings that reach a developer represent something worth addressing. Below that rate, developers start routing around the tool. Every SAST tool I've seen in production has signal-to-noise ratios well below 50% without runtime reachability filtering applied on top.
Workflow integration is the second driver. Security tools that require developers to leave their primary workflow (IDE, CI dashboard, PR review interface) to check findings see significantly lower engagement than tools that surface findings inline. This is not a preference — it's a behavioral economics reality. Every context switch has a cost. A finding that appears as a check failure on a GitHub PR is in the developer's current cognitive context. A finding that requires logging into a separate security dashboard has already lost most of its engagement probability.
Actionability of the output is the third driver. "SQL injection in src/api/users.js at line 47" requires the developer to research what SQL injection is, assess whether their specific pattern is exploitable, determine what the correct fix looks like, and decide whether it's worth prioritizing. That's 20-40 minutes of work before any fixing begins. A finding that says "SQL injection: user-supplied input in the query at line 47 is concatenated directly into the database query on line 49; this allows an attacker to modify query logic by injecting characters like `' OR '1'='1`; fix by parameterizing the query as shown below" requires about 5 minutes. The difference in time-to-fix affects whether the fix happens today or next sprint.
The Tradeoffs Teams Actually Face
Security teams optimizing for developer experience face several genuine tradeoffs. Understanding them makes it easier to make deliberate choices rather than implicit ones.
Coverage versus noise: More scanning coverage (more rules, more code paths analyzed, broader CVE database) produces more findings. More findings means more noise unless you have a filtering layer that can reliably separate signal from noise. The right tradeoff depends on your team's existing noise tolerance and triage capacity. A team with a dedicated security engineer who processes findings daily can handle broader coverage with lower filtering. A team of developers without dedicated security staff needs aggressive filtering before findings reach them.
Detection speed versus accuracy: Some security checks can run in seconds; others require minutes of analysis. Checks that run in seconds can be blocking — fail the PR before the developer pushes to remote. Checks that take minutes are better run asynchronously and surface findings later. If you make every security check blocking, you add minutes to every developer's commit-to-PR cycle. Teams have different tolerances for this. The best configuration we've seen: fast checks (syntax-level, secrets detection, dependency audit) run blocking in CI; slower checks (DAST, IAST, deep SAST) run post-merge and surface findings in a tracking system rather than blocking the PR.
Precision versus recall: A security tool tuned for high precision (few false positives) will miss some real vulnerabilities. A tool tuned for high recall (catches everything) will generate more false positives. Neither extreme serves developers well. In our experience, teams do better with slightly lower recall and higher precision, because false positives destroy the trust that sustained engagement requires. One false positive that costs a developer 30 minutes to investigate undoes the goodwill of ten correctly-identified real findings.
Practical Changes That Move the Needle
Based on what we've seen work and not work, here are the changes with the most consistent impact on developer engagement with security tooling:
- Apply reachability filtering before anything reaches developers. If your SAST tool can't suppress unreachable findings natively, add a filtering layer. The goal is to deliver only findings that can actually be exploited in your running application. Teams that do this report 60–75% reductions in finding volume with no increase in escaped vulnerabilities.
- Rewrite finding descriptions in developer terms. Translate CVE descriptions into plain language with specific context for the codebase. If your security tool doesn't do this automatically, write a wrapper that calls an LLM with the finding context. This is a few hours of engineering work and consistently ranks as the highest-impact change teams report.
- Surface findings in existing workflows. PR checks, IDE plugins, Jira tickets created from CI — wherever developers already work. Avoid requiring login to a separate security dashboard for routine finding review.
- Differentiate blocking from advisory findings. Only block on findings that are critical and reachable. Everything else is advisory — visible and trackable, but not blocking releases. This is the single change that most reduces developer resistance to security tooling. "Your security tool caused us to miss our release deadline" is a political problem that tanks adoption. A non-blocking advisory finding on the same vulnerability is reviewed and addressed on the next sprint cycle.
- Close the feedback loop. When a developer marks a finding as a false positive, that information should feed back into the detection system. Teams that have closed this loop see false positive rates decline by 40–60% over three months. Teams that don't have this loop see the same false positives recurring indefinitely, eroding trust over time.
What "Good" Actually Looks Like
The teams we've seen achieve genuinely good security outcomes — not just good metrics, but actual reduction in exploitable vulnerabilities reaching production — share a few observable patterns. Their developers can describe what the security tool does and why it matters. Finding volume is low enough that triage happens weekly rather than being perpetually deferred. Security fixes appear in the same sprint the finding was discovered, not in a future "security sprint" that keeps getting pushed. Security engineers spend time on architecture review and threat modeling rather than triage and finding re-explanation.
None of that happens when security tooling is designed purely for detection completeness without considering who has to act on what it finds. The shift from "maximize detection" to "maximize developer adoption" is not a security compromise — it's the path to actually fixing more vulnerabilities. In our experience, the best-instrumented teams fix a higher percentage of findings, fix them faster, and have lower rates of findings re-opening after fix than teams with more comprehensive-but-ignored tooling. Coverage without adoption is just noise generation at scale.
