Static Analysis

Static analysis catches the bugs validate cannot — a publicly readable bucket, a 0.0.0.0/0 firewall rule, a disk with no customer-managed key — by inspecting your HCL against a rule set before any apply. validate proved the config is well-formed; these tools prove it is not dangerous. They read the same files and reach a different verdict.

Three tools cover GCP. tflint with the google ruleset handles provider-specific correctness and deprecations; tfsec (now folded into Trivy) and checkov handle security and misconfiguration scanning. All three are fast, credential-free, and run right after validate in the same cheap offline gate — they never touch Google Cloud.

tflint and the google Ruleset

tflint flags invalid google provider usage that validate misses: deprecated arguments scheduled for removal, machine types or regions that do not exist, unenforced naming conventions, and declarations you wrote but never referenced. The base tflint binary is provider-agnostic; the GCP awareness comes from the tflint-ruleset-google plugin, which carries the rules that know e2-medium is real and e2-mediumm is a typo.

The line against validate is this: validate checks that an argument exists in the schema and has the right type; tflint checks that its value makes sense. A region string that is syntactically a string but names no real GCP region passes validate and fails tflint.

# .tflint.hcl — enable the GCP-aware plugin
plugin "google" {
  enabled = true
  version = "0.31.0"
  source  = "github.com/terraform-linters/tflint-ruleset-google"
}

With the plugin pinned to a version, tflint --init downloads it and tflint --recursive runs it across the root module and every submodule. Pinning the version matters: an unpinned plugin can pull a new rule release that turns a green pipeline red without any change to your code.

tfsec / Trivy

tfsec — now distributed inside Trivy — is a security-focused scanner with hundreds of built-in GCP rules. It reads your HCL and flags a google_storage_bucket made public, a google_compute_firewall allowing ingress from 0.0.0.0/0, disks and Cloud SQL instances without CMEK, and over-broad IAM bindings. Every one of those is a finding produced from the source, before a single resource exists.

checkov

checkov (from Bridgecrew, now Prisma Cloud) is a policy-as-code scanner with a large GCP rule library and support for custom policies in Python or YAML. It overlaps with tfsec on coverage and adds graph-based checks across resources — so a bucket and a separate google_storage_bucket_iam_member that together make data public can be evaluated as a pair, not just one resource at a time. Run both and you get broad coverage plus the cross-resource view.

The GCP Misconfigs They Catch

The findings cluster into a recurring GCP exposure list. Public buckets — an allUsers or allAuthenticatedUsers principal in an IAM member. Default-allow firewall rules that open a port to the whole internet. Missing customer-managed encryption keys on disks, Cloud SQL, and BigQuery where policy requires them. Public Cloud SQL instances with an external IP. Unrestricted SSH on port 22 from 0.0.0.0/0. These five are the ones that surface again and again.

The example below is exactly the kind of config that passes validate cleanly and is the reason scanners exist. The IAM member grants the world read access to the bucket, and the firewall opens SSH to the entire internet — both well-formed, both wrong.

resource "google_storage_bucket_iam_member" "public" {
  bucket = google_storage_bucket.raw.name
  role   = "roles/storage.objectViewer"
  member = "allUsers"            # public read — tfsec & checkov flag
}

resource "google_compute_firewall" "ssh" {
  name          = "allow-ssh"
  network       = google_compute_network.vpc.id
  source_ranges = ["0.0.0.0/0"]   # SSH from the whole internet
  allow {
    protocol = "tcp"
    ports    = ["22"]
  }
}

A scanner fails the build on both. The fix is to scope the member to a real principal and the firewall to a known source range or, better, replace direct SSH with Identity-Aware Proxy — but the point here is that the gate catches the exposure before apply, when it costs nothing.

Wiring Into CI

Run the scanners after validate and before plan, in the offline credential-free stage, and fail the build on high-severity findings. They need no GCP access, so they fit alongside validate in the cheap gate. The job is to stop a public bucket from ever reaching a plan, let alone an apply.

Real configs occasionally need a documented exception — a bucket that is genuinely meant to serve public assets. Handle it with a narrow inline ignore (#tfsec:ignore:google-storage-bucket-not-public) on the specific resource, with a comment naming the reason, never a blanket baseline that suppresses a whole rule. The moment everything is suppressed, the gate is theater and the next real public bucket sails straight through.