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

At a glance

What this is: Semgrep redesigned its taint analysis engine to remove duplicated work and materially reduce full scan time and variability.

Why it matters: This matters to IAM and security teams because the same pattern appears in policy engines, code scanning, and identity controls when repeated evaluation becomes the bottleneck rather than the protection itself.

By the numbers:

• Semgrep says its redesigned taint analysis engine can deliver up to 75% speedups on full scans.
• The 95th percentile of Semgrep scan times went from 10 minutes to 7 minutes 30 seconds.
• The P99 scan time moved from a noisy 45 minutes on average to a more consistent 35 minutes.

👉 Read Semgrep’s analysis of taint analysis performance and scan-time reductions

Context

Static analysis slows down when the engine repeats expensive dataflow work across passes, files, or environments. In this case, the primary issue was not detection quality but analysis overhead, which is a familiar governance problem anywhere security tooling must process large codebases at production speed.

For identity programmes, the parallel is straightforward: control logic that is correct but inefficient eventually gets bypassed, delayed, or underused. Whether the workload is code scanning, entitlement review, or NHI governance, the operational question is whether the control can run once, run fast, and still preserve trust in the result.

Key questions

Q: What breaks when a security control recomputes the same state twice?

A: Repeated computation usually creates latency, higher resource use, and more timeout risk without improving decision quality. In practice, that means controls become harder to trust at scale and more likely to be bypassed or delayed. The fix is not just optimisation. Teams should remove duplicated inference, preserve shared context, and measure whether the control remains stable on the largest workloads.

Q: Why do large security analyses need more than average performance metrics?

A: Averages hide the long tail, which is where the operational pain usually lives. Security teams care about the slowest scans, access reviews, or policy checks because those are the ones that block delivery and create user frustration. P95 and P99 metrics show whether the control is predictable enough to be dependable, especially in large or complex environments.

Q: How can teams tell whether a security engine is actually scaling well?

A: Look for lower timeout rates, tighter variance, and consistent execution on large or complex datasets. If performance gains only appear on small samples, the architecture may still collapse under real production load. A control scales well when it keeps fidelity while reducing repeated work and remains stable as workload size increases.

Q: What should teams do when security tooling becomes too slow to trust?

A: Prioritise the slowest and most business-critical paths first, then redesign the workflow so expensive checks happen once instead of repeatedly. Use shadow testing to compare output stability, and keep a rollback path available until the new design proves reliable. If the slowdown is systemic, treat it as a control architecture problem, not a tuning exercise.

Technical breakdown

Why taint analysis became the dominant cost

Taint analysis tracks how untrusted data moves through a program from source to sink. In Semgrep’s earlier design, that work was repeated across intra-file and inter-file paths, which meant the engine spent significant CPU time recomputing relationships it already understood. That approach improves coverage, but it also creates a scaling problem when repository size, rule depth, and scan volume increase together. The engineering challenge was not the logic of taint analysis itself, but the cost of re-running it in multiple forms. Practical implication: identify security checks that repeat the same inference work and treat duplication as a performance defect, not just an implementation detail.

Practical implication: identify security checks that repeat the same inference work and treat duplication as a performance defect, not just an implementation detail.

How inter-file taint analysis changes the execution model

Inter-file analysis extends taint tracking across file boundaries by maintaining a naming environment that links function references to their definitions. That allows the engine to resolve flows that would be invisible in a single-file pass, but it also increases the amount of state that must be carried through the pipeline. Semgrep’s earlier workaround was to compute taint signatures and then feed them back into intrafile logic, effectively preserving correctness at the cost of duplicated computation. The redesign collapses those stages so the flow is computed once and reused. Practical implication: when a security control needs cross-boundary context, design the architecture so context is preserved without forcing a second evaluation loop.

Practical implication: when a security control needs cross-boundary context, design the architecture so context is preserved without forcing a second evaluation loop.

Why multicore support made the rewrite viable

Before OCaml 5.0, parallel execution often meant forking processes, which multiplied memory usage and made large analysis workloads harder to sustain. Once multicore execution became practical, the engine could distribute work without duplicating the full in-memory context for every process. That mattered because the once-only taint design still needed to combine parsing, configuration, and dataflow checks at scale. The performance gain came from both eliminating redundant passes and making the remaining work parallelisable. Practical implication: optimisation efforts should be paired with runtime architecture changes, because software that cannot parallelise usually turns every governance scale-up into a cost problem.

Practical implication: optimisation efforts should be paired with runtime architecture changes, because software that cannot parallelise usually turns every governance scale-up into a cost problem.

NHI Mgmt Group analysis

