TechPrufer
Get started
GitLab
GitLab logoGitLab · Feature trail

Terraform Security and Supply Chain

7 posts · Jun 2019 – Aug 2026

What this trail covers

GitLab CI/CD is evolving to support OCI images as the source of truth for GitOps deployments, moving beyond traditional Git repositories. This enhances delivery control, security through signing and verification, and simplifies manifest management. The platform integrates with Flux CD and Sigstore Cosign, allowing Kubernetes manifests to be pushed and signed as OCI artifacts in GitLab's Container Registry. This enables automated deployments with features like approvals and deploy freezes, and provides a more robust alternative to cloning entire Git repositories for deployments.

All GitLab trails
  1. From OpenTofu to Argo CD: GitLab as your AWS control planeThis post details a comprehensive DevSecOps workflow for infrastructure as code (IaC) using OpenTofu and Argo CD, orchestrated through GitLab CI/CD pipelines. It showcases provisioning AWS environments with OpenTofu, configuring Kubernetes tools (Argo CD, CertManager, Ingress NGINX Controller) via Helm provider, and deploying a sample web application using GitOps principles. The process involves three distinct GitLab pipelines: one for provisioning AWS infrastructure with OpenTofu, another for configuring Kubernetes tools, and a third for deploying the application via Argo CD manifests. It also covers building and packaging the web application into a container image and publishing it to the GitLab Container Registry.
  2. Application security testingThis post details the integration of GitLab with Indeni Cloudrail to automate infrastructure compliance and reduce false positives in IaC security. It emphasizes shifting security checks left in the GitOps workflow and supports OpenTofu for provisioning AWS environments, including networking and EKS clusters, and automates the deployment of core Kubernetes tools like Argo CD.
  3. Pipeline security lessons from March supply chain incidentsThis post details how GitLab Pipeline Execution Policies (PEPs) can be used to address three specific supply chain attack patterns: poisoned tools/actions, packaging misconfigurations that leak IP, and vulnerabilities in transitive dependencies. It introduces open-source PEPs for 'Artifact Hygiene' (blocking packages over 50MB, detecting source maps, and scanning sourceMappingURL) and 'Dependency Integrity' (comparing dependency checksums against known-good lockfile states). It also outlines a proposed PEP for 'Tool and Action Integrity' (pinning tools to immutable references or verifying integrity). The post emphasizes that PEPs are mandatory, cannot be skipped by developers, and are managed by security teams, providing a robust mechanism for centralized policy enforcement within CI/CD pipelines.
  4. Software supply chain security guide: Why organizations struggleThis post expands on the concept of software supply chain security, detailing its components beyond dependency scanning to include source, build, artifact, deployment, and tool security. It introduces new risks introduced by AI, such as model supply chain attacks and insecure AI-generated code. The post also elaborates on the barriers organizations face in implementing effective supply chain security, including the 'false economy mindset,' skills shortages, misaligned organizational incentives, and tool complexity overload. It quantifies the true price of insecurity through metrics on time to identify and contain breaches, reputation damage, regulatory impacts (GDPR, Cyber Resilience Act, SBOMs), and operational disruption. Finally, it critiques current approaches for their focus on massive scanning versus effective protection and collaboration breakdowns, advocating for integrated DevSecOps platforms and developer-native solutions.
  5. How to use OCI images as the source of truth for continuous deliveryThis post introduces the concept of using OCI images as the source of truth for GitOps deployments, moving beyond traditional Git repositories. It details how GitLab's Container Registry, CI/CD, and integration with Flux CD and Sigstore Cosign can be used to push, sign, and deploy Kubernetes manifests as OCI artifacts. The post highlights security benefits like artifact signing and verification, and improved delivery control through CI/CD pipelines. An example CI/CD job demonstrates pushing and signing OCI images, and the use of the GitLab Agent for Kubernetes for cluster access.
  7. Managing multiple environments with Terraform and GitLab CIThis post details a practical setup for managing multiple distinct infrastructure environments (dev, staging, production) within a single GitLab project using Terraform and GitLab CI. It outlines a file structure with environment-specific folders, each containing its own `.gitlab-ci.yml` file that includes a shared `helper.yml`. The CI configuration leverages rules based on file changes within environment-specific directories to trigger jobs like `plan`, `validate`, `deploy`, and `destroy`. It also describes a merge request-based promotion workflow for moving changes through environments.
  8. Top challenges to securing the software supply chainThis post discusses challenges in securing the software supply chain, including the vast attack surface of open-source dependencies and in-house code, the difficulty of implementing zero trust principles, and the increasing ease of launching cyber-attacks. It highlights the need for organizations to assess their threat landscape and suggests tools and processes like version control, multi-factor authentication, and automated security scanning. While it mentions existing solutions and strategies, it does not introduce new technical implementations or directly contribute to the 'Terraform Security and Supply Chain' feature thread beyond contextualizing the problem space.
  9. Introducing the infrastructure bill of materialsIntroduces the concept of an Infrastructure Bill of Materials (IBoM) by partnering with Firefly to discover and manage cloud infrastructure assets. This extends GitLab's GitOps solution to cover cloud footprints and provides drift detection and remediation.
  10. Terraform in the software supply chain: Modules & providersThis post examines the security risks inherent in Terraform's supply chain, specifically focusing on malicious modules and providers. It details how providers, as executable binaries, can be compromised and discusses the mechanisms Terraform uses for provider verification, such as `zh` and `h1` checksums in the `.terraform.lock.hcl` file. The post highlights the vulnerability of Git tags to mutation, which can be exploited to deliver malicious modules. It provides recommendations for securing the Terraform process, including version controlling the lock file and carefully verifying its contents.
  11. Biden administration updates software supply chain security requirementsThis post discusses the Biden administration's updated software supply chain security requirements, including Executive Order 14028 and NIST SSDF 1.1. It highlights the increased focus on code origins, component sourcing, and vulnerability management. GitLab's role in enabling compliance through features like SBOM creation, security dashboards, vulnerability reports, pipeline frameworks, and security scanning is emphasized. The post references existing GitLab blog posts on related topics such as securing the software supply chain through automated attestation and complying with NIST secure supply chain frameworks.
  12. Fantastic Infrastructure as Code security attacks and how to find themThis post introduces specific risks and attack vectors within Infrastructure as Code (IaC) tools like Terraform, focusing on vulnerabilities such as plaintext passwords, public S3 buckets, and supply chain attacks. It details the practical application and output parsing of several IaC security scanning tools (tfsec, kics, checkov, terrascan, semgrep, tflint) using example vulnerable Terraform code. It also provides guidance on developing more IaC scenarios and integrating these scanners into CI/CD pipelines and merge requests for automated security reviews.
  13. Introducing GitLab’s supply chain security direction and landscapeThis post introduces GitLab's Software Supply Chain Security (SSCS) direction and framework, outlining five key aspects: Source, Build, Consumption, Management Process, and Tool Security. It emphasizes the benefits of a single application for SSCS, such as minimizing tools, reducing failure points, enabling seamless interoperability, and simplifying visibility. The post also mentions near-term projects like GitLab Runner Core and highlights the integration with existing capabilities and potential partnerships.
  14. GitOps with GitLab: Infrastructure provisioning with GitLab and TerraformThis post introduces the concept of using GitLab as a GitOps tool with Terraform for infrastructure provisioning. It details the steps for setting up a network and a Kubernetes cluster using Civo, including creating Terraform files for network configuration (`main.tf`, `outputs.tf`, `locals.tf`, `variables.tf`). It also explains how to configure Terraform to use GitLab's managed Terraform state, both locally via direnv and within GitLab CI/CD pipelines using the `Terraform/Base.latest.gitlab-ci.yml` template. The post emphasizes best practices for small Terraform projects and layered infrastructure.
  15. How to get GitOps right with infrastructure as code securityThis post details the integration of Indeni Cloudrail with GitLab CI/CD to shift IaC security checks left in the GitOps workflow. It highlights how this partnership automates infrastructure compliance, provides context-based analysis to reduce false positives, and enables developers to receive instant feedback on security risks within their familiar CI/CD environment, preventing insecure infrastructure from being deployed.
  16. How a DevOps Platform helps protect against supply chain attacksThis post outlines how a DevOps platform can be used to protect against supply chain attacks by integrating security into the software development lifecycle. It details the problems with traditional AppSec approaches and highlights the benefits of an integrated DevOps platform, such as end-to-end visibility and auditability. The post proposes five steps to enhance application security: assessing security hygiene, automating scanning policies and compliance, protecting application infrastructure, securing the software factory itself, and leveraging secrets management. It specifically mentions GitLab's capabilities in SAST, DAST, dependency scanning, container scanning, secrets detection, fuzz testing, and compliance management, as well as its integration with tools like HashiCorp Vault and Falco.
  17. 3 Ways to approach GitOpsThis post details three methods for applying GitOps principles using GitLab: push using manually configured CI/CD release targets (for Kubernetes and non-Kubernetes environments), push using Terraform (for Kubernetes and non-Kubernetes environments supported by Terraform), and pull using a Kubernetes agent (for Kubernetes environments only). It also outlines an upcoming 'push using a Kubernetes agent' approach for Kubernetes environments.
  18. Why GitOps should be the workflow of choiceThis post introduces GitOps as a convergence of infrastructure-as-code and continuous delivery, advocating for its adoption as a workflow. It explains that GitOps uses Git as the central source of truth for infrastructure and application changes, enabling developers and operators to use familiar development patterns and branching strategies. Merge requests are highlighted as the collaborative space for changes, with CI/CD automating deployments upon merging. The post emphasizes that GitOps streamlines the path to production by integrating the pipeline directly into the Git and merge request workflow, reducing unnecessary steps and tools while maintaining governance.
  19. GitLab and HashiCorp streamline delivery workflowsThis post introduces the integration of HashiCorp Terraform and Terraform Cloud with GitLab CI/CD. It outlines how Terraform's infrastructure as code capabilities can be used within GitLab's CI/CD pipelines for automated infrastructure provisioning. It also mentions future iterations involving integration with HashiCorp Vault for secrets management.
  20. Build enterprise-grade IaC pipelines with GitLab DevSecOpsThis post details a comprehensive DevSecOps workflow for infrastructure as code (IaC) using OpenTofu and Ansible, orchestrated through GitLab CI/CD pipelines. It showcases provisioning AWS environments with OpenTofu, deploying applications with Ansible, and integrating security scanning for IaC and container vulnerabilities. Key features include custom Ansible execution environments in the GitLab Container Registry, Ansible linting with Code Quality, and secure cloud access via OIDC integration with AWS. It also demonstrates the use of GitLab's OpenTofu components, Terraform state management, module registry, and CI/CD environment variables for configuration.