TL;DR: Truffle Security found 453 publicly exposed Jenkins servers without authentication requirements, and 3% of scanned servers contained at least one live secret in build logs, including API keys and passwords. Secret leakage here is not just a discovery problem, because unauthenticated access turns logs into a credential exposure path.
At a glance
What this is: Truffle Security reports that hundreds of publicly exposed Jenkins servers were browsable without authentication, and a measurable share of build logs contained live credentials.
Why it matters: This matters because log access, secret scanning, and credential revocation sit on the same control plane for NHI governance, and a weak link in any one of them can expose live keys.
By the numbers:
- 3% of all scanned servers contained at least one live secret.
- Truffle Security found 453 live, publicly exposed Jenkins servers without any authentication requirements.
- TruffleHog identified 26 unique, live secrets from 14 different servers.
👉 Read Truffle Security's analysis of leaked secrets in public Jenkins logs
Context
Public build logs become an identity security problem when they contain reusable credentials. In this case, the issue is not Jenkins itself but the combination of unauthenticated access, operational logging, and live secrets that were never meant to be visible outside the environment.
That combination creates a governance gap for machine identities, because API keys and passwords often outlive the workflow that generated them. secret sprawl is the natural failure mode when logs, build systems, and credential lifecycles are treated as separate controls.
The article’s starting position is typical of many exposed automation environments: the platform is not inherently the failure, but weak access control around it lets normal operational telemetry become a secret repository.
Key questions
Q: What breaks when Jenkins build logs are publicly accessible?
A: The boundary between operational telemetry and credential custody breaks. If logs are public, they can expose live API keys, passwords, and tokens that were never intended to leave the build system. That turns diagnostics into a credential distribution channel and gives attackers a path into downstream services that trust those credentials.
Q: Why do leaked build secrets often lead to broader compromise?
A: Because the secret is usually trusted outside the system that exposed it. A key in a build log may authenticate to cloud, SaaS, or internal services, so disclosure creates a reuse opportunity rather than just an information leak. The broader the credential scope, the larger the blast radius once it is exposed.
Q: How do security teams measure whether secret scanning is actually reducing exposure?
A: Security teams should measure the time from secret creation to detection, the percentage of repositories and build artifacts scanned, and the time from detection to rotation or revocation. Strong programmes also track how many exposed secrets remain valid after discovery. Those signals show whether scanning is finding risk early or only after exposure has spread.
Q: What should teams do when a CI/CD credential is exposed?
A: Revoke the token, validate the affected pipeline and artifact chain, and confirm whether the credential was used for deployment or build access. Then rotate any related secrets, review recent pipeline changes, and verify that protected environments and approvals still block unauthorized release activity.
Technical breakdown
Why unauthenticated build logs become credential exposure surfaces
Build logs often contain command output, environment variables, deployment steps, and error traces. When a Jenkins instance is public and unauthenticated, those logs stop being internal telemetry and become a searchable repository of secrets. The risk is not just disclosure of one credential. It is the propagation of machine identity material, especially API keys and passwords, into a system that was designed for diagnostics rather than secret custody. This is a classic secret leakage problem, but one amplified by automation because the same log stream can expose many credentials across many jobs. Read Guide to the Secret Sprawl Challenge.
Practical implication: Treat job logs as part of the secret surface, not just the observability stack.
How exposed Jenkins servers turn secrets into lateral movement risk
If an attacker can read build logs, they can often harvest credentials that belong to cloud providers, SaaS platforms, or internal services. Once a live key is recovered, the next step is not necessarily immediate exploitation of Jenkins itself. The more common pattern is pivoting into secondary systems that trust the leaked credential. That is why service account and API key governance matter here: the credential may be created in one place, logged in another, and accepted elsewhere without clear ownership or lifecycle visibility. The exposure window is created by the credential, but the blast radius is created by downstream trust. See the API Key Management Guide.
Practical implication: Map every credential in build output to its downstream systems and revoke it on exposure.
Why secret scanners help, but do not close the governance gap
A scanner can identify exposed secrets, but detection alone does not restore control. The article shows that live secrets still existed in logs at the time of testing, which means the operational model depended on discovery after exposure. That is too late if the secret is usable immediately. The deeper issue is that build systems often lack enforced boundaries between runtime telemetry and credential custody. Without authentication on the platform itself and without lifecycle controls on the secrets it emits, secret scanning becomes a compensating control rather than a preventative one. See the Leaked Credential and Secret Incident Response Playbook.
Practical implication: Use scanning as confirmation, not as the primary control for protecting build-generated secrets.
Threat narrative
Attacker objective: The attacker’s objective is to harvest valid machine credentials from operational logs and reuse them to access secondary systems.
- Entry occurred through publicly exposed Jenkins instances that could be browsed without authentication.
- Credential access followed when build logs revealed live API keys and passwords that were still valid.
- Impact arose when those credentials could be reused against cloud and SaaS systems that trusted them.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
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
Unauthenticated build visibility is a governance failure, not just a misconfiguration: when public access reaches internal job logs, the control boundary around machine credentials has already broken. That means the problem spans IAM, secrets management, and platform administration, not one isolated Jenkins setting. The practitioner implication is that log access must be governed with the same discipline as credential issuance.
Secret leakage in build logs is a lifecycle failure for non-human identities: the credential was not protected at the point of creation, not revoked at the right time, and not isolated from operational telemetry. static credentials are especially vulnerable because once they appear in logs, they remain usable until someone actively finds and invalidates them. The implication is that NHI governance must treat log emission as part of the credential lifecycle.
Secret scanning alone creates a false sense of control: detection proves exposure, but it does not change the fact that the secret was live long enough to be abused. That is why this pattern should be read as a trust problem, not a tooling problem. The practitioner implication is to move enforcement upstream of disclosure.
Public CI/CD exposure creates identity blast radius that crosses system boundaries: one exposed Jenkins instance can reveal credentials for AWS, GitHub, Slack, or other services, which then inherit the risk of the weakest log boundary. This is why NHI governance and third-party access control must be evaluated together. The practitioner implication is to inventory where build-time secrets can reach after they are leaked.
From our research library:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
- Read next: Leaked Credential and Secret Incident Response Playbook
What this signals
Secret sprawl is no longer confined to vaults and code repositories. When build platforms can emit live credentials into readable logs, the operational boundary that matters is the one between runtime output and revocation, not the one between development and production.
Build-log credential exposure: this is the pattern where automation telemetry becomes a secret source because access control and credential hygiene are handled separately. The practical implication is that IAM teams must review logging paths with the same seriousness they apply to secret storage and rotation.
For practitioners, the next step is to assume that any unauthenticated or weakly protected build surface may already contain exploitable secrets. That changes the priority order from detection first to containment first.
For practitioners
- Restrict build-log access to authenticated users only Remove public access to Jenkins logs and verify that every job output path is behind an enforced identity check.
- Inventory every secret that can appear in CI output Map API keys, passwords, tokens, and service credentials to the pipelines and jobs that can print them.
- Revoke exposed credentials immediately after discovery Treat any live secret found in logs as compromised until it is rotated or invalidated and downstream access is confirmed closed.
- Scan logs on an ongoing schedule Run secret detection against job logs and build artifacts so leaked credentials are identified before they are reused elsewhere.
Key takeaways
- Public Jenkins logs can become a credential exposure channel when authentication is missing and build output contains live secrets.
- The article’s evidence shows both scale and impact, with hundreds of exposed servers and live credentials found in multiple logs.
- The strongest control response is to lock down log access, eliminate secret leakage at source, and revoke any exposed credential immediately.
Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · API Key Management Guide · Leaked Credential and Secret Incident Response Playbook · Ultimate Guide to NHIs: Static vs Dynamic Secrets
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 CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Build logs exposed live credentials, which is the core secret leakage pattern in this article. |
| NHI-07 — Long-Lived Secrets | The article shows that live secrets remained valid after exposure, which is the long-lived secrets problem. | |
| Recommendation — Scan CI logs for exposed secrets and revoke any credential that appears in build output. Replace static credentials in build pipelines with shorter-lived alternatives where possible. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest Confidentiality | Build logs exposed sensitive credential data that should have been protected from unauthorized disclosure. |
| Recommendation — Apply data protection controls to logs and artifacts that can carry secrets. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | API keys and passwords in logs require lifecycle control under authenticator management. |
| Recommendation — Enforce issuance, storage, and revocation controls for all authenticators used in CI systems. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article describes harvesting credentials from logs and the potential to pivot to other systems. |
| Recommendation — Hunt for credential harvesting in logs and investigate any secondary access using the exposed secrets. | ||
Key terms
- Build Log Secret Exposure: Build log secret exposure occurs when CI/CD output contains tokens, keys, passwords, or other credentials that should never be visible outside the runtime context. In practice, the risk is not just leakage to the console but persistence in searchable logs, artifacts, and shared observability systems.
- Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.
- Credential Revocation: Credential revocation is the process of disabling a secret, token, or key so it can no longer authenticate or authorize action. It is the operational half of detection, because exposed credentials remain dangerous until they are invalidated and replaced across every dependent system.
- Build System Attack Surface: The build system attack surface is the collection of places where an attacker can influence compilation, testing, packaging, or deployment. It includes servers, plugins, credentials, permissions, and integrations. Securing this surface is critical because compromise can affect many downstream software artifacts and release processes.
What's in the full report
Truffle Security's full post covers the operational detail this post intentionally leaves for the source:
- The Shodan and nuclei workflow used to identify public Jenkins instances
- The exact Jenkins build-log scanning command used to find live secrets
- The breakdown of secret types found across AWS, Alibaba, GitHub, OpenAI, and Slack
- The disclosure approach used after the exposed servers were identified
Deepen your knowledge
NHI governance, secrets management, and workload identity security 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