When a SAST tool misses a flaw, the cause is usually one of five things: the file was never scanned, the build or dependencies were incomplete, the tool does not know your framework, the flaw is the kind static analysis cannot see, or the rules do not cover that pattern. Work through them in order.
First, confirm what was scanned
Before blaming the engine, check whether it ever looked at the vulnerable code. Open the scan log and answer three things: was the file in scope, was the language recognized, and did the scan finish without errors.
Exclusion lists are a common culprit. A path excluded for noise, such as a test folder or a generated directory, can quietly hide a real route handler. A related post covers what to exclude and what not to.
The checklist
- Scope. Is the file included, and was the right branch or commit scanned?
- Parsing. Did the tool parse the file, or skip it on a syntax or version problem?
- Build setup. OWASP notes that many tools have difficulty with code that cannot be compiled, often because libraries or build instructions are missing. Check whether dependencies resolved.
- Framework knowledge. Does the tool know how your framework receives input and renders output? Custom wrappers around request objects can hide a source from the tool.
- Flaw type. Is this a flaw static analysis is weak at, such as access control logic or a configuration issue?
- Rule coverage. Does any rule exist for this pattern in this language?
Reading the result of each step
| If you find | Likely fix |
|---|---|
| File excluded or not scanned | Change scope, rescan |
| Parse error | Update language settings or tool version |
| Build incomplete | Fix dependency resolution for the scan |
| Unknown framework or wrapper | Add a custom source or sink definition if supported |
| Flaw type is hard for static analysis | Cover it with review or dynamic testing |
| No rule | Ask the vendor or write a custom rule |
OWASP describes false negatives as cases where a vulnerability exists but the tool does not report it, and gives two reasons: a new vulnerability discovered in an external component, or an analysis tool with no knowledge of the runtime environment and whether it is configured securely. Neither is a bug in your setup. Both are limits to plan around.
Turn the miss into a regression test
Once you know why it was missed, keep the evidence. Save a minimal reproduction of the vulnerable code as a test fixture. When you update the tool or its rules, rerun the fixture. If the miss comes back, you will know immediately.
A short record per miss is enough: the weakness type, the cause from the table, the fix, and the date. After a few of these you will see which cause dominates in your codebase, and that tells you where to invest.
When the answer is "it cannot"
Sometimes the honest finding is that the tool is not the right method for this flaw. That is fine. A SAST tool is one layer. Authorization flaws, for example, are better covered by targeted tests and review.
A worked example: the missed path traversal
A team finds, during a penetration test, that a download endpoint lets a caller read files outside the intended folder. The SAST tool had been running on every pull request and had reported nothing. They run the checklist.
Scope: the endpoint file is in the scan. Passed.
Parsing: the log shows the file was parsed. Passed.
Build setup: dependencies resolved. Passed.
Framework knowledge: the endpoint reads the file name through a small helper that wraps the framework's request object. The tool does not recognize the helper as a source of untrusted input. Found it.
The fix has two parts. First, the team adds the helper as a custom source if the tool allows it, and reruns the scan to confirm the finding appears. Second, they save the endpoint as a regression fixture, so a future rule update cannot silently drop the detection.
Without the checklist, the team might have concluded the tool was useless. With it, they found a specific, fixable gap.
How to read the scan log
Most tools produce a log or a coverage report. Look for these lines:
| What to find | What it means |
|---|---|
| Number of files parsed versus files found | Gap means skipped files |
| Warnings about unresolved imports | Build or dependency problem |
| Languages detected | Missing language means no analysis |
| Rules loaded | Missing rule family means no checks of that kind |
| Exit status and partial results messages | Scan may have stopped early |
If the tool offers no such log, that is itself a finding about the product.
Distinguishing a gap from a limit
A gap is something you can close with configuration. A limit is something the method cannot do well. The distinction decides what you do next.
- Gap examples: an excluded folder, a missing build step, an unknown helper function, a disabled rule family. Fix by configuring the tool.
- Limit examples: a missing authorization check, a business rule violation, an insecure setting in a deployment file. Cover with review, tests or another type of scanner.
OWASP describes static code analysis as having difficulty with problems such as authentication, access control and insecure use of cryptography, and with configuration issues not represented in code. These are limits. No amount of tuning will turn them into dependable detections.
Building a miss log
Keep a simple table of every confirmed miss. Over time it becomes the most valuable data you have about the tool.
| Date | Weakness | Cause category | Fix | Test fixture added |
|---|---|---|---|---|
| Example row | Path traversal | Unknown helper | Custom source | Yes |
After ten or so entries, count by cause. If most are scope and build problems, invest in pipeline hygiene. If most are unknown helpers, invest in custom definitions. If most are limits, invest in other methods. The log turns frustration into a plan.
What to tell the vendor
When a miss looks like a gap in the product, send the vendor a minimal reproduction: the smallest code that shows the flaw, the tool version and the settings. Vendors can act on that quickly. Ask whether a rule exists, whether it is enabled by default, and when a fix is expected. Their response tells you something about support quality too.
When a miss is a sign to broaden coverage
One missed flaw found by a penetration test is a reason to ask what else is not covered. Use the miss to run the checklist across your other services, not just the one that failed.
Try it yourself
Click through it at your own pace, or open it full screen. Notice what a finding needs before it can be reported: a location, a weakness type and a path.
Quick check
What is the first thing to check after a miss?
Whether the vulnerable file was scanned at all. Scope and exclusions explain more misses than engine limits do.
Should I switch tools after one miss?
Not on one miss. Find the cause first. If the same cause recurs across many cases, that is stronger evidence.
Should every miss become a test fixture?
Yes for confirmed misses. A small fixture is cheap, and it catches regressions when you update the tool or its rules.
Safeguard offers SBOM and dependency scanning plus zero-day discovery for the packages you ship, and a free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
