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.
At a glance
What this is: Semgrep’s interfile analysis work shows that single-file SAST misses vulnerabilities when taint, inheritance, and data flow cross file boundaries.
Why it matters: This matters because application security teams that rely on file-scoped rules can miss exploitable paths in code that look safe in isolation but become vulnerable when execution spans multiple files.
By the numbers:
- The benchmark score improved from 10% to 56% after interfile analysis was added.
Context
Single-file static analysis assumes the security-relevant path is visible inside one source file, but modern application code often distributes input, transformations, and sinks across classes and modules. That creates a governance gap for SAST programs, because a rule can be syntactically correct and still miss the actual exploit path once control and data flow leave the file boundary.
For identity and application-security teams, this is a reminder that detection scope is itself a control decision. If your scanning model cannot follow taint through inherited methods, helper calls, and cross-file handoffs, then the programme is measuring local code patterns rather than real exposure. Semgrep’s work shows that the boundary problem is practical, not theoretical.
Key questions
Q: What breaks when SAST stops at file boundaries?
A: File-boundary scanning breaks when security-relevant behavior is distributed across modules. A single file may look clean even though user input, authentication logic, or sanitization is completed elsewhere in the call chain. The practical failure is false negatives on injection, authorization bypass, and business-logic flaws that only exist when the application is viewed as a whole.
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. That lets the engine reason about taint, type information, and constants in a way that single-file scanning cannot. The practical gain is fewer missed vulnerabilities in real codebases where application logic is spread across modules and classes.
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. That can produce either brittle rules or noisy compensations that only work because the engine cannot see far enough. A better approach is to tune against representative vulnerabilities and false positives in production-like code.
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.
Technical breakdown
Why file-scoped SAST misses cross-file data flow
Single-file SAST evaluates one source file at a time, so it can see local syntax but not necessarily the full chain from user input to dangerous sink. That is workable for simple patterns, but it breaks when data is passed through helper methods, inherited methods, aliases, or framework callbacks in another file. In those cases, the analysis may fail to connect the source, transformation, and sink even though the exploit is real. Interfile analysis extends the visible program slice so the engine can follow taint across those boundaries and reason about the whole execution path.
Practical implication: Treat file-scoped rules as incomplete for codebases where business logic is split across classes or services.
Why type inference and constant propagation matter in interfile analysis
Interfile analysis is not just about looking in more files. It depends on understanding what a value is and how it changes, which is where type inference and constant propagation become critical. Type inference helps the engine resolve which method or class is actually involved, while constant propagation tracks values that are assigned once and then reused elsewhere. Without those capabilities, interfile matching either misses real vulnerabilities or becomes noisy. The article shows that practical improvement came from targeting the specific program operations that matter in real repositories, not from trying to solve every theoretical path problem.
Practical implication: Prioritise analysis features that preserve signal on common code patterns before expanding coverage breadth.
Why benchmark design is a security control, not just a product exercise
The article shows that interfile analysis only became useful after the team built a focused benchmark around Java SQL injection, annotated true and false positives, and compared single-file rules with interfile rules. That matters because security tooling often fails when teams optimise for interesting demos instead of representative vulnerabilities. A benchmark turns vague claims about deeper analysis into measurable detection outcomes and exposes where existing rules were compensating for an engine limitation. In other words, product validation doubles as control validation.
Practical implication: Use representative vulnerability benchmarks to decide whether a detection capability actually improves coverage.
Threat narrative
Attacker objective: The attacker wants to turn trusted application data flow into code execution or database compromise through a path the scanner fails to see.
- Entry occurs when user-controlled input enters application code through request parameters and similar sources.
- Escalation happens when that input crosses helper methods or class boundaries and reaches a command or SQL sink without the analysis seeing the full path.
- Impact is exploitable command injection or SQL injection that can execute attacker-controlled actions or access server data.
Breaches seen in the wild
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
- SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Interfile visibility changes the shape of code risk: taint, inheritance, and constant propagation are not academic extras when they determine whether a dangerous value reaches a sink. This is a practical example of detection fidelity, where more context does not just reduce false negatives, it changes which vulnerabilities are even visible to the programme. Teams should treat interfile capability as part of the control design, not a nice-to-have enhancement.
Benchmark-driven tuning is the right way to reduce false confidence: the article shows that representative vulnerabilities and false positives gave the team a better basis for engineering decisions than user wish lists alone. That is the correct approach for security tooling that must operate in real CI pipelines. For practitioners, detection quality should be validated against known exploit classes, not inferred from feature claims.
Code security debt accumulates when tools are built around narrow defaults: one-file analysis is simpler to operate, but it can institutionalise blind spots if teams never revisit the underlying assumption. The named concept here is analysis scope debt, the gap between how code really flows and what the control can see. Practitioners should treat that debt as a measurable risk in their application security programme.
Interfile analysis reinforces the value of secure defaults only when the defaults reflect real program structure: safe patterns such as catching obviously dangerous sinks are useful, but they do not replace cross-file reasoning in modern applications. This means the SAST roadmap should be judged by whether it matches the architecture of the codebase, not by whether it preserves a simpler scanning model. Teams need controls that match their software topology, not just their rule library.
From our research library:
- Software supply chain attacks were projected to cost organisations $60 billion in 2025.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Analysis scope debt: security programmes accumulate this debt when scanners are configured around convenient boundaries instead of real code flow. Once that happens, the tool can certify file-local safety while missing the cross-file path an attacker would actually use. The fix is not more rules alone, but a control model that matches application topology and execution context.
Interfile SAST also changes how teams should think about developer trust. When the scanner can explain why a cross-file path is vulnerable, security engineers can tune checks with developers instead of forcing opaque exceptions, which improves both adoption and signal quality. That makes detection coverage and developer workflow part of the same governance decision.
For practitioners
- 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.
- Prioritise the languages and frameworks that carry the most risk Focus interfile enablement on the stacks where business logic is split across files and the most exploitable paths are likely to appear.
Key takeaways
- Single-file SAST can leave exploitable code paths invisible when input, transformation, and sink are split across files.
- The article’s benchmark work shows that interfile analysis can materially improve detection quality when the code model matches real repository structure.
- Application security teams should validate scanner scope against real vulnerability paths, not against the convenience of local-only rules.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Cross-file analysis gaps behave like a tooling misconfiguration that hides real attack paths. |
| Recommendation — Review scanner configuration and rule scope so cross-file paths are not missed by default. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The article centres on how analysis scope must match application architecture to catch injection paths. |
| Recommendation — Align verification coverage with the way code is actually structured across files and modules. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is about improving application security testing effectiveness in the SDLC. |
| Recommendation — Use application security testing controls to validate that SAST finds real vulnerabilities, not just local patterns. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The exploit patterns discussed can support post-compromise command execution and lateral movement paths. |
| Recommendation — Map injection findings to attacker tactics so detections cover the downstream abuse chain. | ||
Key terms
- Inter-File Analysis: Inter-file analysis follows code relationships across file boundaries instead of staying inside a single source file. It improves coverage because many real vulnerabilities cross boundaries, but it also increases the context the engine must preserve and can create performance pressure if implemented with redundant passes.
- Taint Analysis: A method for tracking untrusted data as it moves through a system until it reaches a sensitive operation. In agentic environments, it helps security teams see when external content can influence tool selection, code changes, or other privileged actions that should not have been reachable from that input.
- Reset Propagation: The process by which a password change is applied to every system that trusts the credential. In hybrid IAM, propagation is often asynchronous and uneven, so practitioners must validate where the new state lands and where stale access may remain.
- False Positive: A false positive is a scanner result that looks like a secret but is not actually sensitive. In secret governance, false positives matter because they consume analyst time, weaken trust in alerts, and can delay response to the findings that truly change exposure and access risk.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Build stronger governance for the identity and access decisions that shape your broader security programme.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org