Jason Miller / Securing Terraform DevSecOps Workflows

The Definitive Guide to DevSecOps for Terraform: Building Secure, Scalable IaC Workflows

Master DevSecOps for Terraform. This guide provides a blueprint for building secure, scalable IaC pipelines. Integrate automated security checks, manage secrets with Vault, and enforce policy as code to ship infrastructure confidently and at speed

Chapter 1: The Paradigm Shift: Infrastructure as Code and Its Inherent Risks

1.1 Framing the Modern Challenge: Velocity and the New Attack Surface

The adoption of Infrastructure as Code (IaC) has fundamentally reshaped how organizations manage their IT environments. Tools like HashiCorp Terraform allow teams to define, provision, and manage infrastructure using human-readable configuration files, aligning infrastructure operations with modern software development practices.1 This codified approach delivers unprecedented gains in efficiency, consistency, and scalability, enabling businesses to deploy complex cloud architectures with speed and reliability.3 By treating infrastructure components—virtual machines, networks, databases, and more—as code, organizations can version, test, and automate their deployment in a repeatable and predictable manner.2

However, this paradigm shift, while powerful, introduces a new and significant attack surface.6 The very attributes that make IaC compelling—automation and reusability—also create a powerful amplification effect for security vulnerabilities. A single, subtle misconfiguration within a Terraform module, if left unchecked, can be replicated hundreds or even thousands of times across development, staging, and production environments.7 This transforms a minor error into a systemic, foundational weakness embedded in the very fabric of the cloud architecture.6

The core security challenge of managing Terraform at scale is not the tool itself, but its capacity to multiply the impact of human error. In a world of manual operations, a misconfigured server is a singular incident requiring targeted remediation. In the world of IaC, a misconfigured Terraform resource is a version-controlled, automated, and reusable template for generating insecure infrastructure. This template can be shared across teams and projects, propagating the vulnerability exponentially and creating a widespread security debt that is difficult to detect and expensive to remediate post-deployment. The problem, therefore, is not merely about fixing a single insecure resource in the cloud; it is about preventing the insecure pattern from ever being codified, versioned, and deployed. This reality necessitates a fundamental change in security strategy, shifting the focus from auditing live environments to securing the source code and the automated pipelines that deploy it.

1.2 A Taxonomy of Terraform Security Risks

The security risks associated with Terraform are multifaceted and interconnected. Understanding this taxonomy is the first step toward building a robust defense. These risks are not theoretical; they represent common failure modes observed in organizations that have adopted IaC without a corresponding evolution in their security practices.

• Misconfigurations: The Silent Threat
  This is the most prevalent and insidious category of risk in IaC.8 Misconfigurations are often unintentional errors in the code that result in security vulnerabilities. Common examples include publicly exposed storage buckets, overly permissive Identity and Access Management (IAM) roles, security groups with unrestricted inbound ports (e.g., SSH access from
  0.0.0.0/0), unencrypted data volumes, and the use of default credentials for databases or services.6 Because IaC automates provisioning based on the code, these errors are deployed faithfully and systematically, creating predictable weaknesses for attackers to exploit.9
• Secrets Sprawl: The Danger of Hardcoded Credentials
  A critical and alarmingly common anti-pattern is the hardcoding of sensitive data—such as API keys, database passwords, private certificates, and access tokens—directly within Terraform configuration files (.tf) or variable files (.tfvars).6 When these files are committed to a version control system (VCS) like Git, the secrets are exposed to anyone with read access to the repository.11 Even in private repositories, this practice constitutes a significant risk, as it widens the circle of exposure and makes secret rotation and auditing nearly impossible. This “secrets sprawl” is a direct path to catastrophic data breaches and infrastructure compromise.3
• State File Exposure: The High-Value Target
  The Terraform state file (terraform.tfstate) acts as a source of truth, maintaining a detailed mapping between the configuration and the real-world resources it manages.1 This file can contain a wealth of sensitive information, including resource IDs, IP addresses, and sometimes even plaintext credentials generated by a resource.6 If the state file is stored insecurely—for example, on a local developer machine or in an unencrypted, publicly accessible remote backend like an S3 bucket—it provides a comprehensive roadmap of the infrastructure for an attacker.7 A compromised state file can reveal misconfigurations and provide the necessary information to access or exfiltrate data.7
• Supply Chain Vulnerabilities: The Risk of Untrusted Modules
  Terraform’s modularity is a key feature for promoting reusability, but it also introduces supply chain risks.8 Organizations frequently leverage third-party modules from public sources like the Terraform Registry or GitHub to accelerate development.9 However, these external modules can contain insecure configurations, hidden backdoors, or malicious code.6 Without a thorough vetting process, teams may inadvertently import vulnerabilities into their environment.9 Furthermore, failing to pin provider and module versions can lead to unexpected and potentially malicious updates being pulled into a build, compromising the integrity of the infrastructure.9
• Identity and Access Management (IAM) Risks
  By its nature, Terraform requires permissions to create, modify, and delete cloud resources. Often, the service principal, user account, or CI/CD runner executing terraform apply is granted highly elevated privileges.6 If this execution environment is compromised, an attacker can leverage these permissions to escalate their privileges and gain administrative control over the entire cloud account.9 This makes the CI/CD system a high-value target and underscores the importance of applying the principle of least privilege to the credentials used by Terraform.10
• Infrastructure Drift: The Unseen Danger
  Infrastructure drift occurs when the actual state of resources in the cloud diverges from the state defined in the Terraform code.6 This can happen due to manual changes made outside of the Terraform workflow, suboptimal configurations, or unintended application changes.3 Drift creates a dangerous blind spot, as the code in the repository no longer represents the true security posture of the environment, potentially leaving security gaps that are invisible to automated scanners that only analyze the source code.6

These risks do not exist in isolation; they often form a causal chain that an attacker can exploit. For instance, a hardcoded secret discovered in a public repository (Secrets Sprawl) could grant an attacker access to an insecurely stored state file (State File Exposure). This state file could, in turn, reveal a misconfigured security group (Misconfiguration) that allows access to a host running a vulnerable service provisioned by an untrusted third-party module (Supply Chain Vulnerability). A comprehensive DevSecOps strategy must therefore address each link in this chain, creating a defense-in-depth model for IaC security.

Chapter 2: The DevSecOps Mandate: Principles for Secure IaC

2.1 Moving Beyond Manual Audits: “Shifting Security Left” for Infrastructure

The traditional approach to security, often characterized by manual audits and security reviews conducted late in the development cycle, is fundamentally incompatible with the speed and scale of DevOps and IaC. When security is treated as an afterthought or a final gate before production, it inevitably becomes a bottleneck, forcing a trade-off between speed and safety.12 DevSecOps resolves this conflict by integrating security practices directly into the DevOps methodology, making security a continuous and shared responsibility rather than a final, isolated phase.4

