Semgrep’s taint analysis rewrite shows where scan time was lost

At a glance

What this is: Semgrep's taint analysis rewrite reduces full-scan cost by removing duplicated work and parallelising more of the analysis path.

Why it matters: For security and IAM teams, the finding shows that detection quality at scale depends not just on rules, but on how efficiently analysis engines handle large repositories and noisy long-tail scans.

By the numbers:

• Semgrep says the redesigned taint analysis engine can deliver up to 75% speedups on full scans.
• Semgrep says the 95th percentile of scan times fell from 10 minutes to 7 minutes 30 seconds.
• Semgrep says P99 scan time moved from a noisy about 45 minutes on average to a more consistent 35 minutes.
• Semgrep says the maximum allowable scan time is 12 hours.

Context

Semgrep's article is about static analysis performance, but the governance issue is broader: security engines that repeat work across phases create avoidable latency, operational noise, and trust friction. When scan duration becomes unpredictable, teams struggle to use analysis results as a dependable control in CI/CD, even if the findings themselves remain accurate.

The article also has an identity angle in the wider sense of application security governance. Faster and steadier scans help teams keep policy enforcement close to the development workflow, which matters when code changes affect authentication, authorisation, secrets handling, and the runtime paths that protect human and non-human identities.

Key questions

Q: What breaks when taint analysis work is done twice instead of once?

A: Duplicating taint analysis burns CPU, lengthens scan times, and increases the chance of inconsistent runtime behaviour across large repositories. The bigger issue is that the security control becomes harder to operate predictably, which makes developers less likely to trust or adopt it. Recomputing the same dataflow also creates more places for timing noise and timeout pressure to hide.

Q: Why do P95 and P99 scan times matter more than average speed?

A: Because the averages hide the long tail that most affects large repositories, release pipelines, and user confidence. A tool can look fast on median timings while still producing occasional scans that stall for far too long. P95 and P99 show whether the analysis behaves consistently enough to support real operational use, not just lab benchmarks.

Q: What signals show that a static analysis engine is not scaling well?

A: Frequent timeouts, very noisy max-scan durations, and large gaps between average and tail latency are all warning signs. If a small number of repositories consistently dominate runtime, the engine is probably carrying duplicated work, excessive state, or poor parallelisation. Those symptoms usually mean the design needs structural change, not just tuning.

Q: How should teams govern performance changes in security scanning tools?

A: Treat runtime changes like control changes. Validate them on realistic repositories, compare findings before and after, keep a rollback path, and watch whether the new version reduces tail latency without hiding or reshaping results. The goal is to improve throughput while preserving the integrity of the security signal.

Technical breakdown

Why duplicated taint passes waste scan capacity

Taint analysis tracks how data moves from sources, through propagators, to sinks. In Semgrep's older design, the engine computed taint once, then reconstructed similar work again through an interfile path, which meant the same analysis logic was effectively paying the cost twice. That pattern inflates CPU use, increases queueing on large repositories, and makes tail latency harder to predict. The point is not that taint analysis is inherently slow. The point is that repeated derivation across analysis phases creates a structural performance tax that grows with repository size and rule complexity.

Practical implication: remove duplicated analysis stages before adding more compute or tuning thresholds.

How interfile data flow changes performance pressure

Intra-procedural analysis follows data inside a file, while interfile analysis follows flows across file boundaries by using a naming environment that maps references to definitions. That cross-file step is essential for catching more realistic injection paths, but it also expands the state the engine must carry. Once the analysis had to preserve more context across more code, the earlier two-pass design became a drag on both CPU and memory. OCaml multicore changed the trade-off by making parallel execution more practical without forcing the process-forking model that previously multiplied memory overhead.

Practical implication: treat cross-file analysis as a scalability problem, not only a detection problem.

Why tail latency matters in security scanning

Average scan time hides the behaviour that practitioners feel most. Long-tail metrics such as P95 and P99 show whether the engine is stable enough for large repositories, monorepos, and alerting workflows that depend on consistent runtimes. A system can look acceptable on median timings while still producing a handful of extreme outliers that delay pipelines and create false confidence in operational readiness. Semgrep's emphasis on reduced noise and fewer max-time hits reflects a common security-engine truth: predictability is a control property, not just a performance metric.

