Static checks alone can miss risk because they evaluate individual configuration lines, not the eventual deployment state created when templates are executed. In CloudFormation, intrinsic functions can resolve values only at runtime and change how resources are actually deployed. If scanners stop at string matches, they may overlook dependency issues, environment-driven behaviour, and security outcomes that appear only after deployment.
Where Static Checks Stop Short
Static scanning is strongest when the risk is visible in the template text itself, but infrastructure as code often encodes behaviour indirectly. A template can look benign while still producing a materially different runtime outcome once parameters, mappings, conditions, and intrinsic functions are resolved. That means the scanner may approve the file while the deployed resources inherit a very different trust boundary, exposure level, or dependency chain.
The practical issue is that the template is only the source artifact. The real security question is what infrastructure the template will create, not what the lines appear to say in isolation. When a tool evaluates only the literal text, it can miss environment-specific resolution, conditional resource creation, and cases where a harmless-looking reference becomes a sensitive deployment path after values are substituted.
- Template text can be static while the effective configuration is dynamic.
- Security posture may depend on runtime inputs that the scanner does not simulate.
- Dependency and ordering problems often appear only in the deployed graph, not in the file syntax.
Why Runtime Resolution Changes the Risk Picture
CloudFormation intrinsic functions are a good example of why execution-time logic matters. They can derive names, select resources, branch on conditions, and pull values from other parts of the stack. A control that looks safe at parse time may become unsafe after resolution if the chosen parameter, environment, or dependency exposes broader access than intended. That is why static vs dynamic secrets is a useful mental model here: the danger is not the syntax alone, but the effective state after deployment.
This is also where misconfigurations become harder to catch. A template may create a resource with inherited permissions, public reachability, or cross-stack references that are invisible until the stack is assembled. If the scan engine cannot resolve those relationships, it cannot reliably judge blast radius, privilege, or downstream access paths. That limitation matters in the same way as other configuration-driven exposure problems described in NHIMG’s Guide to the Secret Sprawl Challenge and Microsoft SAS Key Breach: the artifact may be small, but the resulting access can be large.
Runtime-aware review is especially important when templates influence identity-bearing material, such as access keys, tokens, or other secret values that end up attached to deployed resources. In those cases, static-only review can miss the point where an apparently routine deployment decision becomes a privilege or exposure decision.
What Practitioners Should Validate Instead
Security teams should treat static checks as a first filter, not the final verdict. The deeper validation step is to inspect the resolved deployment state, the effective permissions, and the resource relationships that will exist after parameter substitution and condition evaluation. Where the template language supports it, test the rendered result and compare it to the intended design, not just to policy rules applied to the source file.
What to verify: whether the scanner can evaluate parameters, conditions, and intrinsic functions well enough to approximate the deployed result, and whether a second control exists for post-resolution inspection or change review.
Decision rule: if a template can alter network exposure, access scope, or resource relationships at deployment time, do not rely on a source-only pass for approval. Add a runtime or rendered-template control before you accept the risk.
Practitioner takeaway: the safest review model is source check plus deployment-state check, because the security outcome is determined by what the template becomes, not by what the text appears to describe.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 4 — Secure Configuration of Enterprise Assets and Software | IaC template review is a secure configuration problem because the deployed state must match intended hardened settings. |
| CIS Control 5 — Account Management | Templates often create identities, keys, and permissions that need controlled lifecycle handling. | |
| CIS Control 16 — Application Software Security | Infrastructure as code templates are software artifacts whose logic can hide security-impacting behavior until execution. | |
| Recommendation — Validate rendered infrastructure against secure configuration baselines before deployment. Review template-driven account and permission creation for least privilege and approved ownership. Test infrastructure code with runtime-aware checks in the same security pipeline as other software artifacts. | ||
| NIST CSF 2.0 | PR.IP-1 — Baseline Configuration | The question centers on whether the deployed baseline differs from the static template text. |
| PR.AC-4 — Access Permissions and Authorizations Are Managed | Runtime-resolved resources can change access scope, so permissions must be checked in the deployed state. | |
| DE.CM-3 — Personnel, Devices, Software and Systems Are Monitored | Post-deployment monitoring helps detect when resolved resources diverge from expected security outcomes. | |
| Recommendation — Compare the rendered deployment state to the approved baseline before release. Verify effective permissions after template resolution, not only in source. Monitor deployed infrastructure for drift from the intended template outcome. | ||
Related resources from NHI Mgmt Group
- Why do AI coding agents create more risk than static code scanners alone can handle?
- What breaks when organisations rely on static checks alone for AI generated code
- Why do surface scans and static inventories miss the most important internet exposure risk in modern environments?
- Why do static checks alone miss some mobile app security issues?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