The core tenet of this integration is “shifting security left”.13 This principle advocates for moving security checks and vulnerability assessments as early as possible into the development lifecycle.12 For Infrastructure as Code, this represents a profound strategic change. The primary point of security intervention moves away from the live, deployed cloud environment and shifts to the developer’s local machine and the Continuous Integration/Continuous Delivery (CI/CD) pipeline.13 Instead of security teams acting as auditors who discover misconfigurations in production, they become enablers who equip developers with the automated tools and guardrails needed to write secure infrastructure code from the very beginning.12

Consider the contrast between the two models. In a traditional workflow, a security team might scan a production AWS environment and discover a database exposed to the public internet. They would then file a high-priority ticket, forcing the engineering team to halt their current work, diagnose the issue, trace it back to the source Terraform code, develop a fix, and push it through the entire testing and deployment process. This reactive, fire-fighting approach is disruptive, costly, and inefficient.

In a “shift-left” model, the same vulnerability is caught at multiple, much earlier stages. An IDE extension might flag the insecure resource as the developer is writing the code. If that is missed, a pre-commit hook could prevent the insecure code from ever being committed. Failing that, an automated scanner in the CI pipeline would immediately fail the build upon a pull request, providing the developer with instant, actionable feedback.15 The vulnerability is remediated in minutes, at near-zero cost, and never even approaches a staging environment, let alone production.12 The security team’s effort is invested in building and maintaining these automated guardrails, a scalable activity, rather than in manual, repetitive, and unscalable incident response. This proactive posture is the essence of securing modern, IaC-driven workflows.

2.2 Core Principles of Infrastructure Security as Code

The “shift-left” philosophy is powered by a set of foundational principles that collectively can be termed “Infrastructure Security as Code.” This approach extends the “as Code” paradigm to security and compliance, treating them as software engineering disciplines that can be versioned, tested, and automated.

• Codification: From Documents to Executable Rules
  The first principle is the codification of all security and compliance requirements.12 Instead of policies living in static documents or wikis, they are defined in machine-readable formats.4 Security configurations, access controls, encryption standards, and compliance checks are all written as code.12 This ensures that security standards are explicit, unambiguous, and consistently understood by both humans and machines, eliminating the variability and errors inherent in manual interpretation and implementation.12
• Automation: From Manual Gates to Integrated Guardrails
  Once policies are codified, they can be enforced through automation.12 Automated tools are integrated directly into the CI/CD pipeline to validate infrastructure code against these policies at every stage.8 This transforms security from a manual review process—a classic bottleneck—into a continuous, automated function that scales with the development process.15 Automation ensures that every code change is consistently and reliably checked, providing a scalable mechanism for governance.14
• Continuous Monitoring and Feedback: Creating a Learning Loop
  DevSecOps acknowledges that security is not a one-time event but an ongoing process.13 This principle emphasizes the need for continuous monitoring and the creation of tight feedback loops.12 In an IaC context, this includes not only pre-deployment scanning of code but also post-deployment monitoring for configuration drift and emerging threats.12 When a vulnerability is detected, whether in code or in production, the feedback must be delivered to the developer quickly and clearly, enabling rapid remediation and learning.
• Collaboration: Security as a Shared Responsibility
  Perhaps the most critical principle is the cultural shift toward collaboration and shared ownership of security.4 DevSecOps breaks down the traditional silos between development, operations, and security teams.12 Security is no longer the sole domain of a separate team; it becomes a collective responsibility. Security experts provide the platforms, tools, and guidance, while developers take ownership of the security of the infrastructure they define in their code. This collaborative model fosters a culture where security is built-in by design, not bolted on as an afterthought.

The unifying theme across these principles is the power of treating everything “as Code.” When infrastructure definitions, security policies, and compliance rules are all managed as version-controlled software artifacts, the full suite of mature software engineering practices can be applied. A security policy that begins as a sentence in a compliance document—“All S3 buckets must have server-side encryption enabled”—is translated into a checkov or Sentinel policy file. This file is stored in Git (Codification), automatically executed by the CI pipeline on every pull request (Automation), and provides immediate pass/fail results to the developer (Feedback Loop). This end-to-end process makes security scalable, auditable, and an integral part of development velocity.

Chapter 3: The Secure Terraform Pipeline: A Step-by-Step Implementation Guide

Building a secure Terraform workflow requires a multi-layered approach, with different security controls applied at various stages of the CI/CD pipeline. Each stage serves a specific purpose, from catching syntax errors to enforcing complex business logic. This chapter provides a detailed, step-by-step guide to implementing these controls, complete with tool recommendations and practical examples.

A mature DevSecOps pipeline for Terraform can be visualized as a series of quality and security gates. The following table provides a high-level blueprint of this workflow, outlining the goal of each stage and the key tools involved. This structure acts as a roadmap, illustrating how security is progressively layered into the process, shifting from the developer’s local environment all the way to pre-deployment enforcement.

Table: The Secure Terraform Pipeline: Stages and Controls

3.1 Stage 1: Static Analysis (SAST for IaC)

Static Application Security Testing (SAST) for Infrastructure as Code is the cornerstone of a secure Terraform pipeline. This practice involves automatically scanning Terraform configuration files (.tf) and, more powerfully, Terraform plan files (.json) to identify security misconfigurations, compliance violations, and deviations from best practices before any infrastructure is ever deployed.16 By automating vulnerability discovery at this early stage, organizations can catch and remediate a vast class of potential issues with minimal friction.16 Two of the most prominent open-source tools in this space are

checkov and tfsec.

Tool Deep Dive: checkov

Developed by Bridgecrew (now part of Prisma Cloud by Palo Alto Networks), checkov is a comprehensive static analysis tool that supports a wide array of IaC frameworks, including Terraform, CloudFormation, Kubernetes, ARM Templates, and more.18 Its key features make it a versatile choice for organizations with diverse technology stacks.

• Features: checkov comes with over 750 built-in policies that cover industry standards like CIS Benchmarks, PCI, and HIPAA.19 It allows for the creation of custom policies using either Python or a simple YAML syntax.19 A particularly powerful feature is its ability to scan the JSON representation of a Terraform plan, which provides more context about variable values and module outputs, leading to more accurate analysis than scanning
  .tf files alone.22
  checkov can also be used to scan for hardcoded secrets within configuration files.24
• Usage and Integration:

  • Basic Scan: To scan all Terraform files in the current directory, the command is checkov -d..25

  • Plan Scanning: A more robust approach involves generating a plan file, converting it to JSON, and scanning the result. This captures the final, interpolated values that will be used for deployment.22
    Bash
    # Generate a binary plan file
    terraform plan -out=tfplan.binary

    # Convert the binary plan to JSON
    terraform show -json tfplan.binary > tfplan.json

    # Scan the JSON plan file
    checkov -f tfplan.json

  • CI/CD Integration: checkov can output results in various formats, including JUnit XML (-o junitxml), which can be easily consumed by CI/CD systems like Jenkins or GitLab CI to display test results and fail pipelines based on scan findings.24

