Topic starter
19/10/2026 5:39 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “How Secrets Leak in CI/CD Pipelines”.
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.
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.
A: Use layered controls that reduce exposure before secrets ever reach logs, then shorten the attack window when leakage still occurs.
Practitioner guidance
- 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.
Bottom line: CI/CD secret leakage persists because the same credential can appear in logs, structured output, decrypted files, and published artifacts.
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
👉 Read Truffle Security's analysis of how CI/CD pipelines leak secrets →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/10/2026 5:39 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Secrets leak in CI/CD pipelines despite masking and scanning