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.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “The birth of Semgrep Pro Engine”.
By the numbers:
- The benchmark score improved from 10% to 56% after interfile analysis was added.
Key questions
Q: What breaks when SAST stops at file boundaries?
A: File-boundary scanning breaks when security-relevant behavior is distributed across modules.
Q: Why does interfile analysis improve vulnerability detection?
A: Interfile analysis improves detection because it can connect sources, transformations, and sinks that are separated across files.
Q: What do teams get wrong when they tune SAST rules for simple examples?
A: They often optimise rules for toy cases that look good in demos but do not reflect how real repositories are structured.
Practitioner guidance
- Expand SAST scope beyond single files Validate whether your scanner can follow data from request input to sinks across classes, helper methods, and inherited code paths.
- Benchmark against real vulnerability patterns Use curated cases such as SQL injection and command injection in representative repositories to measure true positives, false positives, and false negatives.
- Separate single-file and interfile rule sets Maintain distinct rules for local matching and cross-file analysis so compensating hacks do not inflate noise when deeper analysis is enabled.
Bottom line: Single-file SAST can leave exploitable code paths invisible when input, transformation, and sink are split across files.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:28 pm
File boundaries are a governance boundary for SAST: once analysis stops at the file level, the control no longer matches how application logic actually executes. The article’s core lesson is that real vulnerabilities often live in relationships between files, not inside isolated files. For practitioners, the relevant question is whether the scanner can follow the code path the attacker would actually use.
A few things that frame the scale:
- Software supply chain attacks were projected to cost organisations $60 billion in 2025.
A question 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. The key questions are whether the engine preserves source-to-sink paths across files, whether false positives stay manageable, and whether developers can understand the rule logic well enough to trust the findings. Coverage without triage quality usually does not scale.
👉 Read our full editorial: Interfile code analysis changes what SAST can catch in practice