IaC Security: Securing Your Terraform and OpenTofu Infrastructure

Why IaC security matters

Infrastructure as Code (IaC) runs most modern cloud operations now, and teams reach for Terraform and OpenTofu to define and provision their infrastructure. Because that code defines your infrastructure, securing it matters as much as securing the infrastructure itself. Recent security research found that 63% of cloud security incidents come from misconfigurations rather than sophisticated attacks, so the tools and practices you pick really matter.

This article walks through the threat models, tools, and strategies for securing Terraform and OpenTofu deployments. Whether you run AWS, Azure, Google Cloud, or a mix of all three, it gives you what you need to bake security into your IaC lifecycle.

Section 1: The State of IaC Security

Understanding the Shift-Left Security Model

Modern IaC security runs on the "shift-left" idea: catch problems as early as you can in the development lifecycle instead of finding them in production. That takes a layered approach that handles security at several stages:

Development Time: Developers identify and prevent security issues in their IDEs before code commits.

Pre-Deployment: Automated scanning in CI/CD pipelines catches misconfigurations before infrastructure changes are applied.

Runtime: Continuous monitoring and compliance validation ensure deployed infrastructure remains secure and drift-free.

Operational: Policy enforcement and compliance reporting maintain security standards across environments.

The Static vs. Dynamic Analysis Dichotomy

Two primary methods exist for IaC security analysis:

Static Analysis (SAST) examines your HCL code before deployment:

• Advantages: Early detection, faster fixes, lower remediation costs, covers entire codebase
• Limitations: May produce false positives, lacks runtime context, cannot detect issues from live environment interactions
• Tools: Checkov, tfsec, KICS, Snyk

Dynamic Analysis & Runtime Validation (DAST/CSPM) assesses infrastructure after deployment:

• Advantages: Validates actual security state, detects configuration drift, verifies real-world compliance
• Limitations: Issues found later, remediation more complex, challenges correlating findings to IaC code
• Tools: Cloud Security Posture Management (CSPM) solutions, AWS Security Hub, native cloud provider tools

Best Practice: These methods work together. SAST is your preventative control, while runtime validation keeps things secure over time and catches unauthorized changes.

Section 2: Threat Models for Terraform and OpenTofu

Common Threat Vectors

Understanding the threats your IaC faces is essential for designing effective controls:

Misconfiguration Exposure

• Missing encryption configurations on storage resources
• Overly permissive IAM policies granting excessive access
• Public access enabled on sensitive resources
• Inadequate network segmentation

Secrets Exposure

• Sensitive values (API keys, passwords, tokens) hardcoded in HCL
• Secrets persisted in Terraform state files
• Credentials visible in plan output or CI/CD logs
• Secrets transmitted over unencrypted channels

State File Compromise

• Unauthorized access to state file backends
• State files with plaintext sensitive data stored in Git
• State files lacking encryption at rest or in transit
• Inadequate access controls on state file storage

Supply Chain Attacks

• Malicious modules from untrusted registries
• Compromised providers containing backdoors
• Unsafe plugin execution without verification
• Dependency vulnerabilities in provider code

Access Control Weaknesses

• Insufficient RBAC for IaC operations
• Lack of approval workflows before infrastructure changes
• Missing audit trails for who made what changes
• Excessive permissions for CI/CD service accounts

Drift and Compliance Violations

• Configuration drift from intended IaC definitions
• Unauthorized manual changes to infrastructure
• Inability to detect non-compliant resource configurations
• Missing enforcement of organizational security standards

Section 3: State File Security

The Critical Importance of Terraform State

Terraform state files are the source of truth for your infrastructure. If someone compromises a state file, they've compromised your whole infrastructure, so state security isn't optional.

State File Security Best Practices

1. Enable Encryption at Rest

# Using AWS S3 for state backend with encryption
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

2. Enable Encryption in Transit

# Force HTTPS for all communication
terraform {
  backend "s3" {
    bucket                         = "my-terraform-state"
    key                            = "prod/terraform.tfstate"
    region                         = "us-east-1"
    encrypt                        = true
    dynamodb_table                 = "terraform-locks"
    skip_credentials_validation    = false
    skip_metadata_api_check        = false
    skip_requesting_account_id     = false
  }
}

3. Implement State Locking

# Use DynamoDB for distributed state locking
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

State locking prevents concurrent operations from corrupting state and is essential in team environments.

4. Restrict Access to State Storage

