Build-Time Secret

Expanded Definition

A build-time secret is not the same as a runtime secret or a long-lived application credential. It is a credential exposed to build automation only when code is being compiled, tested, packaged, or published, and it should exist for the shortest practical window. In NHI security, the key distinction is not simply where the secret lives, but whether it is scoped to a controlled pipeline step, tied to a specific artifact path, and removed immediately after use. Good practice increasingly favors ephemeral credentials, short TTLs, and brokered access rather than embedding reusable tokens into CI/CD jobs. Guidance varies across vendors on how to implement this safely, but the operational goal is consistent: reduce standing exposure while preserving build functionality. The OWASP Non-Human Identity Top 10 treats secret handling as a core NHI risk area, and NHIMG’s broader guidance on Ultimate Guide to NHIs - Static vs Dynamic Secrets frames the preference for dynamic issuance wherever possible. The most common misapplication is treating a build credential like a harmless developer convenience, which occurs when a shared token is copied into pipelines, logs, or configuration files.

Examples and Use Cases

Implementing build-time secrets rigorously often introduces pipeline complexity, requiring organisations to weigh faster automation against tighter credential scoping, rotation, and auditability.

• Signing a software package in CI with a short-lived certificate issued only for the release job, then revoked after artifact creation.
• Pulling private dependencies from an internal registry during build, using a token that cannot be reused outside that pipeline stage.
• Authenticating to cloud services for integration tests with a narrowly scoped secret that expires before deployment.
• Accessing container registries during image build, then deleting the credential from the runner before the job completes.
• Using secret brokers or OIDC-style federation instead of hard-coded keys, reducing reuse across environments and repositories.

These patterns are frequently discussed in NHIMG research such as the CI/CD pipeline exploitation case study and the Guide to the Secret Sprawl Challenge, both of which show how pipeline credentials become attack paths when they are reused or exposed. For implementation patterns, the same concern appears in the OWASP Non-Human Identity Top 10, especially where automation tokens are overprivileged or left discoverable in build output.

Why It Matters in NHI Security

Build-time secrets matter because they sit at the intersection of software supply chain trust and NHI governance. A single exposed pipeline credential can grant access to source code, registries, deployment targets, and cloud control planes, turning a build system into a lateral-movement foothold. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which means build-time exposure is not an edge case but a common control failure. That risk is amplified when the same secret is reused across multiple jobs or environments, because compromise of one runner can cascade into broader access. This is why NHI programs treat build credentials as governed identities, not just tooling settings, and align them with least privilege, rotation, and offboarding discipline. The operational implications are also reflected in the 52 NHI Breaches Analysis and in incidents like the Shai Hulud npm malware campaign, where exposed automation secrets became a supply chain problem. Organisations typically encounter build-time secret risk only after a pipeline compromise, at which point credential containment becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Hardcoded Secret
• What is the difference between secret rotation and just-in-time access?
• What is the difference between build-time scanning and deployment-time policy checks?
• Just-in-Time Secret Delivery