Securing the Golden Paths of Your Platform
- Divine Odazie
- 2 days ago
- 7 min read
Golden paths promise speed and consistency, but what if those paths aren’t secure?
As more teams embrace platform engineering, golden paths have become the go-to approach for streamlining developer workflows. Fundamentally, it solves the “how can/should I do this?” problem for developers in engineering teams. The goal is to set up a complete development environment, with the networking, integration, security, governance, compliance, and deployment aspects of the software delivery pipeline — all available on demand.
But there’s a problem with most golden paths today. It is “wrong priorities”. As Gregor Hohpe notes, this often leads to potholes along the path.
Too often, teams design these golden paths without security in mind and hope to catch up through manual reviews, policy audits, or emergency patches. That defeats the entire purpose of a golden path. A truly golden path isn’t just paved for speed, it’s fortified for safety.
We at Syntasso believe that golden paths must be secure by default, and not an afterthought. So in this article, we will show you how to secure the golden paths of your platform.
Why security can’t be an afterthought
The addition of security that occurs post-golden path design is security that occurs too late. Once developers have already adopted a workflow, it’s far harder to retrofit the proper guardrails without breaking productivity.
According to a Cloud Security Alliance study, 99% of organisations that experienced cloud-related breaches in 2024 blamed insecure identities as the primary cause. Supporting that, SentinelOne’s Cloud Security Report found that 82% of misconfigurations are caused by human error, not technology flaws.
We could list statistics all day, but the message is clear: most security incidents aren’t the result of sophisticated attacks; they’re preventable mistakes. Open S3 buckets. Overly permissive IAM roles. Secrets that aren’t rotated in a timely manner and missing network policies. These are minor missteps that become big problems at scale.
We’ve agreed that developers don’t want to build pipelines and monitoring instrumentation. It's also important to remember that they also don’t want to wrestle with IAM or policy files. They just want to ship code.
That’s precisely why platforms need to absorb this and every possible complexity and present security as an invisible default. When secure configurations, policies, and compliance checks are baked into the golden path itself, developers can move faster and safer without ever slowing down for security.
Security shouldn’t follow the golden path; it should define it.
That’s where prioritising security in your golden paths truly begins.
Prioritising security in your golden paths
With the plethora of cloud-native security tools available today, it’s easy to assume that adding more will automatically make your golden paths safer. In reality, piling on tools without a clear integration strategy often leads to alert fatigue and critical blind spots.
“Good” cloud-native security is context-aware and lifecycle-integrated, aligning with how your Cloud provider, Clusters, Containers, and Code (The 4C's of Cloud Native security) actually evolve at scale.
Shift-left golden paths (Code & Containers)
Before developers take the first steps down a golden path, they will write the code they wish to deploy. Instead of waiting for guardrails and checks to detect issues, isn’t it better for developers to write secure code?
Too often, security tools are designed for security teams, not developers, generating large alerts down the pipeline that aren’t contextually relevant to developers. As a result, you’d often hear “security checks didn’t catch it, should be fine”, but they’ve already packaged it as a container. With the increase in GenAI adoption, if you are just scanning your images rather than code, you may be looking in the wrong direction.
Shift-left golden paths means engineering leaders in your organisation equipping developers with developer-first tooling (SAST, DAST, etc) that integrates directly into their workflow, protects against anti-patterns, vulnerable dependencies, insecure base images, and hardcoded secrets that slip into version control systems.
By automating checks that create clear remediation recommendations where developers work, security shifts left seamlessly while reducing friction and alert fatigue for both developers and platform engineers, ensuring code enters the cloud hardened from the start.
Treat every layer as your first line of defence
As mentioned earlier, a golden path is a complete development environment setup that abstracts the security, governance, compliance, etc. of your platform. How you build your platform shapes how you will secure it.
Whether you already have a mature platform or are building a new one, there is one thing that can help you build secure golden paths, and it's not a technology. It is the “multiplayer model”.
The multiplayer model is a teamwork-and-collaboration model in which the platform team owns the platform but doesn’t build it alone.
The multiplayer model is sometimes called platform democratisation or the producer/consumer model, where producers are the platform team collaborating with other teams, and consumers are developers.
Other teams in this scenario include the security team and other folks in your organisation who are experienced with the specific technology (e.g., PostgreSQL), for whom you are building a golden path.
A great example is PostgreSQL’s search_path vulnerability, something most engineers don’t know or overlook. By default, Postgres searches multiple schemas (like "$user", public") when running queries, meaning a low-privilege user who can create objects in the public schema could shadow built-in functions (like now()) and execute malicious code.
A Postgres expert would know to lock this down by revoking CREATE privileges on the public schema and explicitly setting a safe search_path (e.g., ALTER ROLE app_user SET search_path = app_schema, pg_catalog;).
It’s a small configuration detail that prevents privilege escalation, but one that’s easily missed without consulting a database security specialist.
If you can take specialist tools that experts in your organisation know precisely how to utilise and secure, turn them into building blocks and integrate them into the platform, then you’re not just creating a golden path; you're creating a secure-by-default golden path.
If you were thinking, how could you put this into practice? Then, that’s a valid question.
One way to achieve this is to utilise an open-source platform orchestrator such as Kratix. At the core of Kratix are Promises, which are sets of instructions written in YAML that produce a resource whenever invoked.
Each Promise consists of:
API description of how a user can request that Promise.
Dependencies, which are optional and can be made a requirement, must be met before a developer can request the Promise.
Workflows that define how provisioning takes place.
Destination rules that allow the Promise Author (Producers) to determine where resources should go.
A Promise can also be a dependency in another Promise, forming a compound Promise, which in essence is a golden path that builds on existing building blocks.
With this approach, you defend each layer of your golden path using domain knowledge from your team's experts.
After you have this collaboration model knitted in, choosing your technologies is easier because you are running with experts' recommendations:
Infrastructure provisioning: Tools like Terraform & Crossplane ensure consistency.
Secure-by-default settings: Encrypted storage, mTLS, RBAC, and Policy as Code for tight access control.
Secret management: Use HashiCorp Vault or Sealed Secrets for secure credential storage.
Identity & access control: SSO solutions (e.g., Okta) simplify authentication.
Automation: FluxCD / ArgoCD automates updates, reducing security risks.
Vulnerability scanning: Trivy / Snyk / Aikido secure deployable artifacts.
Compliance enforcement: OPA / Gatekeeper enforces policies.
API security: Istio provides authentication, encryption, and rate limiting.
Monitoring & auditing: Prometheus, Grafana, and Falco detect real-time threats.
CI/CD & GitOps: Automate security while simplifying deployments.
Your cloud is the first golden path
Public, Private (On-premises, Managed, Virtual), Hybrid, or whatever you call it.
Every organisation talks about building golden paths for developers, and few realise that the cloud itself should be the first golden path for everyone in the organisation. If this foundation isn’t secure, every path that follows inherits its flaws. Remember, the cloud operates on a shared responsibility model, and depending on your agreement, your responsibility varies.
The first step will be network segmentation. Use dedicated accounts or VPCs for each team or environment to contain risk. The more isolation, the better, because anything can happen, whether inside or outside your organisation.
Other best practices you can consider are:
Leveraging Just-in-Time (JIT) access
Using Web Application Firewalls (WAFs) and DDoS protection
Establishing incident response plans
Enforcing a zero-trust security model
Develop a strong culture of security awareness
With cloud security, there is almost an unlimited amount of best practices to follow, but what's more important is how you implement them. Here is an article that explains 25 cloud security best practices you can consider.
The rise of the Security Platform Engineer
According to platformengineering.org, a new role is emerging to meet this challenge: the Security Platform Engineer (SPE). Security platform engineers embed security into Platforms, automating controls and ensuring secure-by-default practices for faster, safer, and compliant software delivery.
Security platform engineers don't operate in isolation; like all other platform engineering sub-disciplines, their work touches virtually every aspect of the platform. This makes collaboration a core requirement of the role.
But the truth be told, you most likely don’t need a dedicated security platform engineer. If you have a security team and/or specialist folks in your organisation, you're better off with the multiplayer mode as a dedicated security platform engineer easily becomes a silo.
Create golden paths for day 2, 50, and 1000
Securing the golden paths of your platform isn’t a one-off project. It’s a continuous effort.
The truth is, every platform decision you make today becomes tomorrow’s developer experience. If that experience makes doing the right thing easy, you’ll get security for free. If it doesn’t, you’ll end up enforcing rules instead of enabling progress.
Security-by-default isn’t about more scanners, dashboards, or gatekeepers. It’s about designing guardrails into the experience from the first cloud account you create to the last service your developers deploy.
The multiplayer model makes this possible: platform engineers, security teams, and domain experts working side by side to turn knowledge into reusable, secure building blocks.
The best golden paths don’t just optimise for day 1, they’re built for day 2, 50, and 1000. They scale as your teams grow, your architecture evolves, and your compliance demands change.
Because a golden path isn’t truly golden until it’s safe to walk on. Every time, for everyone.
Comments