# AWS S3 bucket policy for state file access
resource "aws_s3_bucket_policy" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id
 
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Deny"
        Principal = "*"
        Action = "s3:*"
        Resource = [
          aws_s3_bucket.terraform_state.arn,
          "${aws_s3_bucket.terraform_state.arn}/*"
        ]
        Condition = {
          Bool = {
            "aws:SecureTransport" = "false"
          }
        }
      }
    ]
  })
}

5. Enable Versioning and MFA Delete

# Enable S3 versioning and MFA delete protection
resource "aws_s3_bucket_versioning" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id
 
  versioning_configuration {
    status     = "Enabled"
    mfa_delete = "Enabled"
  }
}

6. Never Store State in Git

Always use remote backends (S3, Azure Storage, Terraform Cloud) rather than committing state files to version control. Add to .gitignore:

terraform.tfstate
terraform.tfstate.*
.terraform/

7. Audit State Access

# Enable CloudTrail logging for state access
resource "aws_s3_bucket_logging" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id
 
  target_bucket = aws_s3_bucket.log_bucket.id
  target_prefix = "terraform-state-logs/"
}

Section 4: Secret Management and Ephemerality in Terraform

The Challenge of Sensitive Data in IaC

Terraform has to deal with sensitive information (database passwords, API keys, OAuth tokens) while it provisions infrastructure. This used to be a real problem: you either stored those values in state files or worked around it in ways that weren't secure.

Ephemeral Values: A Security Breakthrough

Ephemeral resources, introduced in Terraform v1.10 (November 2024), fix this by keeping sensitive information alive only during execution so it's never written to state or plan files.

Core Principles of Ephemerality:

• Temporary existence: Values exist only during current Terraform operation
• Non-persistence guarantee: Never written to state files or plan artifacts
• Security by design: Addresses the longstanding sensitive data management challenge
• Runtime-only visibility: Values accessible only during execution in specific contexts

Ephemeral Blocks: Syntax and Functionality

ephemeral "<resource_type>" "<resource_name>" {
  <attributes>
  <meta-arguments>
}

Ephemeral resources participate in Terraform's dependency graph but with unique lifecycle:

1. Opening: Terraform "opens" the resource by executing its logic to fetch or generate data
2. Renewing: For ephemeral resources that may expire during operation (like temporary tokens), Terraform can periodically renew them
3. Closing: Once no longer needed, Terraform explicitly "closes" the resource, allowing proper cleanup

Write-Only Arguments

Terraform v1.11 introduced write-only arguments that allow ephemeral values to be used in regular resource blocks while maintaining security:

resource "aws_db_instance" "example" {
  instance_class      = "db.t3.micro"
  allocated_storage   = "5"
  engine              = "postgres"
  username            = "example"
  skip_final_snapshot = true
 
  # Write-only password argument (never persisted in state)
  password_wo         = ephemeral.random_password.db_password.result
  password_wo_version = 1
}

Write-only arguments follow a naming convention with the _wo suffix and include a versioning mechanism for controlled updates.

Practical Example: Secure Database Password Management

# Generate ephemeral random password
ephemeral "random_password" "db_password" {
  length            = 16
  override_special  = "!#$%&*()-_=+[]{}<>:?"
}
 
# Store the password in AWS Secrets Manager
resource "aws_secretsmanager_secret" "db_password" {
  name = "db_password"
}
 
# Set the secret value using write-only argument
resource "aws_secretsmanager_secret_version" "db_password" {
  secret_id              = aws_secretsmanager_secret.db_password.id
  secret_string_wo       = ephemeral.random_password.db_password.result
  secret_string_wo_version = 1
}
 
# Retrieve the password from Secrets Manager (ephemeral)
ephemeral "aws_secretsmanager_secret_version" "db_password" {
  secret_id = aws_secretsmanager_secret_version.db_password.secret_id
}
 
# Use the password to configure the database
resource "aws_db_instance" "example" {
  instance_class      = "db.t3.micro"
  allocated_storage   = "5"
  engine              = "postgres"
  username            = "example"
  skip_final_snapshot = true
 
  # Use the ephemeral password (write-only argument)
  password_wo         = ephemeral.aws_secretsmanager_secret_version.db_password.secret_string
  password_wo_version = 1
}

Best Practices for Secret Management

1. Use ephemeral resources for sensitive values that should never be persisted
2. Integrate with secret managers (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault)
3. Enable secret rotation by managing versions of write-only arguments
4. Never hardcode secrets in HCL or environment variables
5. Use temporary credentials wherever possible instead of long-lived static credentials
6. Implement least-privilege access to secrets based on workload requirements

