A Terraform stack inventory is a structured view of where infrastructure code lives and how it is organised across repositories and directories. It helps teams distinguish managed infrastructure from potential unmanaged code, so policy enforcement, drift detection, and remediation can be applied consistently across the full codebase.
Expanded Definition
Terraform Stack Inventory is the operational map of Terraform code ownership, location, and structure across repositories and directories. In NHI and infrastructure governance, it is not just a code index. It is the control plane for knowing which stacks are intended, which are active, and which may be unmanaged or forgotten.
Definitions vary across vendors on how much metadata belongs in a stack inventory, but the practical minimum is consistent: repository path, stack purpose, owning team, environment, state location, and policy scope. That inventory becomes the basis for drift detection, secret exposure review, access scoping, and remediation routing. It also helps separate declarative infrastructure that is under management from ad hoc code that can silently bypass controls. For governance alignment, stack inventory supports control mapping and change accountability in ways that mirror expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.
NHIMG’s research shows that only 5.7% of organisations have full visibility into their service accounts, and the same visibility gap often appears in infrastructure code ownership. The most common misapplication is treating a repository list as a complete inventory, which occurs when teams ignore nested directories, generated stacks, and inactive code paths.
Examples and Use Cases
Implementing Terraform stack inventory rigorously often introduces process overhead, requiring organisations to weigh stronger governance against the cost of keeping metadata continuously current.
- A platform team maps each Terraform root module to an owner, environment, and policy set so security reviews can target the right stack instead of the whole monorepo.
- A cloud security team uses the inventory to find stacks that reference long-lived secrets in code, then prioritises remediation where exposure risk is highest, consistent with guidance in the Ultimate Guide to NHIs.
- An enterprise standardises stack metadata so drift detection can compare intended state against deployed state and route findings to the correct engineering group.
- A compliance team cross-checks inventory records against access controls and code review rules to verify that only approved repositories can change production stacks, aligning with NIST SP 800-53 Rev 5 Security and Privacy Controls.
- An incident response team uses the inventory to identify which stacks may have been touched by a compromised pipeline, shortening the path from alert to containment.
Why It Matters in NHI Security
Terraform stack inventory matters because infrastructure code frequently contains or references NHI-adjacent material such as provider credentials, CI/CD tokens, cloud roles, and policy exceptions. If the inventory is incomplete, organisations may assume a stack is governed when it is actually orphaned, duplicated, or deployed outside the expected lifecycle. That gap undermines policy enforcement, rotation planning, and access review.
This is especially important given NHIMG’s finding that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, and 79% have experienced secrets leaks with tangible damage. A complete stack inventory helps reveal where those exposures can arise, who is responsible for them, and whether remediation can be applied consistently across repositories. It also supports the zero-trust expectation that every change path and every workload identity should be observable and attributable, as discussed in the Ultimate Guide to NHIs.
Organisations typically encounter the operational cost of poor stack inventory only after a drift event, a leaked credential, or an unauthorized deployment, at which point the term becomes operationally unavoidable to address.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Stack inventory helps identify unmanaged NHI-related code paths and ownership gaps. |
| NIST CSF 2.0 | ID.AM-02 | Asset management covers knowing where infrastructure code exists and how it is organised. |
| NIST Zero Trust (SP 800-207) | Zero trust requires visibility into managed resources and their change pathways. | |
| NIST SP 800-63 | Identity assurance depends on knowing which non-human entities can act through code and pipelines. | |
| OWASP Agentic AI Top 10 | Agentic workflows often deploy infrastructure through code paths that must be inventoried. |
Track Terraform stacks as governed assets and refresh the inventory whenever repositories or paths change.
Related resources from NHI Mgmt Group
- How should DevOps teams inventory Terraform modules across large codebases to support upgrades and audits?
- Who is accountable for producing Terraform module inventory evidence during compliance audits or security questionnaires?
- What breaks when Terraform module and provider usage is not visible at the stack level?
- What is the difference between stack-level visibility and code-level review for Terraform governance?