• Custom Policies: Organizations can extend checkov’s built-in rule set with custom policies to enforce their own specific standards. For example, a simple YAML policy to ensure all S3 buckets have a cost-center tag would look like this, based on the structure outlined in the documentation 24:
  YAML
  metadata:
  id: “CUSTOM_AWS_001”
  name: “Ensure S3 buckets have a cost-center tag”
  category: “convention”
  severity: “LOW”
  definition:
  and:
  - resource_types:
  - “aws_s3_bucket”
  - attribute: “tags.cost-center”
  operator: “exists”

Tool Deep Dive: tfsec

tfsec, now part of the Aqua Security Trivy scanner, is a static analysis tool designed with a laser focus on Terraform.17 Its developer-first approach prioritizes speed, accuracy, and deep integration with Terraform’s language specifics.

• Features: tfsec performs a deep analysis of Terraform code by integrating directly with the official HCL parser, allowing it to understand complex expressions, functions (concat(), etc.), and relationships between resources.28 It can scan local and remote modules and supports custom checks written in JSON, YAML, or the more powerful Rego policy language.17 It is known for being extremely fast, making it ideal for local developer workflows and rapid CI feedback.28
• Usage and Integration:

  • Basic Scan: To scan the current directory, the command is simply tfsec..30

  • Excluding Directories: It is a best practice to exclude the .terraform directory, which contains cached provider plugins and modules, to avoid irrelevant warnings. This can be done with the --exclude-path flag or a .tfsecignore file.17
    Bash
    tfsec. --exclude-path.terraform

  • Output Formats: Like checkov, tfsec supports multiple output formats, including json and junit, for easy integration with CI/CD systems and custom reporting scripts.28

IaC Static Analysis Tool Comparison: checkov vs. tfsec

Choosing the right static analysis tool depends on an organization’s specific needs, technology stack, and security philosophy. The following table compares checkov and tfsec across several key dimensions, drawing from documentation and community feedback.32

The decision between these tools often reflects a strategic choice. An organization seeking a “single pane of glass” to scan a heterogeneous collection of IaC technologies might lean towards checkov for its breadth. Conversely, a team that is heavily invested in Terraform and prioritizes the deepest possible analysis of HCL might prefer the focused power of tfsec/Trivy. Many mature organizations ultimately use multiple scanners, leveraging the unique strengths of each to create a more robust, defense-in-depth scanning strategy.

3.2 Stage 2: Secrets Management

One of the most critical security failures in IaC is the mishandling of secrets. The cardinal rule of secrets management is to never store sensitive information in plaintext within version control.10 This includes API keys, passwords, certificates, and any other credentials. Integrating a dedicated secrets management solution is not just a best practice; it is an essential control for any production-grade Terraform workflow.

While using environment variables in a CI/CD system is a step up from hardcoding secrets in .tf files, it is not a complete solution. These variables can still be exposed in build logs or accessed by other processes running on the same build agent, posing a significant risk.11 The “golden path” for secrets management involves fetching secrets dynamically and just-in-time from a secure, centralized vault, ensuring that long-lived credentials never reside in the CI environment or the source code.39 HashiCorp Vault is the industry-standard tool for implementing this pattern with Terraform.

Integrating HashiCorp Vault with Terraform

The integration between Terraform and Vault provides a robust framework for managing secrets securely throughout the infrastructure lifecycle. The most secure pattern goes beyond simply storing static secrets in Vault; it involves using Vault’s secrets engines to generate dynamic, short-lived credentials on-demand for each Terraform run.40 These credentials are created just-in-time, are tightly scoped with the minimum necessary permissions, and expire automatically after a short Time-To-Live (TTL), drastically reducing the attack surface.40

This approach fundamentally solves the “secret zero” problem—the challenge of how to securely provide the CI/CD pipeline with its initial credential to authenticate to the secrets manager. By using modern authentication methods like OpenID Connect (OIDC), the pipeline can prove its identity to Vault without needing a pre-configured, long-lived token. Vault, trusting the pipeline’s identity, then generates ephemeral credentials for the target cloud provider, breaking the chain of static secrets entirely.

Practical Tutorial: Using the Vault Provider for Dynamic Secrets

This tutorial outlines the steps to configure Terraform to fetch dynamic AWS credentials from Vault.

Step 1: Configure HashiCorp Vault
First, the appropriate secrets engine must be enabled and configured within Vault.

1. Enable the AWS Secrets Engine: This engine is responsible for generating dynamic AWS IAM credentials.
   Bash
   # Enable the AWS secrets engine at the path ‘aws’
   vault secrets enable aws

2. Configure Vault’s AWS Credentials: Vault needs its own set of long-lived, highly-privileged AWS credentials to be able to create other, temporary credentials. This is a one-time setup.
   Bash
   # Configure the AWS secrets engine with Vault’s own IAM credentials
   vault write aws/config/root \
   access_key=“YOUR_VAULT_AWS_ACCESS_KEY” \
   secret_key=“YOUR_VAULT_AWS_SECRET_KEY” \
   region=“us-east-1”

3. Create a Vault Role: A role in Vault defines the permissions and TTL for the dynamic credentials that will be generated for Terraform. This is where the principle of least privilege is enforced.
   Bash
   # Create a role named ’terraform-role’ that grants specific IAM permissions
   # and sets a TTL of 15 minutes for the generated credentials.
   vault write aws/roles/terraform-role \
   credential_type=“iam_user” \
   policy_document=@/path/to/iam-policy.json \
   ttl=“15m”

   The iam-policy.json file would contain a standard AWS IAM policy document granting only the permissions Terraform needs for a specific workspace.

Step 2: Configure the Terraform Providers
In the Terraform configuration, the vault provider is configured to handle authentication, and the aws provider is left without explicit credentials, as they will be injected dynamically.

Terraform

# main.tf

# Configure the Vault provider
provider “vault” {
# The address of the Vault server is typically set via the
# VAULT_ADDR environment variable in the CI/CD pipeline.

# Authentication will be handled via environment variables
# configured for OIDC or AppRole in the CI/CD pipeline.
}

# Configure the AWS provider
# NO credentials are specified here. The Vault provider will
# dynamically source them and configure the AWS provider.
provider “aws” {
region = “us-east-1”
}

# Example data source to fetch a dynamic AWS credential
data “vault_aws_access_credentials” “creds” {
backend = “aws”
role = “terraform-role”
}

# The aws_instance resource will now be provisioned using the
# dynamic, short-lived credentials generated by Vault.
resource “aws_instance” “example” {
ami = “ami-0c55b159cbfafe1f0”
instance_type = “t2.micro”

# The access key from the dynamic credential can be used if needed,
# but the provider is already configured automatically.
tags = {
Name = “Provisioned-with-Vault-${data.vault_aws_access_credentials.creds.access_key_id}”
}
}