Section 5: Provider Authentication and Dynamic Credentials

Moving Beyond Long-Lived Static Credentials

Security practice is shifting toward short-lived, dynamically generated credentials instead of static API keys and secrets. OpenID Connect (OIDC) lets workload identities grab temporary credentials without you having to manage long-lived secrets.

OIDC for Cloud Provider Authentication

AWS OIDC Integration:

# Configure AWS provider with OIDC
provider "aws" {
  assume_role_with_web_identity {
    role_arn            = aws_iam_role.terraform_role.arn
    web_identity_token  = var.oidc_token
    duration_seconds    = 3600
  }
}
 
resource "aws_iam_role" "terraform_role" {
  name = "terraform-oidc-role"
 
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Federated = "arn:aws:iam::ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
        }
        Action = "sts:AssumeRoleWithWebIdentity"
        Condition = {
          StringEquals = {
            "token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
          }
        }
      }
    ]
  })
}

Azure OIDC Integration:

provider "azurerm" {
  features {}
  use_oidc = true
}

Google Cloud OIDC Integration:

provider "google" {
  project = var.gcp_project
 
  # OIDC configuration handled automatically
  # when running in a workload identity context
}

Scalr and OIDC Integration

Scalr provides built-in support for OIDC-based cloud authentication, eliminating the need to manage long-lived credentials:

# Scalr automatically handles OIDC token exchange
# within its Terraform runs, providing ephemeral
# credentials to cloud providers without requiring
# static API keys or secrets

Provider Configurations in Scalr

Scalr's Provider Configurations feature enables secure centralized management of cloud credentials:

# Provider configuration stored securely in Scalr
# and automatically injected into Terraform runs
resource "scalr_provider_configuration" "aws_prod" {
  account_id    = var.account_id
  name          = "aws-production"
  provider_name = "aws"
 
  # Credentials managed securely by Scalr
  # with OIDC-based authentication
}

Security Benefits of OIDC

• No static credentials stored or transmitted
• Automatic credential rotation with short-lived tokens
• Auditability of which workload obtained credentials and when
• Revocability through identity provider configuration
• Integration with CI/CD pipeline identity management

Section 6: Static Analysis Tools for IaC Security

Checkov: Comprehensive IaC Scanning

Checkov is one of the most widely used static analysis tools for Terraform and OpenTofu, and its graph-based scanning gives you higher accuracy with fewer false positives. For setup walkthroughs, see our guide on using Checkov with Terraform and our broader guide to Terraform vulnerability scanning.

Key Capabilities:

• Scans HCL code, JSON, and Terraform plan files
• Supports Terraform, OpenTofu, CloudFormation, and other IaC frameworks
• Provides 1000+ built-in policies covering security and compliance
• Supports custom policies using Python
• Integrates with CI/CD pipelines, IDEs, and VCS providers
• Detects configuration drift by analyzing terraform plan output

Integration in CI/CD:

# GitHub Actions example
name: IaC Security Scan
on: [pull_request]
 
jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: .
          framework: terraform
          quiet: false
          soft_fail: false
          compact: false

tfsec: Fast Terraform Security Scanning

tfsec is a Terraform-specific scanner written in Go, optimized for speed while maintaining comprehensive coverage.

Key Capabilities:

• Fast scanning of large Terraform codebases
• Cloud-agnostic checks for Terraform security best practices
• Supports custom checks with plugin system
• Minimal false positives through precise rule definitions
• IDE integration for immediate developer feedback

Configuration Example:

# .tfsec/config.json
{
  "checks": {
    "aws-s3-enable-bucket-encryption": "error",
    "aws-s3-block-public-access": "error",
    "aws-iam-require-mfa": "error"
  }
}

KICS: Infrastructure as Code Security

KICS (Keeping Infrastructure as Code Secure) offers support for multiple IaC frameworks and cloud platforms.

Supported Formats:

• Terraform / OpenTofu
• CloudFormation
• Kubernetes
• Docker
• Ansible
• And 20+ additional frameworks

Snyk: Developer-Centric Security

Snyk provides a developer-first approach to IaC security with strong IDE integration and actionable remediation guidance.

Key Features:

• Real-time scanning in development IDEs
• Detailed remediation suggestions with code examples
• Integration with GitHub, GitLab, Azure DevOps
• Support for both code and supply chain vulnerabilities
• Automatic pull request creation for fixes

Making an Informed Choice

When selecting IaC security tools, consider:

