Notifications
Clear all
Topic starter
02/08/2026 12:31 pm
TL;DR: Single-file SAST misses real vulnerabilities when taint, inheritance, and data flow cross boundaries, according to Semgrep’s interfile analysis work, even though a benchmark of Java SQL injection cases improved from a 10% to 56% score. The broader lesson is that code security fails when analysis scope stops at file boundaries, not when teams lack more rules.
NHIMG editorial — based on content published by Semgrep: interfile analysis for SAST and the path from benchmark to engine
By the numbers:
- Semgrep’s benchmark score improved from 10% to 56% after interfile analysis was added.
Questions worth separating out
Q: How should security teams evaluate interfile SAST in real codebases?
A: They should test it against representative repositories with known vulnerabilities, not synthetic examples.
Q: Why do file-level scanners miss injection risks so often?
A: Because the risky path usually spans more than one file.
Q: What do security teams get wrong about interfile analysis?
A: They often assume the main challenge is deeper computation, when the bigger problem is understanding realistic code structure.
Practitioner guidance
- Benchmark scanners against real cross-file paths Use repositories with known vulnerabilities to test whether the tool preserves source-to-sink chains across classes, methods, and helper files.
- Separate single-file and interfile rule sets Maintain distinct rule logic for file-local patterns and interfile taint detection, because rules tuned for one mode often behave badly in the other.
- Prioritise injection paths that span services Focus first on command injection, SQL injection, SSRF, and similar issues where user input often moves through controllers, helper methods, and service layers before reaching a sink.
What's in the full article
Semgrep’s full post covers the implementation detail this post intentionally leaves for the source:
- The benchmark construction method, including how the team selected Java repositories and annotated true positives and false negatives.
- The rule design differences between single-file patterns and interfile taint rules, which matter when you are tuning scanners for CI.
- The engine-side debugging and performance work that was needed before the interfile rules were stable enough for broader testing.
- The specific examples of command injection paths that become visible only when the analysis can follow code across files.
👉 Read Semgrep’s analysis of interfile code analysis for SAST →
Interfile code analysis for SAST: are your controls keeping up?
Explore further
02/08/2026 1:28 pm
Cross-file visibility is now a baseline requirement for meaningful application security scanning. File-by-file rule engines can still be useful for local pattern checks, but they fail once input handling and risky sinks are separated by normal software structure. That is especially true in modern applications built from controllers, helpers, services, and shared libraries. Security teams should treat cross-file reasoning as a detection requirement, not an advanced optional feature.
A question worth separating out:
Q: How do teams decide whether to trust advanced SAST findings?
A: They should look for repeatable evidence that the engine finds real vulnerabilities across multiple repositories and keeps false positives low enough for CI use. Trust increases when rules are explicit, findings are reproducible, and the analysis matches how the code is actually structured. If developers cannot verify a match quickly, adoption will stall.
👉 Read our full editorial: Interfile code analysis changes what SAST can catch in practice
