Who is accountable when developers store secrets inside code or local workflows?

Why This Matters for Security Teams

When developers place secrets in code, notebooks, shell history, or local workflows, accountability stops being a simple ownership question and becomes an operational control gap. The issue is not only where the secret lived, but whether the organisation had a clear standard for issuance, storage, detection, and revocation. NIST SP 800-53 Rev 5 Security and Privacy Controls treats access control, configuration management, and auditability as core safeguards, which is why secret handling cannot remain a personal preference.

NHI Management Group research shows why this matters in practice: in The State of Secrets in AppSec, the average time to remediate a leaked secret is 27 days, even though 75% of organisations report strong confidence in their secrets management capabilities. That gap is exactly where accountability breaks down. If application security owns the policy, platform engineering owns the controls, and development leaders do not enforce daily adoption, developers will keep using whatever is fastest.

In practice, many security teams discover the failure only after a credential has already been reused outside the intended workflow.

How It Works in Practice

Accountability works best when it is mapped to decision rights, not just incident cleanup. Security leaders define the rule: secrets must not be embedded in code, local files, or ad hoc developer tools. Platform engineering then provides the approved path, such as a central secrets manager, ephemeral tokens, local development wrappers, and CI/CD injection at runtime. Engineering managers and tech leads ensure the rule becomes part of normal delivery, code review, and release criteria.

For detection and prevention, the control stack should cover both source and workflow boundaries. The OWASP Non-Human Identity Top 10 reinforces that machine credentials need lifecycle governance, not just storage discipline. That matters because secrets in local workflows often reappear in build logs, pipeline variables, browser caches, and developer-owned automation. NHIMG research on Guide to the Secret Sprawl Challenge shows how fragmented tooling creates hidden exposure paths that standard ticketing does not capture.

• Set a single policy for where secrets may exist and where they are forbidden.
• Use pre-commit and CI scanning to catch hardcoded credentials before merge.
• Issue short-lived credentials for local development instead of static shared keys.
• Require rapid revocation and rotation when a leak is detected.
• Assign named ownership for enforcement, exceptions, and remediation timelines.

That operating model should be backed by code review checks, pipeline guardrails, and audit trails that prove whether approved tooling was actually used. NHIMG’s CI/CD pipeline exploitation case study shows how quickly developer convenience can become an attacker path when local secrets bleed into automated systems. These controls tend to break down in highly distributed teams with inconsistent local environments because policy enforcement disappears once developers work outside centrally managed tooling.

Common Variations and Edge Cases

Tighter secret controls often increase developer friction, so organisations have to balance speed against the risk of silent exposure. That tradeoff is especially visible in data science notebooks, proof-of-concept work, contractor environments, and air-gapped development setups where standard secrets managers are harder to integrate. Current guidance suggests allowing temporary exceptions only when they are time-bound, logged, and tied to explicit compensating controls.

There is also no universal standard for how much responsibility should sit with individual developers versus platform teams. Best practice is evolving toward shared accountability, but the practical split depends on who controls the toolchain. In smaller teams, a security champion model may work better than a formal governance committee. In larger enterprises, policy without platform automation usually fails because developers cannot reliably distinguish an approved local workflow from a risky one.

For deeper context on how credential sprawl escalates across repositories, pipelines, and third-party integrations, see 52 NHI Breaches Analysis and Ultimate Guide to NHIs - Static vs Dynamic Secrets. The key edge case is local-first development with offline tooling, where secrets may be copied into files simply to keep work moving, making enforcement dependent on developer habits rather than system design.

Related resources from NHI Mgmt Group

• Who is accountable when developers leak credentials through unmanaged .env workflows?
• Who is accountable when vulnerable code or leaked secrets reach production through GitHub workflows?
• Who is accountable for securing non-human identities and their secrets?
• Who is accountable when exposed secrets are found in public workflow logs after a supply chain compromise?