Lion Cipher Lab
Write custom Semgrep taint rules and gate CI (advanced SAST)
- AppSec / DevSecOps
- Advanced
- ~60 min
- Free · no account required
Why it matters
Registry rules catch known-insecure PATTERNS on a single line. The bugs that ship past them are usually about FLOW: untrusted input that travels through several variables and function calls before it reaches a dangerous sink like os.system or a raw SQL execute. A naive pattern match ("flag os.system(...)") either misses the bug when the input arrives through a variable, or drowns you in false positives on hardcoded, safe calls. Taint analysis — modeling data as it flows from a SOURCE (user input) to a SINK (the dangerous call), and treating it as safe once it passes a SANITIZER — is how you…
What you'll learn
- the difference between a naive single-pattern match and taint (dataflow source-to-sink) analysis
- authoring a custom Semgrep rule with mode: taint and pattern-sources / pattern-sinks / pattern-sanitizers
- modeling a whole vulnerability class (command injection) instead of one line
- proving a sanitizer works: a true positive fires but a sanitized path does NOT
- tuning a rule down to cut false positives without losing true positives
- gating CI with a non-zero exit (semgrep ci / semgrep --error) that fails a GitHub Actions job
- setting a severity threshold and a triage / nosemgrep policy
- the judgment of when to fail the build vs warn, and the honest limits of SAST
Steps in this lab
- The idea: taint (dataflow) vs a single-pattern match
- Set up and write a deliberately-vulnerable app
- Author the custom taint rule (mode: taint)
- Run it and confirm the true positive fires
- Prove the sanitizer works: the safe path does NOT fire
- Tune for false positives
- Gate CI: fail the build on a tainted flow
- The judgment: when to fail the build, and honest limits