Home / Knowledge hub / Static analysis rules
Knowledge hub
Static analysis rules
The patterns a code scanner uses to decide what counts as a flaw.
What it means
Static analysis rules are the instructions a code scanner follows. Each rule describes a pattern that suggests a flaw, such as user input flowing into a database query without being cleaned. The scanner reads your source without running it and reports every place the pattern appears.
A scanner is only as good as its rules. It cannot find a flaw nobody has written a rule for, and a badly written rule floods you with false alarms. When two tools disagree on the same code, the difference is almost always in the rules.
Why it matters
Rules decide what your team sees and what it never hears about. A rule set too narrow gives false comfort: a clean report that simply did not look. One set too broad produces thousands of alerts, and developers learn to ignore all of them, including the real ones.
That makes rules a business matter as well as a technical one. If you tell a customer or auditor that code is scanned on every change, the honest follow-up is what the scan checks for. It also affects false positives and missed flaws.
How it shows up
You meet rules as rule packs bundled with a static analysis tool, as custom rules your own team writes for in-house patterns, and as severity settings that decide what fails a build. Rules are commonly mapped to a CWE number so a result can be compared across tools.
The usual mistakes: running defaults forever, never reviewing which rules fire, and switching off a noisy rule instead of fixing it. A better habit is a short review each quarter. Look at what is ignored, what was fixed, and which flaws were found some other way that no rule caught.
Questions people ask
Static analysis rules, answered
Who writes the rules in a code scanner?
The tool vendor or open source community supplies most of them. Your team can add custom rules for your own frameworks and internal functions.
Custom rules matter most where you wrap a risky function in your own helper that a generic rule does not recognise.
Why does a scanner miss flaws that are in my code?
Usually because no rule describes that flaw, or because the data path crosses something the tool cannot follow, such as a framework feature or a call between services.
Logic flaws, such as a missing ownership check, rarely match a pattern at all.
How do I reduce false positives?
Tune the rules that fire most often, mark confirmed non-issues with a reason, and raise the threshold for blocking builds. Keep a record of what was suppressed and why.
Do not switch off whole categories without checking they are really irrelevant.
Are more rules always better?
No. More rules mean more output, and output nobody reads protects nothing. Start with rules for flaws that are common in your stack and high in impact.
Add rules when you can triage the extra results.
Can a static scan prove a flaw is exploitable?
No. It shows that a pattern exists in the code. Whether an attacker can reach and use it depends on the running app, its configuration and its defences.
Testing the live application is how you confirm it.
Sources
Where this comes from
Related
Terms that sit next to this one
SAST
Tools that read your source code without ever running it.
False positive
A reported issue that turns out not to be real.
False negative
A real vulnerability that a test failed to find.
CWE
A catalogue of vulnerability types, rather than individual bugs.
Secure code review
Reading code specifically to spot security flaws before they ship.
Is the flagged line actually reachable?
Rules tell you where code looks wrong. In white-box mode we read your code while testing the running app, so a finding can point to the file and line. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.