TL;DR: GitGuardian's December 17 demo says recent supply chain attacks are targeting credentials on developer laptops, CI/CD runners, and other reachable environments, and it frames secrets visibility, prevention, and remediation as the practical response. The core challenge is not detection alone but governance across where secrets live, who owns them, and how quickly they can be contained.
At a glance
What this is: GitGuardian's live demo focuses on credential exposure across developer endpoints, CI/CD runners, and other reachable environments, with an emphasis on secrets visibility and remediation at scale.
Why it matters: IAM and NHI teams need to treat exposed secrets as a governance problem across endpoints, vaults, SaaS, and identity providers, not just a cleanup task after detection.
👉 Register for GitGuardian's live demo on credential exposure and NHI visibility, December 17
Context
Secrets exposure becomes a governance failure when credentials are present in places that remain reachable to attackers, such as developer laptops and CI/CD runners. In this case, the problem is broader than secret scanning because ownership, privilege scope, and remediation speed all affect whether exposure turns into compromise.
GitGuardian frames the issue around supply chain attacks because those attacks increasingly target credentials rather than only code or infrastructure. That matters for NHI programmes, where plaintext secrets, over-permissioned access, and unclear ownership can turn routine developer workflows into identity security exposure.
The event is positioned as a practical demo, but the underlying message is about identity visibility: teams need to know where secrets live, who can use them, and whether they can be removed fast enough to shrink blast radius.
Key questions
A: They should identify the owner, the identity type, and every place the credential is reused before attempting cleanup. That sequencing prevents partial remediation, where one copy is revoked but another remains active in a connected system. The first action is to make the exposure traceable to an accountable identity and then remove its ability to authenticate.
Q: Why do leaked credentials in build and developer environments create such a large security risk?
A: Because those environments often contain credentials with access beyond the original workstation or pipeline. Once a secret can authenticate to vaults, SaaS apps, or identity providers, the attacker inherits whatever privilege scope the credential already had. The risk is amplified when the same secret is reused across workflows or left unowned.
Q: What are the signs that a secrets management programme is failing?
A: Common warning signs include inconsistent secret formats, missing scans in configuration files or side repositories, frequent false positives, and teams relying on manual checks instead of automation. Another red flag is when secrets remain exposed long enough to be reused. If scanning does not cover the full development ecosystem, control gaps usually persist.
A: They should use one lifecycle view that covers issuance, reuse, rotation, and revocation across all connected systems. Separate tools often hide the fact that one credential can survive in multiple places after exposure. Governance needs a single ownership model and a measurable retirement process.
Background and context
Why developer endpoints and CI/CD runners are high-risk secret locations
Developer laptops and CI/CD runners are attractive because they often sit at the boundary between trusted build activity and broad network reach. Secrets may appear in plaintext, environment variables, logs, local caches, or automation outputs, and once they exist there, an attacker does not need to break the vault to use them. The governance problem is that these environments are both highly productive and unevenly controlled, which makes them persistent carriers of credential exposure. In NHI terms, the same secret may be reused across workflow steps, creating a wider compromise surface than the original system owner intended.
Practical implication: inventory where credentials appear outside vaults and treat endpoints and runners as first-class secret-bearing assets.
Secrets visibility versus secrets remediation
Secrets visibility is the ability to detect where credentials exist across code, endpoints, SaaS, and connected systems. Remediation is the separate work of revoking, rotating, replacing, or scoping those credentials so they cannot keep working after exposure. Many programmes overinvest in detection and underinvest in ownership and response, which leaves exposed credentials active long after discovery. For NHI governance, that means the risk is not just finding a secret, but proving that the credential can be traced to an owner and retired fast enough to matter.
Practical implication: pair discovery with revocation ownership and measured remediation deadlines, not just alerting.
Why NHI governance depends on ownership and access scope
Non-human identity governance fails when credentials have no clear owner or retain permissions that no one reviews in practice. A secret tied to a service account, pipeline, or SaaS integration can outlive the team that created it, especially when access is inherited through tooling rather than assigned intentionally. That creates over-permissioned access and weak accountability, two conditions that make credential exposure harder to contain. The lesson is not simply that secrets should be rotated, but that the identities behind them must be owned, classified, and periodically revalidated.
Practical implication: map every exposed secret to an owner, an identity type, and a permission scope before remediation begins.
NHI Mgmt Group analysis
Credential visibility without ownership is not governance: seeing exposed secrets is necessary, but it does not answer who owns the identity, who can revoke it, or who is responsible when the same credential appears in multiple execution paths. This topic sits at the intersection of NHI lifecycle control and operational response, where a discovery event only matters if accountability exists. The practitioner conclusion is simple: visibility programmes that stop at detection still leave exposure live.
Developer endpoints and CI/CD runners are identity surfaces, not just devices: the article correctly treats laptops and build runners as places where secrets live and leak, which means endpoint security and NHI governance now overlap. When credentials are embedded in build activity, the access model is no longer limited to a vault boundary. Practitioners need to treat these environments as part of the identity estate, not as external infrastructure.
Over-permissioned access turns exposure into blast radius: once a leaked secret reaches SaaS, vaults, or identity providers with excess privileges, the issue becomes systemic rather than local. The named concept here is identity blast radius: the distance between one leaked credential and the amount of connected access it can unlock. The more reuse and privilege accumulation exist, the farther that blast radius extends.
NHI governance must include remediation speed as a control objective: attackers are moving faster than the manual processes many teams still use to investigate and close secret leaks. That makes time-to-revoke an identity governance metric, not just an incident response metric. Practitioners should measure whether ownership, approval, and revocation paths are short enough to beat attacker reuse.
Visibility across vaults, SaaS, and identity providers exposes lifecycle gaps: the article's emphasis on finding secrets across multiple control planes shows that fragmentation is part of the problem. If a team cannot see where credentials are issued, copied, and reused, offboarding and rotation become partial controls. The practitioner takeaway is to govern the credential lifecycle across systems, not inside one tool.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Identity blast radius: the practical question is not whether a secret was found, but how far that credential can reach before revocation completes. When one exposed token can still authenticate to multiple connected systems, governance has to move from discovery-first to owner-first, with revocation treated as a control outcome rather than a cleanup step.
The metric that matters next is speed of containment. According to the 2024 State of Secrets Management Survey, the average time to mitigate a leaked secret is 36 hours, which is far too slow when attackers can reuse credentials immediately.
For practitioners
- Map every secret to an owner Build a current inventory that ties each secret, token, or API key to a named owner, an identity type, and a business purpose before you begin cleanup.
- Treat CI/CD runners as secret-bearing assets Review build runners, developer endpoints, and automation logs for plaintext credentials, then classify those environments as part of the NHI attack surface.
- Set revocation deadlines for leaked secrets Define a strict time-to-revoke target for exposed credentials and require evidence that rotation or revocation completed before the incident is closed.
- Extend visibility into SaaS and identity providers Track where credentials are reused across vaults, cloud apps, and identity providers so that one leak does not remain active in adjacent control planes.
Key takeaways
- Credential exposure in developer endpoints and CI/CD runners is an identity governance problem as much as a detection problem.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how hard it is to govern non-human access at scale.
- The control that matters most is fast ownership-linked revocation, because exposed secrets remain dangerous until they are retired everywhere they can be used.
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 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 centers on exposed credentials across endpoints and pipelines. |
| NHI-03 — Vulnerable Third-Party NHI | The article links secret exposure to SaaS, vaults, and identity provider dependencies. | |
| NHI-05 — Overprivileged NHI | The piece highlights over-permissioned access as the force multiplier behind leaked secrets. | |
| Recommendation — Scan developer endpoints and pipelines for leaked secrets and revoke exposed credentials immediately. Review third-party credential paths and remove trust in any integration that cannot prove secret containment. Reduce the permissions attached to every exposed secret so compromise cannot expand into adjacent systems. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes leaked credentials being reused to move through connected systems. |
| Recommendation — Map secret exposure to credential access and lateral movement, then prioritize the systems those secrets can reach. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing what exposed credentials can access. |
| Recommendation — Review entitlements attached to each secret and remove any permissions that exceed the business need. | ||
Key terms
- Credential exposure: The condition where a secret, token, key, or certificate becomes visible to a system or user that should not have direct access to it. In AI-assisted workflows, exposure can happen through prompts, files, or agent-accessible directories, which makes containment and runtime gating essential.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Secrets Visibility: Secrets visibility is the ability to discover where credentials exist, how they are used, and which systems depend on them. It is a prerequisite for effective rotation, revocation, and governance. Without it, organisations cannot confidently reduce risk because they do not know the full spread of their exposed credentials.
- NHI Ownership Gap: An NHI ownership gap exists when a credential, service account, or integration has no clear human or system owner accountable for its lifecycle. That gap makes remediation slow, creates over-permissioned access, and leaves exposed secrets active longer than they should be.
What to expect at the briefing
GitGuardian's full webinar covers the operational detail this post intentionally leaves for the source:
- Live demo of secrets visibility across code, endpoints, CI/CD, and other reachable environments
- Practical examples of preventing secrets from living in plaintext on developer laptops
- Investigation and remediation workflows for secret leak incidents at scale
- Visibility into vaults, SaaS applications, and identity providers for ownership and scope tracing
Deepen your knowledge
NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.
Published by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org