Semgrep matches patterns against the syntax tree rather than the raw text, so a rule looks like the code it is looking for. That is what makes it practical to write a project-specific rule in minutes instead of learning a query language.

This is the tool the series leans on hardest. The recurring finding across posts is that the standard scanners miss framework-specific misuse — mark_safe() on a variable, fields = '__all__' on a ModelForm, .raw() with an f-string — and that a five-line Semgrep rule catches every one of them, in CI, on every commit.

• Custom rules for framework misuse the generic scanners miss
• CI gate that fails the build on a new dangerous pattern
• Codifying a security review finding so it cannot regress