A custom rule finds patterns that can be described in code structure, such as a banned call or a missing argument. It struggles with access control logic, business rules, runtime configuration and anything that depends on how components behave together. Pair rules with tests, review and runtime testing for those.
What rules are good at
OWASP's source code analysis page lists strengths of static tools: they scale, can run repeatedly in continuous integration, identify certain well known vulnerabilities such as buffer overflows and SQL injection flaws, and point developers to the file, line and code snippet. Custom rules extend that with checks for your own APIs and conventions.
What they struggle with
The same page lists weaknesses. It says some types of vulnerability are difficult to find by automated search, including authentication problems, access control issues and insecure use of cryptography. It also says static tools frequently cannot find configuration issues because those are not represented in the code, that it is hard to prove a reported issue is a real vulnerability, and that many tools have difficulty analyzing code that cannot be compiled.
Gap table
| Concern | Why a rule struggles | Better partner |
|---|---|---|
| Broken authorization | The rule would need to know who may do what | Automated tests of access per role, code review |
| Business logic flaws | Intent is not in the syntax | Design review, abuse case tests |
| Runtime configuration | Lives in environment, not code | Configuration scanning and runtime checks |
| Behavior of a running app | Static view only | Dynamic testing |
| Vulnerable dependencies | The flaw is in code you did not write | Dependency scanning with reachability |
| Secrets in history | Rules see the current tree | Secret scanning over history |
| Cross service data flow | A single rule sees one codebase | Threat modeling, integration tests |
How to fit a rule into a wider plan
- Write down the risk, not the rule. "Users can read other users' invoices" is a risk.
- Ask what would catch it. Often it is a test that logs in as user A and requests user B's data.
- Use a rule only where a pattern truly captures the risk, such as "every route handler calls the authorization helper".
- Accept that some risks are covered by process, such as design review.
A useful middle ground
Some rules check that a protective step is present, not that it is correct. "Every handler calls the check" does not prove the check is right, but it removes the case where someone forgot to call it, and that is a common bug. Combine it with tests of the check itself.
Read a clean result carefully
A clean run means no match for the patterns you wrote. It does not mean absence of the risk. Say so in your documentation: each rule's page should include a short "does not cover" line.
Try it yourself
Click through it at your own pace, or open it full screen.
This demo tests a running application. Look at what it can observe that a source pattern cannot.
Quick check
Can a rule detect missing authorization checks?
Only in limited forms, such as confirming a helper is called. Whether the check is correct usually needs tests or review.
Does a clean static analysis run mean the code is secure?
No. It means the patterns you checked were not found.
Safeguard's scanning covers dependencies and SBOMs, and its reachability analysis helps show which findings your code can actually call. You can run a free scan on a repository.
Sources
Last reviewed: 19 October 2026.