Step 3: Authenticate the CI/CD Pipeline to Vault
The final step is to configure the CI/CD pipeline to securely authenticate to Vault. As recommended by HashiCorp, OIDC is the preferred method for cloud-native environments like GitLab CI, GitHub Actions, and Terraform Cloud.40

1. Configure Trust in Vault: The Vault administrator configures a JWT/OIDC authentication backend, establishing a trust relationship with the CI/CD platform’s OIDC issuer. This configuration maps attributes from the CI job’s JWT (like repository name or branch) to specific Vault policies and roles.
2. Configure the Pipeline: The CI/CD pipeline is configured to request an OIDC token for each job. The Terraform Vault provider is then configured via environment variables (e.g., VAULT_AUTH_JWT_TOKEN, VAULT_AUTH_JWT_ROLE) to use this token for authentication.

This dynamic secrets pattern represents the most mature and secure approach to managing credentials in an automated IaC workflow. It eliminates static secrets from the CI/CD environment, enforces the principle of least privilege at scale, and provides a clear audit trail for every credential generated.

3.3 Stage 3: Policy as Code (PaC)

While static analysis tools are excellent at finding known bad patterns and common misconfigurations, Policy as Code (PaC) provides a more powerful and flexible layer of governance. PaC allows organizations to define and enforce custom, logic-based rules that codify organizational policies related to security, compliance, and cost management.43 These policies act as preventative guardrails, ensuring that infrastructure deployments adhere to business-specific constraints.

For users of Terraform Enterprise or Terraform Cloud, the integrated PaC framework is HashiCorp Sentinel. Sentinel executes between the terraform plan and terraform apply stages, analyzing the proposed plan and blocking any changes that violate policy.45 This provides a powerful, preventative control that stops non-compliant infrastructure from ever being provisioned.5

Introducing HashiCorp Sentinel

Sentinel’s strength lies in its ability to make policy decisions based on rich contextual data. It can import and analyze information from the Terraform configuration (tfconfig), the current state (tfstate), and, most importantly, the generated plan (tfplan).44 This allows for the creation of sophisticated policies that go beyond simple static checks. For example, a Sentinel policy can check not just that a resource is configured correctly, but that the

change being proposed is acceptable (e.g., preventing the deletion of a critical production database).

Writing Sentinel Policies

Sentinel policies are written in their own purpose-built language, which is designed to be accessible yet powerful. Policies are structured around rules, with the main rule determining the final pass/fail outcome.48

Example 1: Enforcing Tagging Standards
This policy ensures that all provisioned AWS resources have an owner tag, which is a common requirement for cost allocation and accountability.49

Code snippet

# restrict-tags.sentinel
import “tfplan/v2” as tfplan

# Find all resources that are being created or updated
all_resources = filter tfplan.resource_changes as _, rc {
rc.change.actions contains “create” or rc.change.actions contains “update”
}

# Rule: ensure all resources have an ‘owner’ tag
main = rule {
all all_resources as _, r {
r.change.after.tags.owner is not null
}
}

Example 2: Restricting EC2 Instance Types
To control costs, an organization might want to restrict developers to using only a specific list of approved EC2 instance types in non-production environments.47

Code snippet

# restrict-instance-types.sentinel
import “tfplan/v2” as tfplan

# List of allowed instance types
allowed_types = [“t2.micro”, “t2.small”, “t3.micro”, “t3.small”]

# Find all EC2 instances being created or updated
ec2_instances = filter tfplan.resource_changes as _, rc {
rc.type is “aws_instance” and
(rc.change.actions contains “create” or rc.change.actions contains “update”)
}

# Rule: ensure instance types are in the allowed list
main = rule {
all ec2_instances as _, instance {
instance.change.after.instance_type in allowed_types
}
}

Example 3: Enforcing S3 Bucket Encryption
This security policy ensures that any new S3 bucket must have server-side encryption enabled.49

Code snippet

# enforce-s3-encryption.sentinel
import “tfplan/v2” as tfplan

# Find all S3 buckets being created
s3_buckets = filter tfplan.resource_changes as _, rc {
rc.type is “aws_s3_bucket” and rc.change.actions contains “create”
}

# Rule: ensure server_side_encryption_configuration is defined
main = rule {
all s3_buckets as _, bucket {
bucket.change.after.server_side_encryption_configuration is not null
}
}

Enforcement Modes: The Key to Adoption

A critical feature of Sentinel that facilitates its adoption in large organizations is the concept of enforcement modes.46 These modes allow teams to phase in new policies gradually, minimizing disruption and developer friction.

• advisory: The policy runs and reports violations, but it will not block the terraform apply.51 This is the default mode and is perfect for introducing new policies. It allows teams to assess the impact of a policy and identify non-compliant code without breaking existing workflows.
• soft-mandatory: The policy will block a run if it fails, but users with specific permissions (e.g., organization owners) can override the failure and allow the apply to proceed.45 This is useful for policies that should generally be followed but may have legitimate exceptions that require an audited approval.
• hard-mandatory: The policy must pass for the run to proceed. There are no overrides.46 This mode is reserved for the most critical security and compliance controls that must never be violated.

This tiered approach is fundamental to the successful implementation of Policy as Code at scale. It provides a pragmatic pathway for rollout: a new policy can be introduced in advisory mode to gather data and socialize the requirement. Once developers have had time to remediate their code, the policy can be escalated to soft-mandatory to handle audited exceptions, and finally to hard-mandatory once it is fully embedded in the organization’s standards. This prevents PaC from being perceived as an obstacle and instead positions it as a collaborative tool for improving governance.

Chapter 4: Assembling the Workflow: Complete CI/CD Pipeline Examples

Theory and individual tools are essential, but the real value of DevSecOps is realized when these components are assembled into a coherent, automated workflow. This chapter provides complete, end-to-end CI/CD pipeline configurations for three of the most popular platforms: Jenkins, GitLab CI, and Azure DevOps. These examples are not trivial; they synthesize the principles from the previous chapter into mature, multi-stage pipelines that incorporate validation, static analysis, secrets management with Vault, and policy enforcement, providing a practical blueprint for implementation.

4.1 A Secure Terraform Pipeline with Jenkins

Jenkins, with its vast ecosystem of plugins and flexible Pipeline-as-Code syntax (Jenkinsfile), remains a powerful platform for orchestrating complex workflows. A secure Terraform pipeline in Jenkins leverages the Jenkinsfile for defining stages, the Credentials plugin for securely managing secrets like a Vault token, and the JUnit plugin for visualizing results from security scanners.

Detailed Jenkinsfile Example

The following Jenkinsfile outlines a robust, multi-stage pipeline. It assumes Jenkins has the necessary plugins installed (Pipeline, Docker, AWS Credentials, Vault Plugin, JUnit) and is configured with credentials for AWS and Vault.

Groovy

// Jenkinsfile for a Secure Terraform Workflow

