Why do secrets and misconfigurations still reach production even with modern scanning in place?

Why This Matters for Security Teams

Modern scanning can reduce risk, but it does not guarantee that risky code, exposed credentials, or weak infrastructure settings are stopped before release. The common failure is not the absence of tools, but the way they are used: narrow scan scopes, late-stage review, and unclear ownership between application, platform, and security teams. NIST’s control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames security as an ongoing control system, not a one-time check.

Secrets and misconfigurations still reach production when organisations assume a scanner is equivalent to prevention. A scanner may detect a hard-coded token, but it cannot always determine whether deployment automation reintroduced the same token, whether a cloud bucket policy opened access later, or whether a service account now has excessive privilege. The same pattern appears with agentic systems and service-to-service trust: identity, credential, and policy mistakes often survive because they are spread across code, CI/CD, cloud configuration, and runtime permissions. In practice, many security teams encounter these issues only after a production incident, rather than through intentional release governance.

How It Works in Practice

Effective programmes treat scanning as one input into a broader prevention and verification workflow. That means scanning source code, build artefacts, infrastructure-as-code, container images, and deployed environments, then correlating results so the same issue is not rediscovered in multiple tools without being fixed. For secrets, the control objective is not only detection, but also elimination, rotation, and proof that the secret is no longer usable. For misconfigurations, the objective is to prevent insecure defaults from being merged, promoted, or inherited by downstream environments.

This is where identity and privilege matter. A secret is rarely dangerous on its own; it becomes dangerous when it authorises a service, pipeline, or non-human identity to act with excessive scope. The OWASP Non-Human Identity Top 10 is relevant because many production exposures come from service accounts, workload identities, API keys, and automation tokens that are created once and then over-trusted for too long.

• Shift-left scanning should catch issues before merge, not after deployment.
• Policy-as-code should block known-bad configurations in pipelines and infrastructure templates.
• Runtime checks should confirm that production state matches approved baselines.
• Secret rotation should be automatic when exposure is confirmed, not left to manual remediation.
• Ownership should be explicit so findings do not stall between Dev, Sec, and platform teams.

Best practice is evolving toward continuous validation, but there is no universal standard for how many scanning layers are enough. These controls tend to break down in fast-moving multi-account cloud environments because asset sprawl and duplicated identities make ownership, baseline comparison, and remediation tracking inconsistent.

Common Variations and Edge Cases

Tighter prevention often increases delivery overhead, requiring organisations to balance release speed against the cost of deeper validation. That tradeoff becomes sharper in regulated or highly distributed environments where teams rely on multiple scanners, ephemeral infrastructure, and frequent automated deployments. Current guidance suggests that the strongest programmes focus less on tool count and more on control coverage, false-positive management, and measurable remediation closure.

Edge cases matter. A secret may be detected in a repo after it has already been copied into logs, test fixtures, or build caches. A misconfiguration may pass one scanner but still expose data because a later deployment layer overrides the intended setting. In containerised and serverless platforms, inherited permissions and default network exposure often create gaps that traditional code scanning does not fully see. In those cases, teams need runtime attestation, environment drift detection, and clear rules for when a finding blocks release versus triggers post-deploy remediation.

For organisations building or operating AI-enabled systems, this problem can also involve model pipelines, agent credentials, and orchestration tokens. The key question is not just whether a secret exists, but whether a machine identity can use it in ways the business never intended. That is why identity governance, secret hygiene, and configuration baselines should be managed together rather than as separate programmes.

Related resources from NHI Mgmt Group

• Why do shared service accounts still create risk even when secrets are vaulted?
• Why do AI agent sandboxes still leak secrets even when egress policies are enforced?
• Why do identity-first programmes still fail even when SSO and MFA are in place?
• Why do modern phishing campaigns still succeed even with strong IAM controls?