TL;DR: Truffle Security finds that secrets still leak through CI/CD logs, structured outputs, and public artifacts even when platforms use masking and secret scanning. The underlying problem is that pipeline controls often assume secrets only exist as simple environment variables, while real workflows transform, copy, and publish them in ways redaction cannot reliably catch.
At a glance
What this is: Truffle Security shows that CI/CD secret exposure persists across logs, masking, and artifacts, with transformed and second-order secrets slipping past common protections.
Why it matters: This matters because IAM and NHI teams cannot treat CI/CD redaction as equivalent to governance; the exposed credential path often starts outside the secrets manager and ends in public workflow output.
👉 Read Truffle Security's analysis of how CI/CD pipelines leak secrets
Context
CI/CD secret leakage is a governance problem, not just a logging problem. Pipelines routinely need access to third-party resources, which pushes API keys, tokens, and access keys into build steps where they can be transformed, echoed, exported, or published outside the intended control boundary.
The weak point is the assumption that masking a value at injection time is enough to protect it later. Once a secret is encoded, reversed, embedded in structured data, or carried into an artifact, the pipeline may no longer recognise it as sensitive even though an attacker can still extract it from the output.
Key questions
Q: What breaks when secrets are stored in code and CI/CD tools?
A: Access becomes invisible, reusable, and hard to revoke, which means the organisation loses control of where authentication material exists. Once secrets are embedded in code or pipeline tools, discovery gets harder, offboarding slows down, and the same credential can survive multiple deployment cycles.
Q: Why do public build logs create so much risk for API keys and tokens?
A: Public build logs turn routine job output into an accessible collection point for credentials, especially in open-source or shared environments. If a workflow prints environment variables, verbose command output, or decrypted values, an attacker can harvest working secrets without compromising the build system itself.
A: Use layered controls that reduce exposure before secrets ever reach logs, then shorten the attack window when leakage still occurs. The practical mix is secret masking, log expiration, parsing-aware scanning, and user education for any feature that can reveal environment variables. If a secret is exposed, rotate it immediately, because detection without revocation still leaves an exploitable credential behind.
Q: What is the difference between log masking and secret governance in pipelines?
A: Log masking is a narrow detection layer that tries to hide known values in output, while secret governance controls where credentials are created, stored, transformed, and released. A pipeline can have strong masking and still leak secrets through files, artifacts, or derived outputs.
Technical breakdown
Why CI/CD masking fails on transformed secrets
CI/CD masking usually works by matching known secret values or expected token patterns in job output. That approach breaks when a pipeline changes the secret before printing it, such as reversing a string, base64-encoding it, or passing it through intermediate commands that alter its shape. Redaction engines can also miss partial matches when secrets are stored in structured files or split across multiple outputs. The core issue is that the protection layer is looking for the original token form, while the attacker only needs any recoverable representation of the credential. Read Guide to the Secret Sprawl Challenge.
Practical implication: Treat log redaction as a detection aid, not as a control that can absorb transformed credentials.
How second-order secrets escape the platform's view
Second-order secrets are credentials that are not directly injected as a visible environment variable but are derived from one, such as decrypted file contents, OAuth refresh tokens, signed URLs, or secrets pulled from an external vault. A CI/CD platform may only know about the decryption key or wrapper variable, not the secret material revealed later in the job. That means the platform can mask the input while leaving the output exposed. This is an identity scope problem as much as a secrecy problem, because the pipeline has more effective access than the logging layer understands. See the Secrets Management Guide.
Practical implication: Separate secret retrieval from public-facing steps so the pipeline never has to reveal decrypted material where logs or artifacts are exposed.
Why artifacts create a separate exposure channel
Artifacts are not logs, so secret masking logic does not necessarily apply to them. If a build step packages a file that contains embedded credentials, the artifact itself becomes the leak path even when no log line shows the secret. This is especially dangerous in publish workflows where test files, config files, or generated bundles are carried from a private build context into a public distribution context. In practice, the issue is control boundary drift: the job that may safely touch a secret is not the same job that should be allowed to export content derived from it. See the Secrets Management Buyer's Guide.
Practical implication: Audit the files that move from test and build stages into published artifacts before release steps run.
Threat narrative
Attacker objective: The attacker wants reusable access to third-party services, build outputs, or publishing workflows by harvesting secrets from public or semi-public CI/CD output.
- Entry occurs when a CI/CD job receives valid API keys, access keys, or tokens for third-party services as part of normal build execution.
- Credential exposure follows when the workflow prints, transforms, decrypts, or republishes those values in logs or artifacts that are accessible outside the private build context.
- Impact occurs when attackers recover the exposed secrets and use them to access downstream services, publish poisoned artifacts, or continue credential abuse from trusted pipeline output.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
CI/CD secrets exposure is a lifecycle failure, not a single control failure: the problem spans injection, transformation, reuse, and publication. Masking only addresses one moment in that lifecycle, while attackers exploit every later stage where the secret changes shape or leaves the job boundary. The practitioner lesson is to govern the full secret path, not just the initial variable value.
Second-order secrets create blind spots that secrets managers do not remove by themselves: if a pipeline decrypts files, pulls credentials from an external store, or generates derived tokens, the platform may never see the actual sensitive value in time to mask it. Static vs dynamic secrets matter here because the control question is whether the credential stays recognisable and governable after transformation. The implication is that visibility must extend beyond the injection point.
Public artifacts convert build pipelines into distribution channels for credential leakage: once a secret is embedded in a file that gets packaged, uploaded, or published, the exposure is no longer a log problem. That creates an identity blast radius problem in which a build job with legitimate access can still create long-lived downstream exposure. The practical conclusion is that artifact governance belongs in the same control conversation as credential governance.
Least privilege for pipelines is usually applied too late: the article shows that the dangerous step is often not authentication itself but allowing one job to both touch sensitive material and publish outward-facing output. That pattern violates the assumption that a single pipeline can safely span private and public trust zones. Practitioners should treat CI/CD jobs as scoped identities with sharply separated duties, not as interchangeable automation containers.
From our research library:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 82% of detections were malware-free, with attackers using valid credentials and trusted tools, according to CrowdStrike's 2026 Global Threat Report.
- Read next: Secrets Management Guide
What this signals
Secret leakage in CI/CD is really an identity scoping problem: build jobs often receive more credential power than the downstream release step should ever inherit. Once that power is reused across test, build, and publish phases, the pipeline itself becomes the leak path rather than the victim of one.
Static vs dynamic secrets is the control boundary practitioners should watch most closely here. If a credential must survive long enough to be transformed, reused, and published, then the governance model is already too loose for the pipeline trust zone.
Pipeline programmes should assume that log redaction will miss at least some transformed or second-order values, so detection must extend to artifacts and historical output. That shifts the operational question from whether a secret was masked to whether the workflow ever allowed sensitive material to cross into a public or semi-public boundary.
For practitioners
- Separate private and public pipeline stages Run secret-handling steps in isolated jobs and keep release or publication work in a different job with no access to decrypted material.
- Inventory every secret exposure path Map where credentials appear in logs, environment variables, decrypted files, structured config, and published artifacts so the same secret is not governed by only one path.
- Rotate credentials after pipeline exposure Treat any leaked CI/CD token, key, or refresh credential as compromised and revoke it before it can be reused in downstream services. See the API Key Management Guide.
- Avoid structured secret blobs in pipelines Do not bundle secrets into JSON or other structured formats when the build system cannot reliably recognise transformed or partial leaks.
- Scan historical logs and artifacts continuously Include prior build logs, artifacts, and published package contents in routine secret discovery so old exposures do not remain active indefinitely. See the Secrets Management Buyer's Guide.
Key takeaways
- CI/CD secret leakage persists because the same credential can appear in logs, structured output, decrypted files, and published artifacts.
- The exposure path is broader than injection or masking, which is why transformed and second-order secrets are especially hard to catch.
- The most effective control change is to separate secret-bearing jobs from public release steps and treat any exposed token as compromised.
Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · Ultimate Guide to NHIs: Static vs Dynamic Secrets · Secrets Management Guide · CircleCI breach 2023
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article is centered on exposed API keys, tokens, and passwords in CI/CD output. |
| NHI-07 — Long-Lived Secrets | The article shows how long-lived keys survive across jobs, logs, and publish steps. | |
| NHI-03 — Vulnerable Third-Party NHI | CI/CD jobs rely on third-party services and exposed third-party credentials expand the blast radius. | |
| Recommendation — Scan pipelines for exposed secrets and revoke any credential that appears in logs or artifacts. Replace long-lived pipeline secrets with shorter-lived credentials wherever the workflow allows it. Review third-party pipeline access paths and remove credentials that are not required for each job. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle control is directly implicated by leaked pipeline tokens and keys. |
| Recommendation — Apply authenticator lifecycle controls to rotate and revoke CI/CD credentials after any suspected exposure. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article describes attacker harvesting of credentials from logs and artifacts. |
| Recommendation — Map leaked pipeline output to credential access and exfiltration techniques and hunt for exposed secrets. | ||
Key terms
- CI/CD Secret Leakage: CI/CD secret leakage is the accidental exposure of credentials, tokens, keys, or certificates inside build and deployment pipelines. It occurs when secrets are stored in code, logs, artifacts, environment variables, or pipeline configurations. This creates unauthorized access risk across source control, cloud services, and production systems.
- Second-order secret: A second-order secret is sensitive material that appears only after another credential or key is used, such as decrypted file contents or derived tokens. These secrets are often missed by log masking because the platform sees the wrapper value, not the final sensitive data that the workflow reveals.
- Artifact leakage: Artifact leakage happens when a build or deployment output package contains secrets that were meant to stay inside the pipeline. Unlike log exposure, the secret may not be visible in console output at all, which makes file and release governance just as important as redaction.
- Secret Masking: Secret masking hides sensitive values from logs, but it does not remove those values from memory, environment variables, or filesystem state. It is a visibility control, not a containment control, so it cannot stop an attacker who already has code execution inside the runner.
What's in the full article
Truffle Security's full post covers the operational detail this analysis intentionally leaves for the source:
- Example CI/CD configurations showing how secrets leak through verbose output and transformed values
- Practical handling of encrypted files, third-party vaults, and second-order credential exposure
- Specific workflow examples where public artifacts carry hidden API keys into distribution
- Platform-by-platform notes on how TruffleHog scans current and previous CI/CD logs
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org