Notifications
Clear all
Topic starter
02/08/2026 11:28 am
TL;DR: A redesigned taint analysis engine in Pro Engine 1.158.0 can speed full scans by up to 75%, cutting the 95th percentile from 10 minutes to 7 minutes 30 seconds and reducing P99 variability, according to Semgrep. The broader lesson is that static analysis at scale fails when the same work is repeated across phases instead of being collapsed into one pass.
NHIMG editorial — based on content published by Semgrep: Semgrep Pro Engine 1.158.0 taint analysis performance improvements
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Semgrep’s analysis of taint analysis performance and scan-time reductions →
Semgrep taint analysis performance gains: what changed for teams?
Explore further
02/08/2026 12:44 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Semgrep’s taint analysis rewrite shows where scan time was lost