1. OpenTofu Support: Tools must understand OpenTofu's independent features including check blocks, client-side state encryption, and .tofu file discovery
2. Accuracy: Graph-based scanning provides higher fidelity than simple HCL parsing
3. Integration: CI/CD and IDE integration enables shift-left security
4. Plan File Scanning: Analyzing terraform/tofu plan JSON output provides higher-fidelity pre-deployment checks
5. Policy Management: Ability to use pre-built and custom policies tailored to organizational needs
6. Performance: Scanning speed matters for large codebases and frequent CI/CD runs

Section 7: DevSecOps Practices for IaC

The DevSecOps Paradigm

DevSecOps integrates security throughout the software development lifecycle. Key principles include:

Shift Left (and Everywhere): Address security concerns as early as possible, and keep checking throughout the lifecycle rather than only at the deployment gate.

End-to-End Automation: Automate security checks, tests, policy enforcement, and remediation so they keep pace with how fast teams ship.

Continuous Security Testing: Run multiple testing techniques continuously, including SAST, DAST, SCA, and infrastructure scanning.

Collaborative Culture: Break down silos between development, security, and operations teams.

Security as Code: Define security policies and controls as code so they stay consistent and auditable.

IaC in the DevSecOps Toolchain

Infrastructure as Code sits at the center of DevSecOps. It's the foundation your applications and security controls run on.

SAST for Application Code scans application source code for vulnerabilities.

SCA (Software Composition Analysis) identifies vulnerabilities and license issues in open-source dependencies.

IaC Security Scanning identifies misconfigurations in Terraform, CloudFormation, and other infrastructure definitions, a layer often overlooked.

DAST tests running applications for vulnerabilities.

CSPM (Cloud Security Posture Management) continuously monitors deployed resources for drift and non-compliance.

Complete DevSecOps Tool Strategy

A complete DevSecOps strategy uses tooling across multiple categories:

Section 8: AWS Security Best Practices with Terraform

The AWS Shared Responsibility Model

AWS secures the infrastructure (physical security, hypervisor, host OS, network infrastructure), while customers are responsible for securing what they deploy (service configuration, customer data, identity & access management, network controls, operating system, application security).

Critical AWS Security Risks

Misconfiguration remains the most common vulnerability, accounting for 63% of AWS security incidents.

IAM Issues represent the second most critical risk area, contributing to 47% of successful breaches. See our practical guide on streamlining AWS IAM role creation with Terraform for least-privilege patterns.

Data Exfiltration from improperly configured S3 buckets remains a persistent threat.

Supply Chain Attacks through compromised CI/CD pipelines increased 73% year-over-year.

AWS Security Best Practices in Terraform

1. Identity and Access Management

# Implement least-privilege IAM policies
resource "aws_iam_policy" "limited_s3_access" {
  name = "s3-read-only"
 
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "s3:GetObject",
          "s3:ListBucket"
        ]
        Resource = [
          aws_s3_bucket.app_data.arn,
          "${aws_s3_bucket.app_data.arn}/*"
        ]
      }
    ]
  })
}
 
# Use temporary credentials instead of long-term access keys
resource "aws_iam_role" "app_role" {
  name               = "app-execution-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Service = "ec2.amazonaws.com"
        }
        Action = "sts:AssumeRole"
      }
    ]
  })
}

2. Data Protection

# Encrypt S3 buckets with KMS
resource "aws_kms_key" "s3_encryption_key" {
  description             = "KMS key for S3 bucket encryption"
  deletion_window_in_days = 10
  enable_key_rotation     = true
}
 
resource "aws_s3_bucket_server_side_encryption_configuration" "secure_bucket" {
  bucket = aws_s3_bucket.app_data.id
 
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.s3_encryption_key.arn
    }
  }
}
 
# Block public access
resource "aws_s3_bucket_public_access_block" "app_data" {
  bucket = aws_s3_bucket.app_data.id
 
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

3. Network Security

# Implement VPC Flow Logs
resource "aws_flow_log" "main" {
  log_destination      = aws_s3_bucket.flow_logs.arn
  log_destination_type = "s3"
  traffic_type         = "ALL"
  vpc_id               = aws_vpc.main.id
  log_format           = "${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol}"
}
 
# Create security groups with minimal access
resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow TLS inbound traffic"
  vpc_id      = aws_vpc.main.id
 
  ingress {
    description = "TLS from anywhere"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
 
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}
 
# Use VPC endpoints for service connections
resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.us-east-1.s3"
  vpc_endpoint_type = "Gateway"
}

4. Continuous Monitoring and Response

