Automation, IaC & DevSecOps

The Terraform exists. One repository, a few thousand lines, written by someone who has since moved teams. Running a plan against production returns a wall of diffs nobody can explain, so nobody runs it, so the drift compounds. Changes go out through a pipeline that was configured once and has not been touched since, and the one person who understands it is on call permanently by accident.

Security sits at the end. A scanner runs on a schedule, writes findings to a dashboard, and someone exports them to a spreadsheet twice a year when an enterprise customer asks. Nothing blocks. A vulnerable dependency ships on Tuesday and is discovered in March.

None of this is a competence problem, and it will not be fixed by hiring one more DevOps engineer. Platform patterns are the kind of thing an organization either has or spends eighteen months rediscovering. A new hire without existing patterns to work from will build the pipeline they built at their last company, which was shaped by constraints you do not have.

The module library

Everything starts here, because pipelines built on unversioned modules are pipelines that break on someone else’s merge. Modules are extracted from what you already run, cleaned up, given inputs and outputs that make sense to a team that did not write them, and published to a private Artifact Registry Terraform repository with semantic versions.

Each module gets tests. Not a token example directory — actual validation that a plan succeeds against representative inputs, so a change to a shared module fails in CI rather than in someone’s production apply.

Consumers pin versions. That single change is what turns a shared Terraform repository into a platform: the networking team can ship a module update without breaking every environment that depends on it, and application teams upgrade on their own schedule.

State, workspaces, and promotion

Remote state moves to Cloud Storage with locking, split along blast-radius boundaries rather than along whatever the original repository structure happened to be. A change to a development database should not require a plan that touches production networking.

Environment promotion becomes explicit: the same module versions move from development to staging to production through pipeline configuration, not through a human editing a different tfvars file in each place and hoping they match.

Pipelines and gates

Delivery pipelines are built on Cloud Build or GitHub Actions — whichever your organization already uses, because introducing a third CI system to fix a CI problem is not an improvement. Pipelines are templated, so a new service gets a working pipeline by configuration rather than by copying the last one and editing it until it runs.

Gates are real. A plan is posted for review before an apply. A failing policy check stops the pipeline. Promotion to production requires an approval that is recorded. The runbook covers the exception path, because a gate with no documented way through it becomes a gate everyone learns to bypass.

Policy as code

• +Terraform plan validation, so a plan that would create a public bucket or an over-broad IAM binding fails in CI rather than in review.
• +Policy Controller or OPA Gatekeeper on GKE, enforcing the constraints that matter for your workloads: no privileged containers, required labels, image sources restricted to your registry.
• +Organization policy constraints wired into the same repository, so the guardrails and the resources they guard are versioned together.

Security in the pipeline, not after it

Static analysis and dependency scanning run on every commit. Secret detection runs pre-commit and in CI, because the pre-commit hook catches most of it and the CI check catches the developer who skipped the hook.

Dynamic testing runs against a deployed pre-production environment rather than against a static artefact, which is the only way to find the class of issue that only exists once the thing is running and wired to its dependencies.

Gate thresholds are set with you, and they do not start at maximum. A pipeline that blocks on every medium-severity finding on day one gets disabled in week two. The usual pattern is to block on new critical and high findings, report everything else, and tighten as the backlog comes down.

Supply chain

Images are built once and promoted, not rebuilt per environment. Artifact Registry holds them with vulnerability scanning enabled. Binary Authorization enforces that only images built by your pipeline and signed by it can run on your clusters, which closes the gap between a hardened build process and a cluster that will happily run anything someone pushes.

Provenance attestation records what was built, from which commit, by which pipeline. That record is what turns a supply chain claim in a security questionnaire into something you can actually evidence.

Drift detection

A scheduled plan runs against every environment and reports differences. Drift is not treated as an error to suppress; it is treated as information. Some drift is a legitimate emergency change that needs to be codified. Some is a console edit that should be reverted. The runbook covers both paths, and the point is that neither category stays invisible for six months.

What this package does not cover

Application code is not modified and application tests are not written. The pipeline runs your test suite; building that suite is your team’s work.

Findings the scanners raise are reported, not remediated. Turning on SAST across an existing codebase surfaces a backlog, and working that backlog is application engineering rather than platform engineering. Third-party scanner licensing is bought by you directly — tool choice stays yours, and it should not be bundled into a consulting fee.

CI platforms beyond the agreed runner are out of scope. Pipelines are built on one system, not ported to three.

Deliverable. Module library, pipeline templates, policy bundle, and a runbook covering promotion, rollback, and gate exceptions.