A paved road is the supported, pre-configured way to build and ship software inside a company, with security checks already built in. A guardrail is a single control that stops a risky action. The road makes the safe choice the easy one, and guardrails catch people who drift off it. Most teams need both.
Four terms that get mixed up
People use these words loosely, so it helps to pin them down before a platform project starts.
| Term | What it is | Example |
|---|---|---|
| Golden path | A self-service route for a common job, such as creating a new service | A template that creates a repo, a pipeline and a deploy target |
| Paved road | The same idea seen from the security side: the supported route where checks are already wired in | The shared pipeline that every service on the template uses |
| Guardrail | A control that prevents or flags one unsafe action | Blocking a deploy of an image that runs as root |
| Gate | A checkpoint that must pass before work moves on | A pull request check that must be green to merge |
The DORA research page on platform engineering describes an internal platform as providing shared tools, services and golden paths so teams can build, test and deploy applications securely, reliably and in a compliant way. It also uses the phrase paved road for the result. The vocabulary varies by company, so write your own definitions down and use them consistently.
How they fit together
Think of a trip. The road is the route you take by default. Guardrails sit at the edges, and a gate is a toll booth you must pass through. If you build just guardrails, developers meet a wall of blocks with no easy way forward. If you build just the road, nothing stops a team that wanders off it.
The CNCF platforms white paper makes a related point: shared platform patterns let an organisation embed governance and controls in templates, patterns and capabilities. That is the road doing security work before any gate fires.
What a security paved road usually contains
Keep the first version small. A useful starting set:
- A template that creates a new repository with sane defaults.
- A shared pipeline that runs dependency and code checks.
- A policy file that says what blocks and what merely warns.
- A short page that explains how to get started and who to ask.
Each item can be adopted on its own. That matters, because adoption decides whether a road works at all.
Where a paved road goes wrong
DORA names several antipatterns. One is the ivory tower, where a central team dictates rigid standards without collaboration and acts as a gatekeeper. Another is the golden cage, a one size fits all path that ignores how different teams work. A road that nobody wants to use is just a policy document.
If you want to see what a gate on the road looks like to a developer, try the demo below.
Try it yourself
Click through it at your own pace, or open it full screen. Watch what the developer sees when a check fails, and whether the next step is obvious.
Where Safeguard fits
Safeguard provides policies, gates and guardrails you can attach to the pipelines on your road, plus SBOM and dependency scanning and reachability analysis so checks block on what matters. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a paved road the same as a golden path?
Close, but the emphasis differs. Golden path usually describes the self-service developer journey. Paved road describes the supported route with security and compliance checks already in place. Many teams use them as synonyms, which is fine if your docs say so.
Do I need a platform team to have a paved road?
No. The CNCF white paper notes that a very simple platform could be a wiki page with links to standard procedures. A template, a shared pipeline and an owner can be enough to start.
Sources
Last reviewed: 19 October 2026.