Repeated evaluation is a governance smell, not just an engineering smell. Semgrep’s performance problem came from doing taint analysis twice, which is a useful reminder that control systems often accumulate hidden duplication as they evolve. In identity security, the same pattern shows up when access is re-validated, re-enriched, and re-checked across tools without a single source of truth. The result is latency, inconsistency, and lower operational trust. Practitioners should treat redundant evaluation paths as a control-design issue, not merely a tuning issue.

Cross-boundary security checks only scale when the architecture preserves context cleanly. The article’s inter-file analysis problem mirrors a broader identity challenge: controls that depend on relationships across systems are expensive if every boundary crossing forces a fresh computation. That is true for code analysis, entitlement review, and machine identity governance alike. The architecture has to preserve context without turning every check into a replay of the previous one. Practitioners should look for repeated inference loops anywhere the control plane spans many objects or repositories.

Performance noise is itself a security governance problem. Semgrep’s focus on reducing P99 variability matters because unstable scan times make alerting, triage, and rollout decisions harder. A control that is technically accurate but operationally unpredictable becomes difficult to trust at scale. Detection-response latency: the longer a tool spends reprocessing the same state, the more it behaves like a batch job instead of a security control. Practitioners should measure consistency, not just average speed, when evaluating controls that sit in the security pipeline.

Static analysis teams are moving from correctness-first to throughput-aware design. That shift matters because security tooling increasingly lives inside delivery workflows, where delay has a direct adoption cost. The lesson extends beyond code scanning into IAM and NHI programmes: if a governance control is too slow, teams will route around it. Practitioners should prefer controls that reduce state duplication, limit timeout risk, and keep large environments inside predictable operating bounds.

The real lesson is that security tooling now has to behave like production infrastructure. Semgrep’s improvements were validated with profiling, benchmarks, and shadowed production scans, which is the right pattern for any control that can affect developer output or enforcement reliability. For identity and access programmes, the same discipline should apply to policy engines, access reviews, and automated remediation paths. Practitioners should demand observable performance evidence before rolling controls into critical paths.

What this signals

Control latency will increasingly be treated as a governance risk. When security analysis becomes slow or noisy, teams lose confidence in the control and start tolerating exceptions that should have been closed. For identity programmes, the same pattern affects access reviews, secrets workflows, and NHI governance. The practical signal is simple: if the control cannot keep up with the environment, it will eventually stop shaping behaviour.

Throughput-aware security design is becoming a baseline expectation. Tools that process large codebases, entitlement graphs, or workload identities now need predictable tail performance, not just nominal speed. That is why performance evidence matters alongside functional correctness, especially where detection or enforcement sits inside delivery pipelines. Teams should expect stronger scrutiny of timeout rates, variance, and rollback readiness before adopting new control logic.

Detection-response latency: the distance between a security event and a trustworthy decision is now a measurable design constraint. For identity and secrets programmes, that means building controls that can operate once, preserve context, and remain auditable under load. The more predictable the control, the less likely the organisation is to create hidden exception paths.

For practitioners

• Eliminate duplicated evaluation paths Map any control that computes the same state more than once, then collapse those stages into a single authoritative pass where possible. This is especially important for code scanning, entitlement analytics, and policy engines that depend on cross-boundary context.
• Measure P95 and P99, not just averages Track scan or policy execution consistency across large repositories and high-complexity workflows, because the long tail is what usually breaks trust in the control. Use P99 alerts to catch timeout drift before users route around the process.
• Validate changes with shadow traffic Run new control logic against production-like workloads in shadow mode so you can compare speed, result stability, and timeout rates before rollout. That reduces the risk of improving throughput at the expense of control fidelity.
• Treat parallelisation as a control design choice If the control plane must process many objects or files, ensure the architecture can parallelise without multiplying memory overhead or reintroducing redundant state. Otherwise, scale will turn into a latency and cost problem.

Key takeaways

• Semgrep’s rewrite is a reminder that duplicated security work becomes a scaling problem long before it becomes a functional bug.
• Tail latency matters because slow, noisy controls are the ones teams distrust, defer, or work around in production.
• Security programmes should optimise for single-pass evaluation, predictable execution, and measurable stability across real workloads.

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.
• Shadow execution: Shadow execution is software activity that occurs on a device outside the monitoring paths a security team uses to prove ownership, approval, or accountability. The application may be known in name, but the runtime behaviour and identity evidence are not visible enough for dependable governance.

What's in the full article

Semgrep's full blog post covers the implementation detail this post intentionally leaves for the source:

• The code-level refactor that moved taint analysis from a two-pass model to a single-pass design.
• The profiling and benchmark approach used to verify where CPU time was being spent before rollout.
• The shadow-production experiment that compared analysis results and timeout behaviour on live user workloads.
• The repository traces showing how specific large codebases benefited from the redesign.

👉 Semgrep’s full post covers the profiling method, benchmark results, and repository-level performance traces.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build the control discipline needed to keep identity programmes dependable at scale.