pipeline {
agent {
// Use a Docker container with necessary tools pre-installed
docker {
image ‘your-custom-image:latest’ // Should contain Terraform, tfsec, checkov
args ‘-v /var/run/docker.sock:/var/run/docker.sock’
}
}

environment {  
    // Securely inject Vault address and authentication details  
    // 'vault-approle-creds' should be a Jenkins 'Username/Password' credential  
    // storing the AppRole RoleID (username) and SecretID (password).  
    VAULT\_ADDR \= 'https://vault.example.com:8200'  
    VAULT\_CREDS \= credentials('vault-approle-creds')  
    VAULT\_APPROLE\_ROLE\_ID \= VAULT\_CREDS\_USR  
    VAULT\_APPROLE\_SECRET\_ID \= VAULT\_CREDS\_PSW  
}

stages {  
    stage('1. Checkout') {  
        steps {  
            echo 'Checking out source code...'  
            checkout scm  
        }  
    }

    stage('2. Lint & Validate') {  
        steps {  
            echo 'Formatting and validating Terraform code...'  
            sh 'terraform fmt \--check \--recursive'  
            sh 'terraform init \-backend=false'  
            sh 'terraform validate'  
        }  
    }

    stage('3. Security Scans') {  
        steps {  
            script {  
                // Run security scans in parallel  
                parallel(  
                    tfsec: {  
                        echo 'Running tfsec scan...'  
                        // Run tfsec and allow it to fail the build, but catch the error to publish results  
                        try {  
                            sh 'tfsec. \--format junit \--out tfsec-report.xml'  
                        } catch (Exception e) {  
                            echo "tfsec scan failed: ${e.message}"  
                            currentBuild.result \= 'FAILURE'  
                        } finally {  
                            junit 'tfsec-report.xml'  
                        }  
                    },  
                    checkov: {  
                        echo 'Running checkov scan...'  
                        // Run checkov and allow it to fail the build, but catch the error to publish results  
                        try {  
                            sh 'checkov \-d. \-o junitxml \> checkov-report.xml'  
                        } catch (Exception e) {  
                            echo "checkov scan failed: ${e.message}"  
                            currentBuild.result \= 'FAILURE'  
                        } finally {  
                            junit 'checkov-report.xml'  
                        }  
                    }  
                )  
                // Explicitly fail the stage if any scan failed  
                if (currentBuild.result \== 'FAILURE') {  
                    error "Security scans failed. Check the test results for details."  
                }  
            }  
        }  
    }

    stage('4. Terraform Plan') {  
        steps {  
            echo 'Initializing Terraform and generating plan...'  
            // The Vault provider will automatically use the VAULT\_\* environment variables  
            // to authenticate and configure the AWS provider with dynamic credentials.  
            sh 'terraform init'  
            sh 'terraform plan \-out=tfplan'  
        }  
    }

    stage('5. Manual Approval') {  
        steps {  
            // Pause for manual review of the Terraform plan  
            input message: 'Review the Terraform plan. Approve to apply.', ok: 'Apply Plan'  
        }  
    }

    stage('6. Terraform Apply') {  
        steps {  
            echo 'Applying Terraform plan...'  
            sh 'terraform apply \-auto-approve tfplan'  
        }  
    }  
}

post {  
    always {  
        // Clean up workspace after the build  
        echo 'Cleaning up workspace...'  
        cleanWs()  
    }  
}  

}

This pipeline demonstrates a clear separation of concerns. It validates code quality first, then runs security scans in parallel for efficiency, publishes the results for visibility, and only proceeds to the plan and apply stages if all checks pass. The use of a try/catch/finally block is a key pattern for ensuring that test reports are published even when the scan itself causes the build to fail, providing developers with the necessary feedback to remediate issues.52

4.2 A Secure Terraform Pipeline with GitLab CI

GitLab CI excels at integrating security directly into the developer workflow. Its native support for OIDC allows for seamless and secure authentication to HashiCorp Vault, and its ability to parse and display SAST reports in the merge request UI provides immediate, contextual feedback.

Detailed.gitlab-ci.yml Example

This .gitlab-ci.yml file defines a pipeline that leverages GitLab’s advanced features for a secure Terraform workflow. It uses separate jobs for each task, OIDC for Vault authentication, and SAST artifact reporting.

YAML

#.gitlab-ci.yml for a Secure Terraform Workflow

stages:
- validate
- test
- plan
- apply

# Template for Terraform jobs to reduce duplication
.terraform_template:
image:
name: hashicorp/terraform:latest
entrypoint: [""]
before_script:
- export VAULT_ADDR=“https://vault.example.com”
- terraform --version
- terraform init

# -– Validation Stage -–
validate:
extends:.terraform_template
stage: validate
script:
- terraform validate

# -– Test Stage -–
tfsec-sast:
stage: test
image: aquasec/tfsec-ci:latest
script:
# Output in GitLab SAST format
- tfsec. --format=sast > gl-sast-report.json
artifacts:
reports:
sast: gl-sast-report.json
allow_failure: false # Fail the pipeline if tfsec finds issues

checkov:
stage: test
image: bridgecrew/checkov:latest
script:
# Output in JUnit format for test reporting
- checkov -d. --output junitxml > checkov-report.xml
artifacts:
reports:
junit: checkov-report.xml
allow_failure: false

# -– Plan Stage -–
plan:
extends:.terraform_template
stage: plan
script:
# Authenticate to Vault using GitLab’s OIDC token
- export VAULT_AUTH_METHOD=jwt
- export VAULT_JWT_ROLE=“terraform-ci” # Vault role configured for GitLab OIDC
- export VAULT_JWT_TOKEN=${CI_JOB_JWT_V2}

\# The Vault provider will authenticate using the JWT.  
\# The AWS provider will be configured with dynamic credentials.  
\- terraform plan \-out=tfplan  

artifacts:
paths:
- tfplan
# Run only on merge requests and the main branch
rules:
- if: $CI_PIPELINE_SOURCE == ‘merge_request_event’
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

# -– Apply Stage -–
apply:
extends:.terraform_template
stage: apply
script:
# Authenticate to Vault using GitLab’s OIDC token
- export VAULT_AUTH_METHOD=jwt
- export VAULT_JWT_ROLE=“terraform-ci”
- export VAULT_JWT_TOKEN=${CI_JOB_JWT_V2}

\- terraform apply \-auto-approve tfplan  

dependencies:
- plan
when: manual # Requires manual approval to run
# Run only on the main branch
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

This GitLab configuration demonstrates a sophisticated workflow. The tfsec-sast job is particularly noteworthy; by generating a gl-sast-report.json artifact, it allows GitLab to ingest the findings and display them directly within the merge request interface, providing developers with a seamless feedback experience.54 The use of

id_tokens (via the CI_JOB_JWT_V2 variable) for OIDC authentication with Vault is a best practice that eliminates the need to store any static Vault credentials in GitLab CI/CD variables.55

4.3 A Secure Terraform Pipeline with Azure DevOps