Practical implication: measure P95, P99, and timeout frequency before declaring a scanning workflow production-ready.

NHI Mgmt Group analysis

Repeated analysis is a governance problem when it hides inside the control itself. Security teams often treat scan engines as neutral infrastructure, but the article shows that control design can create its own operational debt when the same work is done more than once. That matters because slow or unstable analysis weakens adoption, especially in large codebases where trust in timing is part of trust in the control. The practical conclusion is that control efficiency is part of control effectiveness.

Tail latency is the metric that exposes whether security tooling can survive real-world repositories. Median speed is a poor proxy for operational fit when a small number of repositories dominate developer pain and alerting noise. The article's shift from noisy P99 behaviour to steadier runtime is the kind of change that makes policy enforcement usable at scale. Practitioners should care less about headline speed and more about whether the slowest scans remain inside a manageable operating envelope.

Performance engineering is now part of security governance for code analysis platforms. Once analysis reaches the point where it is used continuously in CI/CD, the question is no longer only whether it finds issues, but whether it can do so consistently enough to support release decisions. In that sense, efficient scan design becomes a prerequisite for keeping application security embedded in delivery rather than external to it. Teams should assess runtime stability as part of tool governance, not as an afterthought.

Cross-file taint analysis is where detection value and operational cost collide. Interfile analysis improves coverage, but it also raises the burden on memory, parallelism, and confidence testing. The article shows the need for a named concept here: analysis duplication debt: the hidden cost created when separate stages recompute similar dataflow work and then hand results back to the same engine. The implication is simple. If duplication is not governed, scale turns it into latency.

For identity security programmes, scan performance is not a side metric. If analysis tools time out or become noisy, teams are slower to catch code paths that affect authentication, authorisation, secret handling, and the interfaces used by service identities. That does not make performance the primary control, but it does make it an enabling condition for reliable governance. The practitioner takeaway is to treat runtime predictability as part of the security operating model.

What this signals

Analysis duplication debt: duplicated work inside security engines becomes a governance issue once scan time affects developer trust and control adoption. Teams should look for repeated computation across analysis stages because that is where latency, noise, and timeout risk accumulate.

For identity and application security programmes, the practical question is whether analysis runs early enough and consistently enough to catch changes that affect authentication, authorisation, and secrets handling before release. If a scanner cannot hold a stable runtime envelope on large codebases, it is not yet a dependable control in the delivery pipeline.

For practitioners

• Measure tail latency, not just averages Track P95, P99, timeout frequency, and max-scan hits for large repositories so you can see whether the analysis engine is stable enough for production use.
• Remove duplicated analysis stages Audit static analysis pipelines for repeated work across passes, especially where interfile and intrafile logic overlap and recompute similar dataflow state.
• Validate changes against real repositories Test engine changes on benchmark and production-like codebases before rollout so that accuracy drift and timeout reduction are measured together.
• Use rollback paths for scan-engine changes Keep a reversible deployment flag or version fallback so teams can restore prior behaviour quickly if runtime gains create analysis differences.

Key takeaways

• Semgrep's rewrite shows that repeated analysis stages can create avoidable cost even when the underlying findings remain the same.
• The most useful evidence is in the tail, where steadier P99 behaviour and fewer timeout hits matter more than average speed alone.
• For practitioners, the lesson is to govern scan engines as operational controls, with validation, rollback, and runtime stability all measured explicitly.

Key terms

• 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.
• 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.
• Tail Latency: Tail latency is the slow end of a system's performance distribution, usually measured with metrics such as P95 or P99. Security teams care about it because the outliers are often the scans, checks, or reviews that block production workflows and erode trust in the control.
• Naming environment: A mapping used by analysis engines to connect references in one file to definitions in another. It lets the engine resolve that a called function in one location is the same function defined elsewhere, which is essential for cross-file dataflow analysis and accurate taint tracking.

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. It is designed for practitioners who need to connect governance, access control, and identity risk to day-to-day security operations.