Platform engineering needs stronger secrets governance for CI/CD workflows

At a glance

What this is: This is a platform engineering guide showing how internal developer platforms, CI/CD pipelines, and secrets management fit together, with dynamic secrets positioned as the core control for reducing credential exposure.

Why it matters: It matters because platform teams now govern both delivery speed and identity risk, and the same workflow that improves developer autonomy can also expand NHI blast radius if secrets, tokens, and access paths are not tightly controlled.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Akeyless's blog post on platform engineering and secrets management

Context

Platform engineering is the discipline of building internal platforms that let developers ship software through standardised, self-service workflows. The security problem is that those workflows often depend on secrets, tokens, certificates, and service accounts that outlive the task they were created for, which turns delivery infrastructure into an identity governance problem.

In this article, the vendor frames secrets management as the control that makes platform engineering safe at scale. The deeper issue is lifecycle management across humans, workloads, and automation paths, because GitHub Actions, Kubernetes, and Argo CD all become access brokers when they hold reusable credentials.

For teams operating internal developer platforms, the question is not whether to abstract complexity. It is whether the abstraction hides standing privilege, secret zero exposure, and offboarding gaps that IAM and PAM teams will later have to unwind.

Key questions

Q: How should security teams implement dynamic secrets in platform engineering workflows?

A: Start by tying secret issuance to workload or pipeline identity, then limit the credential to the shortest practical task window. Dynamic secrets work best when the platform can renew them automatically, expire them cleanly, and log every request. If the workflow still depends on shared static credentials, the improvement will be partial at best.

Q: Why do CI/CD runners and build tools increase NHI risk?

A: They often hold cloud tokens, publishing credentials, SSH keys, and database secrets that behave like non-human identities. When those identities are long-lived or broadly scoped, a single package execution can expose multiple environments. That is why build infrastructure needs the same governance discipline as other privileged identity surfaces.

Q: What breaks when secret zero is stored in code or pipeline variables?

A: The entire bootstrap chain becomes recoverable by anyone who can read the repository, job logs, or pipeline configuration. Once the initial credential is exposed, downstream dynamic secret controls may still work, but the attacker already has a foothold in the trust path. That is a design failure, not just a secret leak.

Q: Who should own offboarding for platform identities and secrets?

A: Ownership should sit with the team that governs the underlying identity, not just the application team. Pipeline identities, workload credentials, and portal access all need explicit revocation paths so access does not outlive the system or project that created it. Without lifecycle ownership, platform automation becomes permanent privilege.

Technical breakdown

Why secret zero is the first platform engineering failure mode

Secret zero is the bootstrap problem where a system must authenticate before it can retrieve the credentials needed for further authentication. In platform engineering, that usually appears in GitHub Actions, Kubernetes auth flows, or orchestration pipelines that need an initial token, certificate, or workload identity to reach the secret store. If that first trust anchor is stored in code, configuration, or CI/CD variables, the entire platform inherits the exposure of a long-lived credential. Dynamic secrets reduce downstream blast radius, but they do not solve bootstrap trust by themselves.

Practical implication: inventory every bootstrap credential and replace static secret zero paths with federated or workload-bound authentication where possible.

How dynamic secrets change the identity lifecycle in CI/CD

Dynamic secrets are short-lived credentials generated for a specific task, service, or deployment window. They fit platform engineering because pipelines and applications can request access only when needed, then let the secret expire instead of relying on manual rotation. The control value is not just short TTLs. It is the ability to bind access to the runtime context of the workload, which reduces the time an attacker can reuse a leaked value. That matters most where CI/CD jobs and application pods repeatedly touch databases, registries, and deployment APIs.

Practical implication: align secret TTLs with job duration and workload execution patterns, then verify that expiry fails safely rather than breaking deployments.

Why access control must extend beyond the vault

A vault is only one part of the control plane. Platform engineering also depends on repository permissions, pipeline tokens, Kubernetes namespaces, Argo CD application rights, and developer portal access. If each layer is governed separately, teams can still end up with broad standing privilege even when secrets are centrally stored. This is why secrets management must be treated as part of identity governance, not as a point solution. The relevant question is which actor can request, retrieve, inject, and renew credentials across the workflow, and under what approval or policy conditions.

Practical implication: map every platform workflow to the identities that can create, read, renew, and revoke credentials across each system boundary.

Threat narrative

Attacker objective: The attacker wants durable access to the software delivery chain and the downstream systems that the chain can reach.

