Golden Path

The Golden Path is the default, supported way to build a new service or component. Following it means most of your security decisions are already made for you — sensible defaults, vetted tooling, and guardrails baked into the platform.

You’re free to deviate from it, but deviations should be a conscious decision, ideally discussed with the security team, not an accident.

What “golden” means in practice

• Secure by default — the defaults are the secure choice; you have to opt out of security, not opt in.
• Paved, not paved over — teams can still make their own choices, but the paved road is the easy, well-supported one.
• Automated where possible — checks run in CI, not just in someone’s head during review.

The path

1. Start from a template. New services should start from an approved starter/template repository rather than from scratch, so baseline configuration (CI, linting, dependency scanning, secrets scanning) is already in place.
2. Authenticate with the standard identity provider. Don’t roll your own auth. See Authentication.
3. Keep secrets out of the repo. Use the standard secrets manager / environment variable injection in CI-CD. See Secrets Management.
4. Turn on dependency and vulnerability scanning. Dependabot (or equivalent) and a supply-chain scan should run on every repository from day one. See Dependency Management.
5. Validate all external input at the boundary. See Input Validation.
6. Ship behind CI. No direct pushes to production; changes go through pull request review and an automated pipeline that runs tests and security checks before deploy.
7. Log and monitor. Emit structured logs and set up basic alerting before you consider a service production-ready.

When you need an exception

If the Golden Path doesn’t fit your use case, document the deviation (what, why, and the compensating control) and flag it in review. The goal isn’t to block you — it’s to make sure security tradeoffs are visible and intentional rather than silent.