BlogCI/CD

SAST in CI with Semgrep and custom rules

Add fast static analysis to your pipeline and write project-specific rules that catch your own recurring bugs.

Jan 28, 2026·9 min readIntermediate

Semgrep matches code against patterns that look like the code itself — no AST wrangling. It ships thousands of community rules and, crucially, lets you write a rule for your own recurring mistakes in a few lines of YAML. That combination is why it fits in CI without a security team babysitting it.

bash — a first passlive
semgrep --config auto .
python.lang.security.audit.subprocess-shell-true
app/tasks.py:42 subprocess.run(cmd, shell=True)
ran 1,284 rules on 96 files, 3 findings

Run it on every merge request

.gitlab-ci.yml
sast:
stage: test
image: semgrep/semgrep
script:
- semgrep ci --config auto --error

Write a rule for your own bug

Say your codebase must never build SQL with f-strings. Encode it once and it is enforced forever.

rules/no-fstring-sql.yaml
rules:
- id: no-fstring-sql
languages: [python]
severity: ERROR
message: Build SQL with parameters, not f-strings (injection risk).
patterns:
- pattern: cursor.execute(f"...")
Start with warnings
Introduce new rules as WARN, fix the backlog, then flip to ERROR so they block. A gate that fails on day one gets turned off by day three.

Keep the signal high

Baseline the existing findings so only new issues fail the build, and use nosemgrep comments sparingly with a reason. The goal is a scanner developers trust, not one they route around.

Go deeper in a courseSoftware supply chain securitySAST, dependency and secret scanning, SBOMs, and signing.View course

Related posts