Developer experience decides whether a security control gets used or worked around. A check that is slow, noisy or outside the workflow gets skipped, muted or disabled. A check that is fast, accurate and sits in the pull request becomes part of how code ships. Adoption, not detection, is the real measure.
Why does friction defeat a control?
Security teams often measure what a tool can find. Developers experience what it costs them: a ten minute pipeline step, a ticket with no file name, a blocked merge on a finding that does not apply.
People are rational about cost. When a gate fails on false alarms three times, the fourth failure gets an override. When the scanner needs a separate login and a separate dashboard, it gets opened once a quarter. A tool with perfect recall and no adoption protects nothing.
What does the guidance say?
CISA's Secure by Design initiative argues that manufacturers should take ownership of customer security outcomes, and that secure options should be the default rather than something customers must assemble. The same principle applies inside a company: the secure path should be the easy path.
NIST SP 800-218, the Secure Software Development Framework, frames security as practices woven into the software lifecycle, not a review bolted on at the end. Both documents point the same way: put the control where the work happens.
What does good experience look like in practice?
Here are the properties worth testing, each with a concrete bar.
Speed. A pull request check should finish in about the time a developer takes to refill a coffee. If a full scan takes 40 minutes, run an incremental one on the diff and the full one on a schedule.
Accuracy. Every false positive spends trust. Tools that can show whether vulnerable code is reachable from your application remove a large class of them.
Context. A finding should name the file, the line, why it matters and the fix, in the place the developer already looks.
Reversibility. Developers accept gates they can appeal. A documented exception path with an expiry date is better than a silent override.
Consistency. The same rule in the editor, the pull request and the pipeline. Surprises at the last stage create resentment.
A constructed example
A team adds a dependency scanner that blocks merges on any high severity advisory. In week one, 14 pull requests are blocked. Eleven involve a transitive package in a test-only tool. Developers learn to add an ignore comment. By week four, the ignore list has 60 entries and nobody reads it.
Now change two things. Block only on advisories in packages that production code calls, and make the ignore path require a reason and a date. Blocks drop to a few a week, each one real, and the ignore list is short enough for a security lead to review monthly. Same scanner, different experience, very different outcome.
How do you measure developer experience?
You can measure it without surveys.
- Median time added to a pull request by security checks.
- Share of findings that developers fix versus dismiss.
- Number of overrides per month and who makes them.
- Time from a finding appearing to a fix merging.
- Count of repositories where the check has been disabled.
If dismissals outnumber fixes, treat that as a product bug in the control, not a discipline problem in the team.
How to check or apply this
- Time your current security checks in the pull request and write the number down.
- Sample 20 recent findings and mark how many were real and actionable.
- Move checks earlier: editor first, pull request second, pipeline last.
- Add an exception process with an owner and an expiry date.
- Review overrides monthly and tune the rules that cause them.
- Ask two developers to try the workflow and watch where they hesitate.
Safeguard delivers checks through IDE extensions, the CLI and local runner, and pull request gates, with reachability analysis to cut noise. Whatever tool you use, apply the same measures above.
Quick check
Is developer experience just about speed?
No. Speed matters, but so do accuracy, clear context and a fair exception process. A fast tool that is wrong half the time still gets ignored.
Should security gates ever block a merge?
Yes, for findings you have decided are unacceptable and can detect reliably. Keep the blocking rules narrow and the exception path clear.
Sources
Last reviewed: 18 October 2026.
