PS Product SecurityKnowledge Base

๐Ÿ”Ž Semgrep for Cloud Security and Infrastructure as Code

Intro: Semgrep started as a code-focused pattern-matching tool and was often used in cloud security through workarounds and generic matching. That history still matters because many teams first encountered Semgrep for Terraform, CloudFormation, or YAML through custom rules. The modern picture is better: Semgrep now has direct Terraform support and still remains useful for custom patterns, YAML-heavy review, and โ€œsecurity reviewer sanity checks.โ€

What this page includes

  • where Semgrep fits for cloud and IaC review;
  • old-versus-current guidance;
  • practical rule examples for Terraform and YAML;
  • how to use it next to Trivy, Checkov, or policy engines.

Why Semgrep matters in cloud security

Semgrep is especially useful when you need to answer questions like:

  • can we detect a risky pattern that is easy to describe but not covered by our default scanner?
  • can we catch copy-pasted bad Terraform or YAML fragments before merge?
  • can we write one rule that becomes a reviewer memory aid across many repos?

Legacy versus current reality

Topic Older pattern Better current 2026 reading
Terraform support generic pattern matching was the main trick Terraform is now directly supported by Semgrep; generic matching still matters for edge cases
YAML use custom patterning with broad text-like rules still useful, but combine with native manifest scanners and admission policy
Role in pipeline โ€œone clever scannerโ€ best as a targeted custom-rule layer next to Trivy, Checkov, or OPA/Kyverno
Team ownership AppSec-only experimentation stronger when platform and product security teams co-own rules

Where Semgrep fits best

Good fits

  • custom checks for organization-specific Terraform modules;
  • detecting dangerous defaults in internal templates;
  • fast policy-like checks on YAML, CI config, Dockerfiles, or shell;
  • cloud reviewer guardrails that are easier to read than a complex policy engine.

Poor fits

  • complete CSPM coverage;
  • runtime policy enforcement;
  • deep package vulnerability analysis;
  • replacing admission or deploy-time enforcement.

Practical usage patterns

Pattern 1 โ€” custom Terraform checks

Use Semgrep where the risky pattern is obvious and repeated.

Example: unencrypted EBS volume.

See snippet:

Run:

semgrep scan --config ../snippets/cloud/semgrep/terraform-unencrypted-ebs.yaml terraform/

Pattern 2 โ€” open-to-the-world security group review

Use Semgrep to catch obviously wide ingress in local or CI review.

semgrep scan --config ../snippets/cloud/semgrep/aws-open-security-group.yaml terraform/

Pattern 3 โ€” YAML or generic config review

Use Semgrep when you want to find a repeated anti-pattern in Helm values, GitLab CI, or internal templates.

semgrep scan --config p/security-audit kubernetes/

Practical guidance for teams

Use Semgrep for what humans would otherwise grep manually

That is the sweet spot.

Keep rules short and reviewer-readable

If only one person understands the rule, the control will decay.

Treat custom rules as product code

  • version them;
  • test them;
  • document false positives;
  • assign rule ownership.

Do not turn Semgrep into fake CSPM

It is stronger as a targeted custom check layer than as a replacement for purpose-built cloud posture tooling.

Suggested placement next to other tools

Problem Better primary tool Where Semgrep helps
broad Terraform/Kubernetes misconfig scanning Trivy config, Checkov, Kubescape custom organization-specific patterns
cloud runtime drift or posture CSPM / cloud-native services pre-merge code review layer
Kubernetes deployment prevention Kyverno, Gatekeeper, PSA early design and review checks
SAST in app repos Semgrep Code / other SAST same engine can extend into IaC and CI config

Practical rollout model

  1. start with 3 to 10 high-signal cloud/IaC rules;
  2. run in advisory mode first;
  3. document recurring false positives;
  4. promote only the clearest rules into blocking mode;
  5. keep Semgrep next to, not instead of, broader IaC tools.

---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.