Azure DevOps provides a robust platform for CI/CD with its YAML pipelines, Service Connections for secure cloud authentication, and Variable Groups for managing secrets. A key decision when building a Terraform pipeline in Azure DevOps is whether to use the pre-built marketplace tasks or to rely on command-line script tasks for greater control.56 For a mature DevSecOps workflow that integrates external tools like Vault, script tasks often provide the necessary flexibility.

Detailed azure-pipelines.yml Example

This example uses a multi-stage YAML pipeline. It leverages a Variable Group to store the Vault AppRole credentials and uses script tasks to orchestrate the security scans and Terraform commands.

YAML

# azure-pipelines.yml for a Secure Terraform Workflow

trigger:
- main

pool:
vmImage: ‘ubuntu-latest’

variables:
# Link to a Variable Group containing VAULT_ADDR, VAULT_APPROLE_ROLE_ID, etc.
# These secrets should be marked as ‘secret’ in the Variable Group UI.
- group: Terraform-Vault-Credentials

stages:
- stage: Validate_and_Scan
displayName: ‘Validate & Scan Code’
jobs:
- job: SecurityChecks
steps:
- task: TerraformInstaller@0
displayName: ‘Install Terraform’
inputs:
terraformVersion: ’latest’

\- script: |  
    terraform init \-backend=false  
    terraform validate  
  displayName: 'Terraform Init & Validate'

\- script: |  
    \# Install security tools  
    pip install checkov  
    \# Assuming tfsec is installed via another method or available in the agent image  
  displayName: 'Install Security Scanners'

\- script: |  
    tfsec. \--format junit \--out $(Build.ArtifactStagingDirectory)/tfsec-report.xml  
  displayName: 'Run tfsec Scan'  
  continueOnError: true \# Continue even if scan fails to publish results

\- script: |  
    checkov \-d. \--output junitxml \> $(Build.ArtifactStagingDirectory)/checkov-report.xml  
  displayName: 'Run checkov Scan'  
  continueOnError: true

\- task: PublishTestResults@2  
  displayName: 'Publish Security Scan Results'  
  inputs:  
    testResultsFormat: 'JUnit'  
    testResultsFiles: '$(Build.ArtifactStagingDirectory)/\*.xml'  
    failTaskOnFailedTests: true \# Fail the pipeline if tests (scans) fail

- stage: Plan
displayName: ‘Terraform Plan’
dependsOn: Validate_and_Scan
condition: succeeded()
jobs:
- job: TerraformPlan
steps:
- task: TerraformInstaller@0
displayName: ‘Install Terraform’
inputs:
terraformVersion: ’latest’

\- script: |  
    \# The Vault provider uses environment variables mapped from the Variable Group  
    export VAULT\_APPROLE\_ROLE\_ID=$(VAULT\_APPROLE\_ROLE\_ID)  
    export VAULT\_APPROLE\_SECRET\_ID=$(VAULT\_APPROLE\_SECRET\_ID)  
      
    terraform init  
    terraform plan \-out=tfplan  
  displayName: 'Terraform Init & Plan'  
    
\- task: PublishPipelineArtifact@1  
  displayName: 'Publish Plan Artifact'  
  inputs:  
    targetPath: 'tfplan'  
    artifact: 'terraform-plan'

- stage: Deploy
displayName: ‘Terraform Apply’
dependsOn: Plan
jobs:
- deployment: TerraformApply
environment: ‘production’ # Defines an environment with an approval gate
strategy:
runOnce:
deploy:
steps:
- task: TerraformInstaller@0
displayName: ‘Install Terraform’
inputs:
terraformVersion: ’latest’

      \- task: DownloadPipelineArtifact@2  
        displayName: 'Download Plan Artifact'  
        inputs:  
          artifact: 'terraform-plan'  
          path: '$(Pipeline.Workspace)/terraform-plan'

      \- script: |  
          export VAULT\_APPROLE\_ROLE\_ID=$(VAULT\_APPROLE\_ROLE\_ID)  
          export VAULT\_APPROLE\_SECRET\_ID=$(VAULT\_APPROLE\_SECRET\_ID)  
            
          terraform init  
          terraform apply \-auto-approve "$(Pipeline.Workspace)/terraform-plan/tfplan"  
        displayName: 'Terraform Apply'

This pipeline demonstrates several Azure DevOps best practices. Using a separate Validate_and_Scan stage creates a clear quality gate that must pass before any infrastructure planning occurs.5 The use of an

environment in the Deploy stage is the standard Azure DevOps mechanism for implementing manual approval checks.57 While the Microsoft-provided Terraform tasks can simplify basic pipelines, this example shows how

script tasks provide the fine-grained control needed to orchestrate the authentication sequence for Vault correctly, a crucial pattern for advanced DevSecOps integration.

Chapter 5: Conclusion: The Business and Security Impact

Adopting a DevSecOps methodology for Terraform is more than a technical exercise; it is a strategic imperative that delivers tangible business and security outcomes. By embedding automated security controls directly into the infrastructure development lifecycle, organizations can move beyond the false dichotomy of speed versus safety. This approach enables teams to innovate rapidly while systematically reducing risk, automating compliance, and enhancing their overall security posture.

5.1 Quantifying the Benefits: Beyond “Better Security”

The value of implementing a secure Terraform workflow extends far beyond a simple reduction in vulnerabilities. The benefits are measurable and have a direct impact on an organization’s bottom line and operational efficiency.

• Drastically Reduced Risk and Faster Remediation: The most immediate benefit is the early detection and remediation of security issues. By “shifting left,” vulnerabilities are identified at the code level, where the cost and effort of fixing them are orders of magnitude lower than in production.13 This proactive stance prevents costly security breaches, data exposure, and the associated reputational damage and regulatory fines.20
• Automated and Continuous Compliance: A DevSecOps pipeline transforms compliance from a periodic, manual audit into a continuous, automated process. Policies for industry standards like the CIS Benchmarks, HIPAA, or PCI-DSS can be codified using tools like checkov or Sentinel and enforced on every single code change.21 This provides real-time compliance validation, simplifies audit preparations, and ensures that the infrastructure remains in a compliant state by default.20
• Sustained Development Velocity: A common misconception is that adding security slows down development. In reality, a well-designed DevSecOps pipeline does the opposite. By automating security checks, it removes the manual review cycles and security gates that have traditionally been major bottlenecks in the release process.4 Developers receive fast, automated feedback, allowing them to fix issues independently and maintain momentum. Security becomes a self-service function and an accelerator for delivery, not a brake.15

Perhaps the most significant, quantifiable benefit is the reduction of unplanned work. Security incidents, compliance failures, and production outages caused by misconfigurations force engineering teams to drop their planned feature development and engage in reactive fire-fighting. This unplanned work is a major drain on productivity and innovation. The automated, preventative controls in a DevSecOps pipeline—from static analysis to policy as code—are designed to eliminate the root causes of these incidents. By preventing entire classes of errors, the pipeline frees up countless engineering hours that would otherwise be spent on remediation and crisis management. This reclaimed time can be directly reinvested into building value-adding products and services, providing a clear and compelling return on investment for the DevSecOps initiative.58

