TL;DR — Key Takeaways
- A golden path can become a hacker’s fast lane. When insecure templates distribute credentials across hundreds of services, one configuration mistake can become an organization-wide security weakness.
- Your secrets may be hiding in plain sight. Backstage vulnerabilities, exposed CI/CD logs, forgotten Git history and poorly protected Kubernetes Secrets can turn developer convenience into an attacker’s opportunity.
- Stop handing out permanent keys and start building secure defaults. Short-lived credentials, per-service identities and centralized secrets management can transform internal developer platforms from credential factories into defensible security controls.
Platform engineering teams build golden paths so that developers can ship a new service in minutes. The template creates the repository, the pipeline, the container image, the namespace and, almost always, the credentials the service needs to talk to a database, a cloud API or a message broker. That convenience is the whole point. It is also why an internal developer platform (IDP) becomes one of the most valuable targets in a company: Whoever controls the path controls every credential it hands out.
This article looks at where secrets actually leak inside an IDP, using a real example from Backstage, and then at five changes a platform team can make this quarter to shrink the blast radius.
Why the Golden Path Concentrates Risk
A golden path is repeatable by design. If a template provisions a long-lived access key with broad permissions, every service created from it inherits the same weakness, and it does so at scale. A single mistake in a template is no longer a single mistake; it is a pattern copied into every team that follows the path.
Three properties make this worse than a normal application bug. Templates run with elevated rights because they must create resources across systems. Their inputs often include secrets, such as tokens for the source control host or the cloud account. And their output, the logs of every run, is visible to far more people than the secret itself ever should be.
Where Secrets Leak Inside an IDP
- Template inputs and run logs. In August 2025, the Backstage project published CVE-2025-55285 for the Scaffolder backend plugin. The fetch:template action logged a duplicate, pre-redaction copy of its input values, so secrets passed through the secrets bag could appear in log output. The advisory rates it low severity (CVSS 2.6) because exploitation needs a template that passes secrets to fetch:template and access to the logs, and it was fixed in version 2.1.1 of @backstage/plugin-scaffolder-backend. The score is modest, but the lesson is not: the weakness class (CWE-532, sensitive information written to a log file) is common, and a platform that runs thousands of template executions produces a lot of logs for an attacker to read.
- Repositories and their history. Skeleton templates are copied into new repositories, and a credential committed once stays in the Git history even after the file is deleted. Attackers know this, and they automate the search. A classic example is secret scanning with Gitrob, which walks the repositories of an organization and flags files and commits that match patterns for keys, tokens and configuration files. If a pentester can find your leftovers with a free tool, so can everyone else.
- Build runners and containers. Pipelines run untrusted code, such as dependencies and pull requests from forks, on machines that hold deployment credentials. If the runner is a privileged container, or if the Docker socket is mounted into the build, a compromised job can break out of its sandbox and reach the host and every secret on it. The techniques are well documented; see this overview of container escape techniques to understand how little separates a build step from the node underneath it.
- Kubernetes Secrets. By default, Kubernetes stores Secret objects unencrypted in etcd, and the base64 encoding that kubectl shows is not protection. Anyone with read access to Secrets in a namespace, or to a backup of etcd, can read them in clear. Encryption at rest has to be turned on deliberately.
Five Fixes for Platform Teams
Replace stored credentials with short-lived ones. The strongest fix is to stop storing cloud credentials in the pipeline at all. GitHub Actions, GitLab CI and most major CI systems can request a signed OIDC token for each job, and cloud providers can exchange that token for temporary credentials tied to a specific repository and branch. A stolen token then expires in minutes instead of living for years. A minimal GitHub Actions example for AWS looks like this:
permissions:
  id-token: write
  contents: read
steps:
  – uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789012:role/deploy-orders-service
      aws-region: eu-west-1
Give each service its own identity. A template should create a narrowly scoped role per service and per environment, never reuse one shared role. If the orders service is compromised, the attacker should not be able to touch the billing database.
Keep application secrets in a secrets manager and sync them. Store values in Vault, AWS Secrets Manager or a similar system, and let a controller such as External Secrets Operator create the Kubernetes Secret at deploy time. Developers and templates then handle references, not values, and rotation happens in one place.
Treat logs as an attack surface. Keep the IDP and its plugins patched, avoid passing secrets as template parameters when a reference will do, and test your own redaction: run a template with a dummy secret and search every log it produces. Backstage users should also check that the Scaffolder backend is on a fixed release.
Block secrets before they reach the repository. Turn on push protection and secret scanning in your source control platform, scan the skeleton templates themselves, and run a history scan on existing repositories. Rotate anything that is found, because deleting the file does not delete the exposure.
A Short Audit Checklist
- List every credential each golden path creates, and who can read it.
- Check which of them are long-lived, and replace those with OIDC or workload identity.
- Review runner privileges: no privileged containers, no mounted Docker socket on shared runners.
- Confirm encryption at rest for Kubernetes Secrets and restrict who can list them.
- Search recent template run logs for anything that looks like a token.
Conclusion
A golden path should make the secure choice the easy choice. When the template hands out short-lived, narrowly scoped identities and never shows a developer a raw key, the platform stops being a credential factory and becomes a control point you can defend. Start with the credentials your templates create today, because that is where an attacker will start too.