# Configure CloudTrail for audit logging
resource "aws_cloudtrail" "main" {
  name                          = "main-trail"
  s3_bucket_name                = aws_s3_bucket.cloudtrail_logs.id
  include_global_service_events = true
  is_multi_region_trail         = true
  enable_log_file_validation    = true
  kms_key_id                    = aws_kms_key.cloudtrail.arn
 
  event_selector {
    read_write_type           = "All"
    include_management_events = true
 
    data_resource {
      type   = "AWS::S3::Object"
      values = ["arn:aws:s3:::"]
    }
  }
}
 
# Enable GuardDuty for threat detection
resource "aws_guardduty_detector" "main" {
  enable            = true
  finding_publishing_frequency = "FIFTEEN_MINUTES"
}

Section 9: Security in CI/CD Pipelines

Integrating IaC Security Scanning

Modern CI/CD pipelines should include automated security scanning at multiple stages:

Pre-Commit Hooks: Prevent secrets and misconfigurations from entering the repository.

Build Stage: Run comprehensive static analysis on all IaC code.

Plan Stage: Analyze terraform/tofu plan output for security issues.

Policy Evaluation: Enforce organizational security policies before deployment.

Post-Deployment Validation: Verify deployed resources match intended configuration.

Example CI/CD Pipeline with Security

# GitHub Actions workflow
name: Terraform Security Pipeline
 
on:
  pull_request:
    paths:
      - 'terraform/**'
  push:
    branches:
      - main
 
jobs:
  terraform_validation:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
 
      - name: Terraform Format Check
        run: terraform fmt -check -recursive terraform/
 
      - name: Terraform Validate
        run: terraform -chdir=terraform/prod validate
 
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: terraform/
          framework: terraform
          quiet: false
 
      - name: Run tfsec
        uses: aquasecurity/[email protected]
        with:
          working_directory: terraform/
 
      - name: Terraform Plan
        run: terraform -chdir=terraform/prod plan -json -out=tfplan.json
 
      - name: Analyze Plan with Snyk
        run: |
          npm install -g snyk
          snyk iac test tfplan.json --json-file-output=snyk-results.json
 
      - name: Upload SARIF Results
        uses: github/codeql-action/upload-sarif@v2
        if: always()
        with:
          sarif_file: snyk-results.sarif
 
  terraform_apply:
    needs: terraform_validation
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
 
      - name: Terraform Apply
        run: |
          cd terraform/prod
          terraform init
          terraform apply tfplan.json

Section 10: Scalr Security Features for Infrastructure Management

Scalr as an IaC Governance Platform

Scalr adds enterprise governance to Terraform and OpenTofu so you can run secure, compliant infrastructure operations at scale. For audit and compliance evidence, see Terraform audit logs; for runtime scanning integrations, see automating Terraform security in Scalr deployments with Regula and using Scalr hooks with Bridgecrew Yor.

Identity and Access Management

SAML 2.0 & SCIM Integration:

# Scalr integrates with corporate identity providers
# for unified authentication and provisioning

OIDC for API Access:

# Authenticate programmatically with OIDC tokens
# instead of static API keys

Policy Enforcement

Open Policy Agent (OPA) Integration:

# Scalr enforces OPA policies before infrastructure changes
package terraform.policies
 
deny[reason] {
    resource := input.resource_changes[_]
    resource.type == "aws_s3_bucket"
    not resource.change.after.server_side_encryption_configuration
 
    reason := sprintf("S3 bucket '%s' must have encryption enabled", [resource.name])
}

Checkov Integration:

# Scalr integrates Checkov via a pre-plan custom hook,
# so configurations are scanned before plans are applied

Credential Management

Provider Configurations:

Scalr centrally manages and securely stores credentials for cloud providers and other services, then automatically injects them into Terraform runs.

OIDC for Dynamic Cloud Credentials:

# Scalr supports OIDC for obtaining temporary
# credentials from AWS, Azure, and GCP
# eliminating long-lived static credentials

Infrastructure and Data Security

VCS Agents for Internal Repositories:

If you run a self-hosted version control system, Scalr's VCS Agents set up secure connections without exposing your internal repositories to the public internet.

Self-Hosted Agents:

# Run Terraform/OpenTofu operations within
# your own network infrastructure for complete control

State Encryption:

• Scalr-managed state files are encrypted at rest
• Customer-managed backends use provider-native encryption
• Sensitive variables are encrypted and never exposed

Comprehensive Reporting

OPA Policy Violation Reporting:

