Semgrep findings fail the job (exit code 1) in CI

By Kaveh Alemi·Latchkey

Semgrep is designed to gate: when semgrep ci (or semgrep scan) finds blocking rules, it exits non-zero and fails the job. This is the tool working as intended, not a crash. The output lists the findings that triggered it.

What this error means

The Semgrep step ends with "X blocking findings" and exit code 1, failing the workflow. The scan itself ran successfully.

Ran 214 rules on 1892 files: 3 findings.
  3 Blocking findings
Semgrep exited with code 1

Common causes

Real blocking findings were detected

Rules marked as blocking matched code, so Semgrep fails the job to stop the change until the findings are resolved or triaged.

A rule is too broad and flags acceptable code

An overly generic rule matches patterns you consider safe, producing findings you need to suppress or downgrade.

How to fix it

Triage or fix the findings

1. Read each finding and its rule id in the output.
2. Fix the real issues in code.
3. For accepted cases, add a targeted # nosemgrep: rule-id comment on that line.

password = get_secret()  # nosemgrep: python.lang.security.hardcoded-password

Adjust severity or exclude paths deliberately

Downgrade a noisy rule from blocking, or exclude generated code in .semgrepignore, rather than disabling the gate entirely.

How to prevent it

• Run Semgrep locally or in pre-commit so findings surface before CI.
• Use scoped # nosemgrep: rule-id suppressions, not blanket ignores.
• Keep the ruleset tuned to reduce false positives.

Frequently asked questions

Related guides

References

• GitHub Actions documentation