Static analysis
🏠The everyday picture
A spelling and grammar checker reads every page of a manuscript without getting tired, catching the routine mistakes so the editor can focus on meaning.
📘What it really is
- Static analysis (SAST) examines source code without running it, looking for risky patterns.
- Tools:
- TypeScript in strict mode catches whole classes of bugs (Module 29);
- ESLint with security plugins (
eslint-plugin-security) flags patterns likeevalor unsafe regular expressions; - Semgrep: rules for injection, XSS, secrets, unsafe crypto; free community rules for JavaScript and TypeScript;
- GitHub CodeQL code scanning: free for public repositories, available for private ones on some plans; runs in Actions and shows findings on pull requests;
-
secret scanners (gitleaks, GitHub secret scanning, Module 77).
-
Run them in CI on every pull request, so problems appear while the change is fresh.
-
False positives: tools flag some safe code. Review each finding, fix real ones, and mark false ones with a short explanation. Don't turn a tool off because it's noisy; tune it.
-
Limits: static analysis can't see business logic problems ("staff can approve their own refund") or most authorisation gaps. Those need tests and review.
🖱️Try it
Add a Semgrep job (or CodeQL, if your repository supports it) to your CI workflow. Run it, review every finding, fix the real
ones and document the false positives. Turn on TypeScript's strict if it isn't already.
✅Quick check
What can static analysis find, and what does it usually miss?
Show the answer
It finds risky code patterns (injection, unsafe functions, secrets); it usually misses business-logic and authorisation flaws.
What should you do with a false positive?
Show the answer
Review it, and if it's really safe, mark it with an explanation rather than turning the tool off.