Scanning Infrastructure Code: A Worked Example for DevOps Consultants

Say a client engagement starts with a Terraform repo that provisions a VPC, a handful of managed services, and an S3-style storage bucket. Snyk's infrastructure-as-code scanning reads the Terraform plan and flags misconfigurations before they're applied, such as a storage bucket left open to public read access or a security group with an overly broad inbound rule. That check runs at pull request time, catching the mistake before terraform apply ever runs against the client's account.

Catching it here, rather than after the resource already exists in the client's account, saves the awkward cleanup step of tearing down and rebuilding something that's already live.

Once the Terraform layer provisions a Kubernetes cluster, the Helm charts defining what runs inside it carry their own risk: a container running as root by default, a resource limit left unset, a secret mounted more broadly than it needs to be. Both tools can catch dependency issues in the application code packaged into those containers, but the chart configuration itself benefits from the same infrastructure-as-code scanning applied to the Terraform layer, so treat the two as one continuous review rather than separate steps.

The pipeline that builds and pushes images to a registry is where a stale base image usually hides. If the client's build process pulls a base image tagged 'latest' rather than a pinned version, a fix that landed in the base image upstream months ago might never actually reach the running container. Pin base image versions, rebuild on a schedule even without a code change, and scan the built image, not just the Dockerfile, since a vulnerability can enter through a layer the Dockerfile doesn't directly reference.

This is also the stage where an engagement most often reveals it never had a rebuild schedule at all, just a pipeline that ran once at launch and hasn't been touched since.

Snyk's infrastructure-as-code and container scanning are built for exactly this stack, and because it isn't tied to GitHub, a consultant can run the same scanning approach whether the client hosts on GitHub, GitLab, or a self-hosted Git server. GitHub Advanced Security's code scanning is strong for the application layer sitting on top of the infrastructure, but it wasn't built primarily as an infrastructure-as-code tool, so a consultancy whose main deliverable is the Terraform and Helm layer will likely still want a dedicated IaC scanner regardless of what the client uses for application code.

A consultant who builds a secure pipeline and then leaves is only half finished. Document which scans run at which stage, who gets notified on a failed check, and what the fix process looks like for a common finding like an open storage bucket. Teams with a mature deployment pipeline tend to see fewer failed changes reach production than teams without one, a pattern the DORA research tracks across performance clusters¹, which is worth mentioning to a client who's deciding whether the extra pipeline steps are worth the friction.

A pipeline runbook the client can maintain should record:

• Which scans run at each stage of the pipeline, so the client knows what is checked before an image is pushed.
• Who gets notified when a check fails, named by role so alerts do not depend on the consultant who built the pipeline.
• What the fix process looks like for a common finding, such as an open storage bucket.
• What a typical failure looks like, so the client's team can tell a real problem from noise.

A pipeline that only the consultant who built it understands is a liability the moment that person moves on to the next engagement. Leave the client with a short runbook: what each scanning stage checks, what a typical failure looks like, and who on the client's side should be notified first when something breaks. Walk one of the client's own engineers through a deliberately triggered failure before you leave, so the first real failure they hit after you're gone isn't also the first time they've seen the process work.

Clients who inherit a pipeline they understand tend to keep the security checks running long after the consultant is gone; clients who inherit a pipeline they don't understand tend to quietly disable the checks the first time one blocks a release they're in a hurry to ship.