What is the difference between a platform secret store and an external secret manager for pipelines?

Why This Matters for Security Teams

For pipeline security, the real decision is not simply where a secret is stored. It is where authority lives, who can audit access, and how quickly a compromise can be contained. A platform secret store centralises credentials inside the delivery system, while an external secret manager preserves an enterprise system of record for access control, rotation, and logging. That difference becomes critical when CI/CD is already one of the most targeted paths into production, as shown in NHIMG research on the CI/CD pipeline exploitation case study.

Security teams often underestimate how quickly pipeline secrets spread across runners, build logs, templates, and downstream jobs. The NIST Cybersecurity Framework 2.0 emphasizes governance and asset visibility, which is exactly where this choice lands in practice. NHIMG’s Guide to the Secret Sprawl Challenge also shows why storing secrets is not the same as controlling them. In practice, many security teams discover the governance gap only after a pipeline token has already been reused outside the build that requested it.

How It Works in Practice

A platform secret store is usually the simplest operating model. The CI/CD system keeps a managed repository of secrets and injects them into jobs when needed. That can be efficient for internal teams because the platform owns retrieval, masking, and basic lifecycle operations. The limitation is that the pipeline platform also becomes part of the trust boundary, so access reviews, rotation, and incident response are constrained by the platform’s own controls.

An external secret manager keeps the source of truth outside the pipeline. The pipeline retrieves secrets at runtime from an enterprise vault or cloud secret service, often through short-lived authentication and policy checks. That model aligns better with central governance because the security team can enforce rotation, approval workflows, and audit trails in one place. It also reduces duplication when multiple build systems need the same credential set.

• Use a platform secret store when the pipeline is the primary consumer and operational simplicity matters most.
• Use an external secret manager when the credential already has an enterprise owner, stricter audit needs, or broader reuse.
• Prefer short-lived retrieval over copying secrets into config files, job variables, or artifacts.
• Map secret access to least privilege and separate read, rotate, and revoke permissions.

OWASP’s Non-Human Identity Top 10 is useful here because pipeline secrets are still NHI credentials, not just generic config values. NHIMG’s Top 10 NHI Issues is a strong reminder that leakage often comes from visibility gaps, overprivilege, and weak lifecycle ownership. These controls tend to break down when pipelines are distributed across multiple teams and secret ownership is split between platform engineering and separate cloud administrators because no single group can prove end-to-end accountability.

Common Variations and Edge Cases

Tighter centralisation often increases operational overhead, requiring organisations to balance governance against pipeline speed. That tradeoff is why there is no universal standard for this yet. Some teams use a hybrid model: the platform stores only non-sensitive references, while the external secret manager holds the actual credential and performs rotation. Others keep ephemeral build credentials in the platform but reserve high-value production secrets for the enterprise vault.

Edge cases appear when pipelines span multiple clouds, ephemeral runners, or third-party build services. In those environments, an external secret manager usually reduces lock-in and makes audit trails easier to preserve, but it can also introduce latency or dependency on another service during builds. For regulated environments, the choice often comes down to whether the organisation wants pipeline convenience or enterprise-grade custody of secrets. NHIMG’s NHI Lifecycle Management Guide is relevant because the retrieval mechanism matters less than the full lifecycle: issuance, rotation, revocation, and offboarding.

Best practice is evolving toward external governance for high-risk credentials and platform-native storage only for low-impact or temporary secrets. In practice, the wrong answer usually shows up as secret sprawl in the build system long before anyone notices a policy mismatch.

Related resources from NHI Mgmt Group

• What is the difference between privilege reduction and secret rotation?
• What is the difference between a rules-based secret scanner and a hybrid scanner?
• What is the difference between code scanning and runtime identity monitoring?
• What is the difference between zero trust for users and zero trust for NHIs?