Infrastructure as Code Security in DevSecOps

Infrastructure as code security is not a scanner problem. It is a change authority problem.

A few lines of configuration can create an internet path, grant administrator access, replace a key, remove logging, alter a network boundary, or destroy stateful data. A clean scanner result does not prove that the source is trusted, the plan is understood, the state is protected, the deployment identity is narrow, or recovery will work.

Secure the complete change path. Protect the repository and dependencies. Test syntax, behavior, security, policy, cost, and destructive intent. Approve the exact plan for one target. Apply with scoped workload identity and protected state. Verify the result, detect drift, preserve the receipt, and prove recovery for changes that can cause serious harm.

The DevSecOps and Secure Software Delivery hub connects infrastructure changes to source, builds, security gates, secrets, and release evidence. Pair this guide with DevSecOps Secrets Management, the DevSecOps Toolchain Guide, and DevSecOps Security Gates. GS Consulting applies these controls through DevSecOps and Software Supply Chain.

Infrastructure as Code Security: The Short Answer

Keep infrastructure code in protected repositories with review, trusted module and provider sources, version locks, secret scanning, and change ownership. Run validation, unit tests, policy tests, security checks, cost checks, and explicit detection for destructive or privilege changing actions before merge.

Create a fresh plan from the approved source and trusted state. Bind approval to that exact plan, target, deployment identity, policy result, reviewer, conditions, and expiry. Replan when source, dependencies, state, variables, target, or policy changes. Apply through scoped workload identity with state locking and complete logs.

Verify the live result, not just the command exit code. Confirm exposure, identity, encryption, logging, data protection, health, and resource inventory. Detect drift. Test recovery. Preserve a connected evidence packet from requirement through operating result.

Treat IaC as a Privileged Change Lifecycle

Infrastructure as code converts source into operating authority. The controlled object is not only a configuration file. It is the complete combination of source revision, modules, providers, variables, policy, current state, target, deployment identity, plan, approval, apply result, and live environment.

Start with the requirement. Name the owner, intended target, reason, affected services, users, data, trust paths, permissions, network exposure, recovery objective, and evidence duty. This gives reviewers a basis for deciding whether the plan matches the change request.

Separate authoring, review, approval, and apply authority where consequence warrants it. A developer can propose code. Automated checks can evaluate defined policy. A qualified reviewer can assess context. A protected service identity can perform the approved apply. No single laptop needs standing administrator access to every target.

Close the lifecycle after apply. Verify the intended result and important denied conditions. Reconcile partial changes. Update inventory and dependencies. Detect drift. Close exceptions. Keep recovery evidence. A successful command with an unsafe operating state is a failed change.

Public Guidance Supports Lifecycle Assurance

NIST SP 800-204D integrates software supply chain security across build, test, package, and deploy. NIST SP 800-218 supports protected source, review, secure builds, vulnerability response, and retained development evidence. These publications provide a structure, not a required IaC tool or policy language.

The joint NSA and CISA CI/CD guidance describes compromise paths through pipeline configuration, infrastructure code, application source, and dependencies. The DoD Enterprise DevSecOps Fundamentals version 2.5 describes ten lifecycle phases and identifies infrastructure as code as a critical ingredient.

HashiCorp guidance for sensitive Terraform data recommends remote state, encryption, access control, and state access records. Its style guide advises against committing state, saved plans, and sensitive variable files while recommending tests. GitHub deployment environments illustrate approval, branch restriction, protection rules, and controlled environment secret access.

Original Research: Infrastructure Change Assurance

Identity and privileged access change scores 98. State backend protection and locking score 96, tied with secret data in configuration, plan, or state; encryption and key control; and destructive data resource change. Public network exposure scores 95. These domains deserve hard assurance gates because failure can spread quickly or be difficult to reverse.

GS Consulting rated twelve representative change domains from one to five across privilege consequence, exposure change, blast radius, state sensitivity, recovery burden, and evidence duty. Base weights are 25, 20, 20, 15, 10, and 10 percent. The result is normalized to a zero to 100 assurance priority score.

Logging or monitoring disablement scores 91. Privileged container or cluster configuration scores 89. Module and provider source trust score 86, tied with plan approval and controlled apply. Drift and out of band change score 76. Tagging, cost, and metadata policy score 46 in the illustrative case.

A lower score does not make a control optional. Cost tags can be mandatory under local policy, and metadata can affect operations or data handling. The score only reflects the six selected planning factors and example ratings. Authority, contract, mission, data, environment, and incident evidence can change the result.

The alternate case raises privilege consequence to 30 percent and reduces exposure change to 15 percent. Priority lanes remain stable. This is a sensitivity check on arithmetic, not proof that the ratings fit a particular system. Replace the inputs with observed targets, permissions, dependencies, state contents, recovery performance, and evidence duties.

This is a GS Consulting derived planning model based on cited public sources and documented assumptions. It is not an official legal, audit, compliance, NIST, CISA, NSA, DoD, SLSA, OWASP, vendor, authorization, or regulatory determination.

Protect Source, Modules, and Providers

Use approved repositories, protected branches, required review, signed or verified changes where appropriate, and narrow administration. Treat workflow definitions and policy files as privileged source. A change to the pipeline can bypass checks or redirect an apply even when the infrastructure code itself is unchanged.

