Runtime changes, manual console edits, and API-driven drift all fall outside the scanner’s view. That means the team can approve code that no longer matches the live environment by the time it matters. The result is false confidence, especially when secrets or permissions change after deployment.
Why This Matters for Security Teams
Pre-deployment IaC scanning is valuable, but it only validates the declared configuration at commit or pull request time. Once infrastructure is deployed, the risk picture changes quickly through console edits, auto-scaling actions, emergency fixes, pipeline overrides, and secret rotation. A code-only control can therefore leave material gaps in accountability, detection, and change assurance. NIST SP 800-53 Rev. 5 Security and Privacy Controls makes clear that continuous monitoring and configuration management are part of a defensible control environment, not optional extras. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames security as an ongoing operating state rather than a one-time review.
The practical problem is that teams often treat a clean scan as evidence that the environment is secure, when it is really evidence that the file looked acceptable at a moment in time. That distinction matters most in cloud and container estates where permissions, network exposure, and secrets can change outside the repository. In practice, many security teams encounter drift only after an incident review reveals that the live system no longer matched the approved IaC state.
How It Works in Practice
A mature control set treats pre-deployment scanning as one checkpoint inside a larger lifecycle. The scanner should catch unsafe patterns before merge, but the organisation also needs post-deployment validation, drift detection, and runtime telemetry to confirm that the deployed state still matches policy. That usually means combining CI checks with cloud configuration monitoring, change alerts, and periodic reconciliation against the authoritative IaC source. The NIST SP 800-190 Application Container Security Guide is relevant because containers and orchestration platforms often mutate after initial deployment through redeployments, image changes, and orchestration events.
- Scan IaC for insecure defaults such as open security groups, overly broad IAM, or plaintext secrets.
- Validate deployed resources against the same policy baseline after release.
- Detect drift when console edits, scripts, or automation alter live settings.
- Correlate configuration changes with approval records and incident alerts.
For environments using cloud-native controls, this should also connect to the organisation’s broader detection and response stack. CISA guidance on cloud logging and configuration monitoring is a useful reference point for building visibility across both planned and unplanned changes. CISA Cloud Security Technical Reference Architecture supports the operational point that secure cloud posture depends on observability as much as on policy-as-code.
Where identity is involved, the issue becomes sharper. A scanner may approve a role definition, while the live environment later acquires additional permissions, a new access key, or an inherited trust relationship that the code never represented. These controls tend to break down when teams allow direct production changes and do not reconcile cloud state back to source-controlled policy because the scanner has no view of out-of-band modification.
Common Variations and Edge Cases
Tighter pre-deployment control often increases release friction, requiring organisations to balance speed against assurance. That tradeoff becomes more visible in high-change environments, where emergency fixes, blue-green deployments, and platform-managed resources can create legitimate drift without indicating a security failure. Best practice is evolving here: there is no universal standard for how aggressively every runtime deviation should be blocked versus observed, especially in autoscaled or ephemeral infrastructure.
Edge cases matter. Some resources are intentionally mutable, such as temporary scaling policies, incident response changes, or service-managed certificates. Other environments, including serverless platforms and managed Kubernetes clusters, can generate configuration changes that are not obvious from the IaC repository alone. In those cases, the security objective is not zero drift at any cost, but controlled drift with evidence, approval, and alerting. The CISA secure cloud logging and monitoring material helps anchor that operational expectation.
For NHI governance, the most common failure is unnoticed privilege expansion for workloads, service accounts, or automation tokens after deployment. Teams should treat those changes as security-relevant identity events, not mere configuration noise. That is especially important when secrets management is decoupled from IaC and rotated by separate tooling, because the live authority chain can diverge from the approved code path before anyone notices.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Pre-deployment-only scanning misses ongoing configuration management and change control. |
| CIS Controls | 4.1 | Asset and software inventory must reflect deployed reality, not only source code. |
| MITRE ATT&CK | T1078 | Privilege changes after deployment can enable abuse of valid accounts and service identities. |
| NIST AI RMF | GOVERN | If IaC provisions AI services, governance must cover the deployed runtime, not just code. |
Add drift detection and change reconciliation so live infrastructure stays aligned with approved policy.