5.2 The Future of IaC Security

The field of Infrastructure as Code security is continuously evolving. As organizations mature their practices, several emerging trends are shaping the future of how we secure automated infrastructure.

• AI-Powered Security: Artificial intelligence and machine learning are beginning to play a larger role in IaC security. This includes intelligent threat detection that can identify anomalous patterns in infrastructure configurations, AI-driven tools that can suggest or even automatically generate remediations for detected vulnerabilities, and platforms that use AI to help developers build secure infrastructure from scratch.4
• The Rise of Zero Trust Principles: The principles of Zero Trust—never trust, always verify; enforce least privilege access—are being increasingly applied to IaC workflows. This means moving away from broad, static permissions and toward just-in-time, dynamically generated credentials for every action, as exemplified by the Vault dynamic secrets pattern. Pipelines will increasingly be designed to ensure that all provisioned infrastructure adheres to strict least-privilege and secure authentication protocols by default.4
• Holistic Supply Chain Security: The focus is expanding beyond just the Terraform code itself to encompass the entire software supply chain. This includes securing developer accounts to prevent code tampering, hardening the CI/CD runners that execute Terraform, vetting all third-party modules and providers, and ensuring the integrity of every artifact in the build process.3

Ultimately, securing Terraform with DevSecOps is a journey of continuous improvement, not a one-time project. It requires a foundational commitment to an “as Code” philosophy, a culture of shared responsibility for security, and a willingness to adapt as new threats and technologies emerge. By embracing these principles and implementing the robust, automated workflows detailed in this guide, organizations can confidently scale their use of Infrastructure as Code, unlocking its full potential for business agility without compromising on security or compliance.

Works cited

