Developer workflow scanning happens during coding, review, or build time, when fixes are cheapest and context is fresh. Post deployment scanning happens later and is better for validation, but it cannot prevent many issues from entering the release path. Mature programmes use both, but shift left for earlier containment and faster remediation.
Why This Matters for Security Teams
Scanning location changes the security outcome. Developer workflow scanning catches issues while code, manifests, or pipeline logic is still being edited, so fixes are cheaper and context is clearer. Post deployment scanning validates what actually shipped, but by then exposure may already exist in production. That distinction matters most for secrets, service accounts, and agent credentials, where a missed issue can become persistent access rather than a simple bug.
This is why NHI governance treats prevention and validation as separate jobs. The Ultimate Guide to NHIs — What are Non-Human Identities shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks. Scanning earlier helps stop those failures before release, while post deployment scanning helps confirm what was missed and what drifted after deployment. The NIST Cybersecurity Framework 2.0 reinforces this split between protective controls and continuous monitoring.
In practice, many security teams discover leaked secrets, misconfigurations, or unsafe pipeline logic only after deployment telemetry or an incident has already exposed them.
How It Works in Practice
Developer workflow scanning usually runs in the places where change is created: local IDE plugins, pre-commit hooks, pull request checks, build pipelines, and infrastructure-as-code review. The goal is to block or flag risky material before it reaches a release artifact. That includes hard-coded API keys, over-permissive service account references, insecure container settings, and agent tool definitions that allow excessive execution authority. For NHI-heavy environments, this is where you catch the problem closest to the source.
Post deployment scanning runs against what is already running. It can inspect cloud assets, container images, deployed manifests, runtime configurations, and exposed endpoints to verify whether the release matches the intended policy. This matters because code review alone cannot see everything that emerges at deployment time, such as environment variable injection, inherited permissions, or secrets introduced by orchestration layers. The difference is operational, not theoretical: one is a gate, the other is an assurance check.
- Use developer scanning to catch secrets, unsafe defaults, and policy violations before merge.
- Use post deployment scanning to detect drift, missed exposure, and runtime configuration mistakes.
- Connect both to the same policy baseline so findings map to the same risk language.
- Prioritise remediation by blast radius, especially where NHIs or CI/CD tokens are involved.
The State of Secrets in AppSec is a useful reminder that remediation lag is still a real problem, and current guidance from the NIST Cybersecurity Framework 2.0 favours continuous monitoring alongside preventative controls. These controls tend to break down when deployments are highly dynamic, because ephemeral environments and rapid configuration drift can outpace scan coverage.
Common Variations and Edge Cases
Tighter scanning earlier in the workflow often increases developer friction, requiring organisations to balance release speed against control coverage. That tradeoff is real, especially when teams are already dealing with fragmented toolchains or frequent hotfixes. Best practice is evolving, not settled, on exactly where the line should sit for AI-generated code, infrastructure-as-code, and agentic automation.
Some environments need both scans to be continuous. For example, a clean pull request can still deploy a vulnerable container image, a permissive cloud role, or a secret injected at runtime by a pipeline variable. Conversely, post deployment scanning alone can miss the moment an issue was introduced, which makes root cause analysis slower and remediation harder. The Google Firebase misconfiguration breach is a useful reminder that exposed configuration often becomes visible only after deployment, when the blast radius is already real. The GitHub Action tj-actions Supply Chain Attack also shows why pipeline-stage scanning matters when credentials can be compromised before they ever reach production.
The practical answer is not either-or. Mature programmes use developer workflow scanning for prevention and post deployment scanning for validation, then tune both to the risk profile of the application, the sensitivity of its NHIs, and the speed of the release process.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Developer and post-deploy scanning both detect weak NHI exposure paths. |
| OWASP Agentic AI Top 10 | A-03 | Agent workflows need policy checks before tool access is granted. |
| CSA MAESTRO | MAESTRO-3 | Covers continuous assurance across build and runtime for autonomous workloads. |
| NIST AI RMF | Supports lifecycle risk monitoring across development and production. | |
| NIST CSF 2.0 | PR.DS-6 | Addresses monitoring for data and secrets protection across environments. |
Use continuous monitoring to detect secrets exposure in build and production stages.
Related resources from NHI Mgmt Group
- What is the difference between a lightweight self-hosted deployment and a standard self-hosted deployment?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
