They should place controls where secrets first appear, which is often in the editor or source repository, not only in runtime or deployment pipelines. That means aligning code scanning, secret detection, and access governance around the same workflow. If the control arrives too late, the exposure window is already open.
Why This Matters for Security Teams
Secrets controls are not just a deployment concern. They shape whether credentials are exposed during authoring, review, build, or release, and that timing determines how long an attacker has access if a secret leaks. For AppSec, the question is where to detect and block secrets before they become deployable risk. For identity teams, it is where to govern the privileges behind those secrets, especially when non-human identities and automation are involved. The OWASP Non-Human Identity Top 10 is useful here because it frames secrets as part of identity lifecycle risk, not only code hygiene.
The main mistake is treating secret scanning as a final gate rather than a layered control. If secrets are first committed in source code, then CI detection alone is too late to prevent repository exposure, branch propagation, or toolchain reuse. If secrets are issued without ownership, rotation, or scope controls, the leak becomes an identity problem as much as a code problem. In practice, many security teams encounter secret sprawl only after a credential has already been reused across pipelines, environments, or automation jobs, rather than through intentional lifecycle design.
How It Works in Practice
Effective placement starts with mapping where secrets enter the workflow and which team owns each control point. AppSec usually leads on detection in editors, pre-commit hooks, repository scanning, and CI checks. Identity and platform teams usually lead on issuance, scope, rotation, and revocation. The controls should overlap, but not duplicate blindly, because a secret that is discoverable in code and also overprivileged at runtime creates two separate failure modes.
A practical model is to align controls to the earliest viable point in the workflow:
- Developer workstation: block committed secrets with local scanning and policy prompts.
- Source repository: detect committed secrets and quarantine high-confidence findings.
- CI pipeline: validate that no new secrets are introduced and that approved secret references are used instead.
- Deployment and runtime: enforce short-lived credentials, access boundaries, and rotation.
Identity governance matters because not every secret deserves the same treatment. A long-lived API key, a short-lived token, and a service account certificate should not be managed as equivalents. Current guidance suggests pairing secret detection with ownership metadata, so teams know who can rotate it, where it is used, and what downstream systems depend on it. That is where identity control and NIST Cybersecurity Framework 2.0 functions such as identify, protect, and detect become operationally useful. When teams need attack-pattern context, MITRE ATT&CK helps map how exposed credentials are typically abused after initial access.
In mature environments, secret management is also tied to Non-Human Identity governance. Each secret should correspond to a named workload, service, or automation agent, with expiry, rotation, and usage boundaries that are visible to both AppSec and identity owners. These controls tend to break down in polyglot repositories with unmanaged developer tooling because secrets are copied into scripts, notebooks, and test fixtures faster than policy can be enforced.
Common Variations and Edge Cases
Tighter secret controls often increase developer friction, requiring organisations to balance fast delivery against stronger pre-commit and CI enforcement. That tradeoff becomes sharper in monorepos, shared libraries, and ephemeral environments where a single secret can appear in many places at once. Best practice is evolving, but there is no universal standard for how far left every control must move, because the right answer depends on how secrets are created, copied, and consumed.
One edge case is vendor-managed automation. If an external platform issues or stores secrets, AppSec may detect leakage but identity teams may not control rotation, so ownership must be clarified contractually and operationally. Another is secrets embedded in infrastructure-as-code templates. Those files are often treated as safe configuration, yet they are still source artifacts and should be scanned accordingly. For identity-heavy pipelines, the key question is not only whether a secret exists, but whether it is tied to a workload identity that can be audited and replaced without breaking production.
Where organisations use secret brokers, vaults, or short-lived token exchange, the control point shifts from static secret detection to entitlement governance and issuance policy. That approach reduces standing exposure, but it still requires review of who can request a secret, under what conditions, and how misuse is detected. The OWASP Non-Human Identity Top 10 is especially relevant when service accounts, workload tokens, or agent credentials are part of the delivery path.
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, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Secrets controls depend on knowing who and what can access credentials. |
| OWASP Non-Human Identity Top 10 | NH-1 | Non-human identities often own the secrets that power CI/CD and automation. |
| NIST AI RMF | GOVERN | Secret placement is a governance issue across the AI and software supply chain. |
| MITRE ATT&CK | T1552 | Exposed secrets are a common path to credential theft and lateral movement. |
| NIST Zero Trust (SP 800-207) | PA-1 | Just-in-time access reduces standing exposure when secrets are used by automation. |
Define ownership, policy, and accountability for where secrets are detected and approved.
Related resources from NHI Mgmt Group
- How should security teams decide which identity controls to automate first?
- How do teams decide whether email security needs identity controls more than another gateway layer?
- How do teams decide whether runtime security should sit with AppSec or identity?
- Why do fraud teams need to care about identity verification and account lifecycle controls?
