The Same Flaws Keep Entering at the Code Stage. Here Is What We Put in the Way.

A small tip for development companies: use Semgrep to find security holes in your code.

Across the security assessments and code reviews we run at AppSec Labs, we see again and again how the same security problems enter systems at the code stage - sometimes without the developers being aware of it at all.

One of the tools we most like to put into the process is Semgrep - a static code scanner (SAST) that is clever, light and fast, and makes it possible to find weaknesses simply, accurately, and tailored to your own code.

Why it is so useful to us

• It scans code intelligently - not regex-based, but based on an understanding of code structure.
• It supports modern languages: Python, JS, TS, Java, Go and more.
• You can run it locally, inside CI/CD, or as part of a review process.
• It has dozens of ready-made rules, including categories like XSS, SQLi and SSRF.
• You can write your own rules to match your organisation's code.

Getting started

• Installation is very fast:pip install semgrep or brew install semgrep, or simply run it through Docker.
• A first scan: run semgrep --config=auto against the project directory - within a minute you will see results.
• CI/CD integration: a simple connection to GitHub Actions, GitLab CI or Jenkins, to stop pull requests with security problems.
• Custom rules are easy: build your own in YAML to catch patterns specific to you.

The bottom line is that Semgrep lets you identify security problems at an early stage, save expensive fixes in production, and improve code quality without loading the development team down.

One caveat from our side of the table, which applies to any scanner: it finds the classes of flaw that have a shape. The ones we spend most of an engagement on - authorization, tenant isolation, business logic - have no malformed request to match on. Put Semgrep in the pipeline, and do not mistake a clean run for a tested system.

I first shared a version of this as a LinkedIn post on 2025-04-20. It is republished here, lightly edited, so it is easier to find and reference. — Erez Metula