Developers skip a paved road when it costs more than the alternative: it is slow, too rigid for their work, built without their input, or fails with messages they cannot act on. The fix is to treat the road as a product with users, measure friction, and give teams a safe way to ask for exceptions.
Five reasons teams go off road
DORA's platform engineering guidance lists common antipatterns. They map neatly onto why a security paved road gets bypassed.
| Cause | What it looks like | Fix |
|---|---|---|
| Built without user research | The template assumes a stack nobody uses | Interview two or three teams before you build |
| Ivory tower | Rules arrive from a central team with no discussion | Publish the reasoning and take pull requests |
| Ticket queue | Teams must file a request to get a scan or a fix | Make the common case self-service |
| Big bang release | Months of work, then a launch that no longer fits | Ship the smallest useful road first |
| Golden cage | One path for web, mobile and data teams alike | Offer a few supported variants |
DORA describes the first as the "build it and they will come" trap, and notes it often leads to poor adoption. The ivory tower approach, it says, tends to produce shadow IT workarounds. In security terms, a workaround is a pipeline with the checks removed.
Friction is the real competitor
A developer under deadline compares two costs: the time to follow the road and the time to go around it. Your job is to make the first lower. Look for the moments where the road slows people down.
- Setup time. How long from "I need a new service" to a green pipeline?
- Noisy checks. If a scanner reports dozens of findings that do not affect the app, people learn to ignore it.
- Unclear failures. DORA's 2025 data found that the platform capability most correlated with a positive user experience was clear feedback on the outcome of tasks. A failing check with no explanation is the opposite.
- No off ramp. If there is no sanctioned way to deviate, people deviate quietly.
Give people a sanctioned way to differ
DORA recommends enabling constraints with enough flexibility for teams to use the right tools for their jobs. In practice that means a documented exception route, with a named owner, a reason and an end date. A visible exception is far better than an invisible bypass, because you can count it and learn from it.
Cut noise before you add rules
If your road runs a dependency scan, make sure it separates reachable risk from background noise. The demo below shows the idea: the same findings, filtered by whether the vulnerable code can actually be reached.
Try it yourself
Click through it at your own pace, or open it full screen. Compare the count before and after reachability is applied.
Where Safeguard fits
Safeguard's reachability analysis helps a gate block on findings that matter, and its policies let you set what blocks and what warns per team. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Should the paved road be mandatory to stop people leaving it?
Mandating without fixing friction usually drives workarounds. Start by making the road the easiest option, then require the parts that protect everyone, such as a required security check on merge.
How do I find out why a team left the road?
Ask them. A short conversation with the team lead usually surfaces the cause within minutes, and it is cheaper than guessing from dashboards.
Sources
Last reviewed: 19 October 2026.
