They often treat these secrets as operational conveniences instead of high-value identities. In practice, developer laptops and CI runners are rich credential stores, and tokens that remain valid for long periods are ideal for republishing, impersonation, and downstream access. Secrets should be governed like privileged access, not cache data.
Why Security Teams Misread Developer and CI Secrets
Developer laptops, build agents, and CI runners are not just tooling environments. They are identity-rich execution points where secrets become the fastest path to impersonation and lateral movement. The recurring mistake is treating tokens as temporary conveniences instead of privileged access. NHI Management Group’s State of Secrets in AppSec found that only 44% of developers consistently follow secrets best practices, while the average time to remediate a leaked secret is 27 days. That gap turns exposure into durable access.
Security teams also underestimate how quickly a leaked secret can be republished into a different workflow, repository, or automation system. A token copied from a local shell history or CI variable can outlive the incident that exposed it. Current guidance from OWASP Non-Human Identity Top 10 is clear that secrets must be governed as identities, not as disposable configuration data. In practice, many teams only discover the real blast radius after a pipeline compromise has already reached downstream systems.
How Secrets Behave in Developer Workstations and CI Pipelines
In practice, the risk is not just storage. It is reuse, propagation, and over-scoping. A developer secret often exists in multiple places at once: environment variables, dotfiles, shell history, package manager configs, IDE plugins, and copied snippets in tickets or chat. CI secrets are even more fragile because they are repeatedly injected into ephemeral runners, reused across jobs, and often granted broad access to compensate for broken pipeline design.
The best operational model is to treat each secret as a workload identity with a narrow purpose, short lifetime, and explicit revocation path. That means replacing long-lived static credentials with short-lived tokens where possible, binding them to the exact workload or pipeline stage that needs them, and rotating them automatically after task completion. Guidance from the Guide to the Secret Sprawl Challenge and the CI/CD pipeline exploitation case study shows that the problem is usually not one secret, but uncontrolled duplication across systems.
- Issue secrets just in time for the specific build, test, or deploy action.
- Prefer workload-bound credentials over shared human-style tokens.
- Limit scope to one repository, one environment, or one job where feasible.
- Revoke on completion, not on a calendar that assumes human behaviour.
- Detect leakage in code, logs, artifacts, chat, and ticketing systems.
For implementation, teams should align secret issuance with policy-as-code and pipeline attestations, then verify that each token can be traced back to a single identity and purpose. These controls tend to break down in monorepos with shared runners and unmanaged developer tooling because access paths multiply faster than review processes can track them.
Where the Standard Advice Breaks Down
Tighter secrets control often increases friction, so organisations have to balance developer velocity against exposure reduction. The hard cases are the ones security teams tend to normalise: shared CI templates, temporary hotfix tokens, vendor integrations, and emergency access during outages. Those exceptions frequently become the default path if there is no automated issuance and revocation workflow.
There is no universal standard for every environment, but current guidance suggests one rule should hold: if a secret can be copied, it can be reused; if it can be reused, it can be abused. That is why long-lived credentials are especially dangerous in code-hosting and CI environments, where Shai Hulud npm malware campaign and other supply-chain incidents show how quickly secrets move from one system into many. The practical answer is to assume secrets will leak and design for fast invalidation, not perfect prevention.
Teams also miss the fact that internal repositories are not inherently safe. NHI Management Group’s research on The State of Secrets Sprawl 2026 found that leaked secrets often remain valid long after detection, which means inventory without revocation creates false confidence. In environments with fragmented CI providers, legacy build scripts, or unmanaged service accounts, the guidance breaks down because nobody can prove where the credential is still active.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Static secrets and poor rotation create durable non-human identity risk. |
| OWASP Agentic AI Top 10 | Build and automation identities behave like tool-using agents with execution authority. | |
| NIST AI RMF | Secret misuse in automated workflows is a governance and accountability problem. |
Replace long-lived developer and CI secrets with short-lived, revocable credentials.