Record where modules and providers come from, who maintains them, which version is allowed, how integrity is verified, and how updates are reviewed. Lock versions and checksums. Avoid silent use of moving references. Mirror or approve dependencies where availability, sovereignty, or supply chain risk requires it.

Keep values separate from reusable logic. Do not commit state, saved plans, active credentials, or sensitive variable files. Use schema and validation to reject unsafe or incomplete input early. Tests should cover both intended creation and denied conditions such as public exposure, broad identity grants, weak encryption, missing logging, and unapproved regions.

Policy as code works best when each rule names its owner, purpose, scope, severity, exception route, test cases, and evidence output. A rule with no operating owner becomes noise. A rule with no target context can block harmless work and miss material consequence.

Approve the Exact Plan for One Target

The plan is the reviewable expression of intent against current state. Preserve the source revision, dependency locks, input identifiers, state version, target, tool version, and policy results used to create it. Highlight creates, changes, replacements, deletes, privilege grants, public paths, encryption changes, logging changes, and stateful resource impact.

Approval should expire and apply only to that exact plan. If source, variables, dependencies, state, target, or policy changes, create a new plan and decision. Reusable approval turns a meaningful control into a ceremony. Protect plan artifacts because they can reveal sensitive values and infrastructure details.

Use hard stops for broken trust: unapproved source, unknown dependency integrity, invalid plan, wrong target, missing state lock, unauthorized identity, exposed secret, prohibited public path, unresolved critical policy failure, or destructive action without recovery evidence. Use contextual review for findings whose consequence depends on the actual service and environment.

Protect State, Plans, and Secrets

State is a control asset. It binds configuration to resources and can hold identifiers, relationships, outputs, history, and sensitive data. Use remote storage with encryption, narrow access, locking, versioning, backup, access records, and tested recovery. Keep production state separate from lower environments and from ordinary source administration.

Minimize sensitive values in configuration, variables, plans, outputs, and state. A sensitive display flag can reduce ordinary output but does not erase data from storage. Use managed secret services and workload identity where possible. Review provider behavior because some values must enter state to manage a resource.

Plan and state access should be narrower than repository read access. Record every state operation and emergency unlock. Protect backup and recovery copies to the same standard. Test import, restore, and reconciliation on representative resources before assuming a backup is usable.

Control Apply, Verification, Drift, and Recovery

Issue a scoped deployment identity to the protected job only after approval passes. Constrain account, project, subscription, region, resource type, and allowed action where supported. Keep human emergency access separate, time limited, logged, and reviewed. No earlier build or test step needs production administrator authority.

During apply, lock state and retain the identity, target, start and end time, plan identifier, actions, errors, and final status. Handle partial failure deliberately. Determine which resources changed, whether state matches reality, which dependencies are affected, and whether to continue, correct forward, import, or restore.

Post apply verification should test the live environment. Confirm network exposure, identity paths, encryption, logging, monitoring, backups, service health, data protection, and important denied actions. Compare desired code, trusted state, and observed resources. Assign drift to an owner and distinguish approved emergency change from unauthorized or unknown activity.

Rollback is not a universal property of infrastructure. Deletion or data migration may require restore, import, reconciliation, or forward correction. Test the actual recovery route and capture proof before allowing a high consequence change to rely on it.

Six Infrastructure as Code Security Failures

The scanner reads code while the plan and state carry the sensitive values. Approval is reused after the commit or target changes. State is treated as a shared file without strong access, locking, history, and recovery. Policy ignores target context. Apply uses standing administrator access. Rollback is assumed even when destructive changes require restore and reconciliation.

Correct these failures with connected source, dependency, state, plan, identity, approval, apply, drift, and recovery records. Automate checks, but keep named ownership for policy, exceptions, targets, operating verification, and response.

Keep a Minimum Infrastructure Change Packet

Keep the change record, source trust record, test results, exact plan record, approval record, apply receipt, drift evidence, and recovery proof. Link them with one change identifier. Record the owner, source revision, dependencies, state version, target, identity, policy results, exceptions, reviewer, expiry, operating verification, and open actions.

The packet should answer: what was requested, what source and dependencies were trusted, what the plan would do, which policy passed or failed, who approved which target, which identity applied it, what actually changed, whether the live result matched intent, what drift appeared, and whether recovery worked.

A 30, 60, and 90 Day Plan

By day 30, inventory repositories, modules, providers, state stores, deployment identities, targets, policy, emergency paths, and high consequence resources. Protect source and workflow definitions. Stop state, saved plans, and sensitive variable files from entering version control.

By day 60, establish validation, tests, security and policy checks, exact plan approval, protected plan storage, remote state locking, scoped workload identity, apply logging, and post apply verification. Write explicit hard stop and exception rules.

By day 90, test recovery for state loss, partial apply, destructive change, and out of band drift. Review evidence packets for the highest consequence changes. Measure plan changes after approval, standing administrator access, state access, drift age, failed applies, recovery time, exception age, and proof gaps.

Sources and Suggested Future Reading

• NIST SP 800-204D, Software Supply Chain Security in DevSecOps Pipelines
• NIST SP 800-218, Secure Software Development Framework version 1.1
• NSA and CISA, Defending CI/CD Environments
• HashiCorp, Manage Sensitive Data in Terraform Configuration
• HashiCorp Terraform Style Guide
• HashiCorp Terraform State
• GitHub Deployment Environments
• DoD Enterprise DevSecOps Fundamentals version 2.5

Frequently Asked Questions