TL;DR — Key Takeaways
- Golden paths often need credentials for repositories, CI/CD and cloud resources, creating risk when one broadly scoped token is reused across many services.
- CVE-2025-55285 in Backstage showed how secrets passed through scaffolding workflows could leak into logs, expanding the secrets attack surface.
- Safer designs use per-service identities, external secrets managers, least privilege and tighter controls around logs and scaffolding pipelines.
The whole promise of a golden path is that a developer never has to think about the plumbing. Click a button, answer a few prompts, and the platform hands back a fully wired service: Repository, CI/CD pipeline, cloud resources, and — almost always — the credentials to talk to all of it. That last part is where platform engineering quietly creates one of the largest single points of compromise most organizations have ever built.
It’s not a hypothetical. It’s a pattern, and it has already shown up in production tooling millions of engineers use.
Why One Token Behind the Curtain is Worse Than Many
A golden path template typically needs to authenticate to several systems on the developer’s behalf: A Git provider to create the repository, a CI/CD system to wire up pipelines, a cloud provider to provision infrastructure. The path of least resistance — and the one most teams take when a platform is first standing up — is a single, broadly-scoped credential baked into the template itself, shared across every service it scaffolds.
That convenience is exactly the problem. A credential scoped to “whatever the golden path might ever need” and reused across hundreds of scaffolded services is no longer a service credential. It’s a master key, and it’s sitting in a place — a template engine, a scaffolding tool, a CI variable — that was designed for convenience, not for holding the one secret that unlocks everything built on the platform.
A Real Example: CVE-2025-55285 in Backstage
Backstage — the CNCF-hosted, Spotify-originated platform that has become the de facto standard for building internal developer portals — runs golden paths through a component called the Scaffolder, using Software Templates to bootstrap new services. Those templates can accept secrets as input parameters, passed through at creation time so the generated service starts with working credentials already in place.
In August 2025, CVE-2025-55285 was disclosed against the Scaffolder’s fetch:template action: a logging flaw caused a duplicate, pre-redaction copy of the input parameters to be written out whenever a template used the secrets bag. Any secret passed through that action could end up sitting in plain text in local or server-side Scaffolder logs — logs that, in most setups, considerably more people can read than can read the secret store itself.
The fix, shipped in version 2.1.1, removed the duplicate log path. The lesson doesn’t get fixed by a version bump, though: the moment a golden path is trusted to handle a secret on a developer’s behalf, every logging statement, every audit trail, and every debug output in that pipeline becomes part of your secrets’ attack surface — whether anyone designed it that way or not.
Why Kubernetes Secrets Don’t Save You Either
The instinct after a scare like this is to move the credential into “a proper secret,” and for platforms running on Kubernetes that usually means a Kubernetes Secret. It helps, but it’s a smaller step than it looks like: Kubernetes Secrets are base64-encoded, not encrypted, and stored as plain objects in etcd. Anyone with read access to Secrets in a namespace — including, in a lot of clusters, a wider set of service accounts and CI jobs than anyone intended — can decode one in a single command.
If the credential a golden path injected was broad and long-lived to begin with, moving it into a Kubernetes Secret hasn’t reduced its blast radius. It has just changed which kind of disclosure gets you there — a leaked log line and a readable Secret object end up handing an attacker functionally the same thing.
What Actually Closes the Gap
- Audit for the CVE-2025-55285 pattern specifically. If you’re running Backstage, confirm you’re on 2.1.1+ of the scaffolder-backend plugin, and grep your own templates for any use of ${{ secrets }} inside fetch:template actions specifically — the workaround of simply not passing secrets through that action still applies even on a patched version.
- Stop baking one shared credential into every scaffolded service. Each service a golden path creates should get its own narrowly-scoped identity — provisioned at creation time, not inherited from the template — so that compromising one service’s credential doesn’t compromise every service the platform has ever built.
- Route secrets through an external secrets manager, not static Kubernetes Secrets. Tools like the External Secrets Operator sync credentials from Vault, AWS Secrets Manager, or an equivalent at runtime, so nothing long-lived sits base64-encoded in etcd waiting to be read.
- Treat scaffolder and CI logs as sensitive by default. Restrict who can read them, and run automated secret-scanning across them the same way you’d scan a git repository — a single shared platform token that ends up in a log line is exactly the kind of credential an attacker would spend time harvesting, precisely because one token unlocks so much more than a single service’s worth of access.
The Bottom Line
Platform engineering exists to remove friction, and secrets are one of the most tempting places to remove it — nobody wants a developer to be blocked because they don’t know how to fetch a cloud credential. But the fastest way to grant that convenience is usually the same move that turns one golden path template into a single point of failure for everything built from it. The teams getting this right aren’t the ones with the most convenient templates; they’re the ones who made per-service, short-lived credentials just as frictionless as the shared token used to be.