Tracks which workspaces violate policies and provides remediation guidance.

Resource and Configuration Tracking:

Aggregates all resources across state files for visibility and audit purposes.

Drift Detection Reports:

Identifies discrepancies between intended and actual infrastructure configuration.

Version Management Reports:

Tracks Terraform/OpenTofu, module, and provider versions to identify outdated components with known vulnerabilities.

These fleet-wide reports read a single object model across every workspace in your estate. A platform team can scan every workspace in one view for a vulnerable provider version, an unencrypted resource, or unresolved drift, instead of checking each workspace by hand. Scalr is a drop-in alternative to Terraform Cloud, so a team running HCP Terraform today can move to this kind of fleet-wide reporting without re-tooling.

Stale Workspace Reports:

Identifies workspaces with active resources that haven't been recently updated, which may not reflect current security policies.

API Token Management:

Tracks token rotation and usage patterns to enforce security best practices.

Audit Logs:

Comprehensive activity logs with first-party integrations to both AWS EventBridge and Datadog. Audit logs and run events stream directly to Datadog for centralized security analysis, while EventBridge remains available for AWS-native event routing.

Section 11: Best Practices for IaC Security in 2026

1. Implement Zero Trust Architecture

Treat all networks as potentially hostile and enforce strict least-privilege principles:

• Require strong authentication for all API access
• Use temporary credentials instead of long-lived secrets
• Implement MFA for sensitive operations
• Audit all access and changes

2. Automate Security Assessment

Manual security reviews no longer suffice for infrastructure operating at cloud scale:

• Integrate static analysis into every CI/CD pipeline
• Use plan file analysis for pre-deployment validation
• Implement continuous post-deployment scanning
• Establish automated remediation workflows for policy violations

3. Adopt Permissions-on-Demand

Static permissions are inherently risky:

• Implement just-in-time (JIT) access for sensitive operations
• Use temporary credentials with short lifespans
• Use ephemeral resources for secrets and provider authentication
• Require explicit approval for privileged operations

4. Shift Left on Security

Catch issues as early as possible:

• Implement pre-commit hooks to prevent secrets and misconfigurations
• Use IDE integrations for real-time security feedback
• Enforce scanning in CI/CD before any deployment
• Give developers security tools that integrate into their workflows

5. Embrace Immutable Infrastructure

Rather than patching and modifying:

• Rebuild infrastructure from secure templates
• Use infrastructure as code to define everything
• Treat infrastructure as replaceable rather than precious
• Practice frequent, repeatable deployments

6. Manage Secrets Securely

Never trust hardcoded values:

• Use ephemeral resources for secrets that should not be persisted
• Integrate with external secret managers
• Implement secret rotation policies
• Enable MFA delete on secret storage
• Use OIDC for workload identity instead of static credentials

7. Enforce Policy as Code

Define and enforce security standards programmatically with policy as code:

• Use OPA/Rego for custom security policies
• Define compliance requirements as code
• Make policies understandable and actionable for developers
• Implement dry-run modes to prevent surprise policy violations

8. Maintain Comprehensive Audit Trails

Security requires accountability:

• Enable CloudTrail, VPC Flow Logs, and application logging
• Integrate logs into SIEM for analysis
• Maintain audit trails of all infrastructure changes
• Track who made what changes and when

9. Manage Configuration Drift

Prevent unauthorized or unintended changes:

• Enable drift detection in Scalr or equivalent platforms
• Establish remediation workflows for detected drift
• Prevent manual changes to infrastructure
• Regularly verify deployed configuration matches intent

10. Build a Security Culture

Tooling alone is insufficient:

• Foster shared responsibility between development and security teams
• Provide security training for infrastructure engineers
• Reward and recognize security-conscious practices
• Make security part of the developer experience, not an obstacle

Where to start

No single control secures Infrastructure as Code on its own. You need layered controls, the right tools, and consistent practices. New threats keep showing up, and Terraform and OpenTofu keep shipping answers to old problems like ephemeral resource handling and dynamic credentials.

Success in 2026 requires:

• Comprehensive approach: Combine static analysis, runtime validation, and policy enforcement
• Automation: Integrate security into every stage of the development and deployment lifecycle
• Culture: Foster security awareness and shared responsibility across teams
• Platform: Use governance platforms like Scalr for consistent policy enforcement at scale

Start by wiring static analysis into every pull request, then add runtime policy-as-code, drift detection, and audit logging so violations cannot reach production even if they pass review. Each layer you add closes off a class of misconfiguration that scanning alone would miss.