1. Entry occurs when a reusable pipeline token, static secret, or bootstrap credential is exposed in source, configuration, or CI/CD tooling.
2. Escalation follows when that credential can reach repositories, deployment systems, or databases with more privilege than the original task requires.
3. Impact is achieved when the attacker reuses the credential to modify code, exfiltrate data, or take control of the deployment path.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Platform engineering has become an NHI governance domain, not just a delivery architecture. Once GitHub Actions, Kubernetes, and deployment orchestration begin handling reusable credentials, the platform itself becomes part of the identity attack surface. That means IAM, PAM, and lifecycle controls must extend into the software delivery path, not sit beside it. Practitioners should treat platform engineering as governed identity infrastructure, not merely developer tooling.

Secret zero is the defining trust assumption in platform engineering. The assumption is that a system can securely obtain its first credential without already needing a credential worth stealing. That assumption fails whenever the bootstrap secret is stored in code, a pipeline variable, or a shared secret manager path that is itself overexposed. The implication is that platform teams must rethink how trust starts, not just how secrets rotate.

Dynamic secrets create a smaller blast radius, but they do not eliminate entitlement sprawl. A short-lived MySQL credential is still dangerous if the pipeline that issued it can also create repositories, alter deployments, or renew access without strong policy boundaries. The governance issue is not the secret alone but the privilege chain around it. Practitioners should assess the full request, issuance, renewal, and revocation path as one control surface.

Identity blast radius is now a platform metric. The more systems a single workflow can touch, the more damage one leaked token can do before expiration or revocation. This is why secret storage, repository permissions, deployment rights, and portal access must be reviewed together. Teams should measure how far a compromised pipeline identity can travel before control breaks down.

Lifecycle governance is the hidden test for platform maturity. Access that is easy to create but hard to revoke produces the same failure pattern as human privilege creep. Platform engineering programmes need the same lifecycle discipline applied to service accounts, workloads, and automation identities that IAM teams already expect for people. Practitioners should design for offboarding, renewal, and revocation from day one.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably account for the identities embedded in platform workflows.
• For a deeper lifecycle lens, see Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs for provisioning, rotation, and offboarding controls.

What this signals

Identity blast radius is the right lens for platform engineering programmes that rely on GitHub Actions, Kubernetes, and deployment automation. When one workflow can mint secrets, create repositories, and publish to runtime systems, the governance question becomes how far a compromised execution path can travel before it is contained.

The control gap is rarely the vault itself. It is the absence of a unified lifecycle model across pipeline identities, workload credentials, and portal access, which is why platform teams should align implementation work with NIST Cybersecurity Framework 2.0 functions for identity governance, detection, and recovery.

The practical next step is to treat secret issuance, renewal, and revocation as platform SLOs. If access can be created in seconds but cannot be offboarded with equal precision, the programme has solved delivery convenience faster than it has solved identity risk.

For practitioners

• Map the bootstrap trust chain Document how GitHub Actions, Kubernetes, Argo CD, and any portal authenticate before they can request secrets, then eliminate static secret zero paths where a federated identity can replace them.
• Classify every platform identity by lifecycle Separate human users, pipeline identities, service accounts, and workload credentials, then assign ownership for creation, renewal, and revocation to the right control owner.
• Bind secret TTLs to runtime need Set secret expiry to match the actual duration of jobs and application sessions, and verify that expired credentials fail safely without forcing teams to reuse longer-lived values.
• Review cross-system privilege chains Trace which identities can create repositories, write manifests, renew credentials, or deploy applications, then remove any capability that is not required for the task itself.
• Test revocation as part of platform change control Simulate the offboarding of pipeline access, portal permissions, and workload credentials to confirm that revoked access actually stops secret retrieval and deployment execution.

Key takeaways

• Platform engineering improves delivery speed, but it also turns CI/CD and orchestration layers into identity control points that must be governed like NHIs.
• Short-lived dynamic secrets reduce exposure windows, yet the real risk remains bootstrap trust, cross-system privilege, and delayed revocation.
• Teams that can map lifecycle ownership across pipeline identities and workload credentials will be better positioned to contain platform blast radius.

Key terms

• Secret Zero: Secret zero is the first credential needed to reach a secrets store, identity broker, or protected system. It is the root trust dependency that often survives even when everything else is rotated. If that initial credential is exposed, the rest of the secret model can collapse very quickly.
• Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Platform Identity Lifecycle: The creation, renewal, review, and revocation lifecycle for non-human identities used by platforms, pipelines, and workloads. It is the governance layer that prevents automation credentials from becoming permanent access simply because they are embedded in delivery workflows.

What's in the full article

Akeyless's full blog post covers the operational detail this post intentionally leaves for the source:

• GitHub Actions pipeline steps for creating repositories, namespaces, and deployment wiring.
• Demo-specific configuration for Port, Argo CD, and Kubernetes integration across the workflow.
• A look at how the platform handles dynamic MySQL credential issuance during application runtime.
• Implementation notes for JWT-based secret zero handling in GitHub and Kubernetes auth flows.

👉 The full Akeyless post covers the demo workflow, GitHub Actions setup, and dynamic secret handling in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.