1. What is Infrastructure as Code with Terraform? - HashiCorp Developer, accessed July 27, 2025, https://developer.hashicorp.com/terraform/tutorials/aws-get-started/infrastructure-as-code
2. Terraform Infrastructure as Code (IaC) Guide With Examples - Spacelift, accessed July 27, 2025, https://spacelift.io/blog/terraform-infrastructure-as-code
3. Infrastructure as Code Security (IaC) - Risk, Challenges & Best Practices - SignMyCode, accessed July 27, 2025, https://signmycode.com/blog/what-is-infrastructure-as-code-security-iac-risk-challenges-best-practices
4. DevSecOps and Infrastructure as Code: A Security Nexus - CIO Influence, accessed July 27, 2025, https://cioinfluence.com/it-and-devops/devsecops-and-infrastructure-as-code-a-security-nexus/
5. DevSecOps Approach with Terraform and CI/CD Pipelines | by Bijit Ghosh - Medium, accessed July 27, 2025, https://medium.com/@bijit211987/devsecops-approach-with-terraform-and-ci-cd-pipelines-f556c2d5b40d
6. 6 Essential Terraform Security Best Practices - Wiz, accessed July 27, 2025, https://www.wiz.io/academy/terraform-security-best-practices
7. Infrastructure as Code (IaC): Common Security Risks, accessed July 27, 2025, https://orca.security/resources/blog/infrastructure-as-code-common-risks/
8. Complete Guide On Mastering Terraform Security - Zeet.co, accessed July 27, 2025, https://zeet.co/blog/terraform-security
9. 12 Terraform Security Best Practices (& 7 Common Risks) - Spacelift, accessed July 27, 2025, https://spacelift.io/blog/terraform-security
10. Terraform Best Practices: Building Secure Infrastructure as Code | by Kesavan Mariappan, accessed July 27, 2025, https://medium.com/@mkesavan170/terraform-best-practices-building-secure-infrastructure-as-code-da68720ad76c
11. Terraform Secrets - How to Manage Them (Tutorial) - Spacelift, accessed July 27, 2025, https://spacelift.io/blog/terraform-secrets
12. DevSecOps Principles: Tutorial and Best Practices - Drata, accessed July 27, 2025, https://drata.com/grc-central/compliance-as-code/devsecops-principles
13. DevSecOps: Principles, Tools, and Best Practices [2025 Guide] - Pynt, accessed July 27, 2025, https://www.pynt.io/learning-hub/devsecops/devsecops-principles-tools-and-best-practices-2025-guide
14. What is DevSecOps? - Principles, Goals, Benefits, Challenges - OpsMx, accessed July 27, 2025, https://www.opsmx.com/blog/what-is-devsecops/
15. Understanding DevSecOps Principles - DEV Community, accessed July 27, 2025, https://dev.to/574n13y/understanding-devsecops-principles-18fp
16. Terraform Security Best Practices - Sysdig, accessed July 27, 2025, https://sysdig.com/blog/terraform-security-best-practices/
17. Terraform Tutorials: TFSec for Security Scanning - DevOpsSchool.com, accessed July 27, 2025, https://www.devopsschool.com/blog/terraform-tutorials-tfsec-for-security-scanning/
18. Comprehensive Guide to Using Checkov for Infrastructure as Code (IaC) Scanning | by Anshumaan Singh | Medium, accessed July 27, 2025, https://medium.com/@anshumaansingh10jan/comprehensive-guide-to-using-checkov-for-infrastructure-as-code-iac-scanning-bb6a93471c6a
19. What is Checkov: Benefits, Key Features, and Examples - Env0, accessed July 27, 2025, https://www.env0.com/blog/best-iac-scan-tool-what-is-checkov
20. A Guide to Securing Your Terraform Code with Checkov - Halodoc Blog, accessed July 27, 2025, https://blogs.halodoc.io/securing-your-terraform-code-with-checkov-a-guide/
21. What is Checkov? Features, Use Cases & Examples - Spacelift, accessed July 27, 2025, https://spacelift.io/blog/what-is-checkov
22. Terraform Plan Scanning - checkov, accessed July 27, 2025, https://www.checkov.io/7.Scan%20Examples/Terraform%20Plan%20Scanning.html
23. Scanning Terraform Code with Checkov: Comprehensive Guide - DevOpsCube, accessed July 27, 2025, https://devopscube.com/terraform-checkov-scan/
24. Using Checkov with Terraform - Integrations, Features, Examples - Scalr, accessed July 27, 2025, https://scalr.com/blog/using-checkov-with-terraform-integrations-features-examples
25. Quick Start - checkov, accessed July 27, 2025, https://www.checkov.io/1.Welcome/Quick%20Start.html
26. Feature Descriptions - checkov, accessed July 27, 2025, https://www.checkov.io/1.Welcome/Feature%20Descriptions.html
27. Terraform - IaC Scanning with TFSEC for VsCode (Extension) - DEV Community, accessed July 27, 2025, https://dev.to/pwd9000/iac-scanning-with-tfsec-for-vscode-extension-27h8
28. aquasecurity/tfsec: Tfsec is now part of Trivy - GitHub, accessed July 27, 2025, https://github.com/aquasecurity/tfsec
29. What is tfsec: Benefits, Key Features, and Examples - Env0, accessed July 27, 2025, https://www.env0.com/blog/best-iac-scan-tool-what-is-tfsec
30. What is tfsec? How to Install, Config, Ignore Checks - Spacelift, accessed July 27, 2025, https://spacelift.io/blog/what-is-tfsec
31. Fantastic Infrastructure as Code security attacks and how to find them - GitLab, accessed July 27, 2025, https://about.gitlab.com/blog/fantastic-infrastructure-as-code-security-attacks-and-how-to-find-them/
32. Checkov vs. Tfsec vs. Terrascan - VegaStack, accessed July 27, 2025, https://vegastack.com/tutorials/checkov-vs-tfsec-vs-terrascan/
33. Checkov vs Tfsec vs Trivy vs Terrascan? : r/Terraform - Reddit, accessed July 27, 2025, https://www.reddit.com/r/Terraform/comments/1kv7n3y/checkov_vs_tfsec_vs_trivy_vs_terrascan/
34. tfsec vs chekhov vs terrascan - What do pople recommend? : r/Terraform - Reddit, accessed July 27, 2025, https://www.reddit.com/r/Terraform/comments/mzzz5h/tfsec_vs_chekhov_vs_terrascan_what_do_pople/
35. Securing Your Infrastructure-as-Code: An Overview of Terraform validate, TFLint, TFSec, Checkov and OPA | by Alexander Klein | Medium, accessed July 27, 2025, https://medium.com/@kleinalexander/securing-your-infrastructure-as-code-an-overview-of-terraform-validate-tflint-tfsec-checkov-and-5d8ef405b283
36. tfsec - Aqua Security, accessed July 27, 2025, https://aquasecurity.github.io/tfsec/v1.28.13/
37. Secret Handling in Terraform - Auth0 Community, accessed July 27, 2025, https://community.auth0.com/t/secret-handling-in-terraform/127016
38. Risks of Exposed Terraform Secrets and 4 Ways to Secure Them | Codefresh, accessed July 27, 2025, https://codefresh.io/learn/devsecops/risks-of-exposed-terraform-secrets-and-4-ways-to-secure-them/
39. Terraform Secrets Management: Build Golden Paths for Security - Akeyless, accessed July 27, 2025, https://www.akeyless.io/blog/terraform-secrets-management-build-golden-paths-for-security/
40. Integrate Terraform with Vault - HashiCorp Developer, accessed July 27, 2025, https://developer.hashicorp.com/validated-patterns/terraform/terraform-integrate-vault
41. Azure Dynamic Secrets with Terraform & Vault | by Alim Azad - DevOps.dev, accessed July 27, 2025, https://blog.devops.dev/azure-dynamic-secrets-with-terraform-vault-4089b01837be
42. Use Vault-backed dynamic credentials in HCP Terraform - HashiCorp Developer, accessed July 27, 2025, https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/vault-backed
43. 6 ways Terraform can help secure your infrastructure - HashiCorp, accessed July 27, 2025, https://www.hashicorp.com/blog/6-ways-terraform-can-help-secure-your-infrastructure
44. Scale Your AWS Environment Securely with HashiCorp Terraform and Sentinel Policy as Code | AWS Partner Network (APN) Blog, accessed July 27, 2025, https://aws.amazon.com/blogs/apn/scale-securely-with-hashicorp-terraform-and-sentinel-policy-as-code/
45. Using Hashicorp Sentinel to implement Policy-as-Code within your Terraform Provisioning workflow | by Bruce Cutler | The Slalom Blog | Medium, accessed July 27, 2025, https://medium.com/slalom-blog/using-hashicorp-sentinel-to-implement-policy-as-code-within-your-terraform-provisioning-workflow-c89aac0ecc8
46. Enforce a Policy :: MP DevOps Series, accessed July 27, 2025, https://hashicorp-terraform.awsworkshop.io/060_sentinel/6-policy-quickstart.html
47. Terraform and Sentinel - HashiCorp Developer, accessed July 27, 2025, https://developer.hashicorp.com/sentinel/docs/terraform
48. Write a Sentinel policy for a Terraform deployment - HashiCorp Developer, accessed July 27, 2025, https://developer.hashicorp.com/terraform/tutorials/policy/sentinel-policy
49. Mastering Policy-as-Code with Terraform Sentinel: A Guide for Cloud Security and Compliance | by Aurion Howard | Medium, accessed July 27, 2025, https://medium.com/@aurionhoward/mastering-policy-as-code-with-terraform-sentinel-a-guide-for-cloud-security-and-compliance-00370d655cf0
50. Enforcing Policy as Code in Terraform: A Comprehensive Guide - Scalr, accessed July 27, 2025, https://scalr.com/learning-center/enforcing-policy-as-code-in-terraform-a-comprehensive-guide/
51. Simplify policy adoption in Terraform with pre-written Sentinel policies for AWS - HashiCorp, accessed July 27, 2025, https://www.hashicorp.com/blog/simplify-policy-adoption-in-terraform-with-pre-written-sentinel-policies-for-aws
52. Jenkins - checkov, accessed July 27, 2025, https://www.checkov.io/4.Integrations/Jenkins.html
53. How to Automate Security Scan of Terraform Files using Checkov with Jenkins Pipeline?, accessed July 27, 2025, https://www.coachdevops.com/2025/05/how-to-automate-security-scan-of.html
54. terraform-modules.gitlab-ci.yml · main · GitLab.com / GitLab …, accessed July 27, 2025, https://gitlab.com/gitlab-com/gl-infra/pipeline-templates/-/blob/main/terraform-modules.gitlab-ci.yml
55. Terraform Pipeline with Gitlab CI and OpenID Connect | by Calvine Otieno | Medium, accessed July 27, 2025, https://medium.com/@calvineotieno010/terraform-pipeline-with-gitlab-ci-and-openid-connect-b5c4e73ccb8c
56. microsoft/azure-pipelines-terraform: Azure Pipelines tasks for installing Terraform and running Terraform commands in a build or release pipeline. - GitHub, accessed July 27, 2025, https://github.com/microsoft/azure-pipelines-terraform
57. Implementing Pipeline for Terraform in Azure DevOps Without Extension | by Aatish Sharma, accessed July 27, 2025, https://medium.com/@aatishsharma46/implementing-pipeline-for-terraform-in-azure-devops-without-extensions-d97a34888af0
58. Evaluating Cloud Security in Terraform DevSecOps Architecture and …, accessed July 27, 2025, http://his.diva-portal.org/smash/record.jsf?pid=diva2%3A1984098
59. Secure and compliant infrastructure as code : r/Terraform - Reddit, accessed July 27, 2025, https://www.reddit.com/r/Terraform/comments/1kg10ch/secure_and_compliant_infrastructure_as_code/