Notifications
Clear all
Topic starter
06/09/2026 5:18 pm
TL;DR: Static Application Security Testing is now embedded in most development pipelines, but LEVO's analysis shows the control still leaves major blind spots around runtime behaviour, APIs, and false positives. The lesson is that shift-left coverage only reduces risk when it is paired with validation that reflects how applications are actually used.
NHIMG editorial — based on content published by LEVO: why SAST tools are important and where they fall short
By the numbers:
- Recent application security research shows that 8 of the top 10 data breaches in 2023 were driven by application attack surfaces.
- 85% of developers now integrate SAST during the, during the coding phase.
Questions worth separating out
Q: How should security teams use SAST without treating it as full application coverage?
A: Use SAST as an early detection layer for code defects, then validate the same flows with runtime testing, API checks, and telemetry.
Q: Why do SAST findings often overwhelm developer teams?
A: They overwhelm teams when tools flag too many low-confidence issues, duplicate findings across scans, or code patterns that are not exploitable in context.
Q: What happens when organisations rely on SAST alone for modern application security?
A: They miss runtime defects, API abuse, and authorisation failures that only appear in live workflows.
Practitioner guidance
- Align SAST with exploitable risk Prioritise findings that can be tied to reachable code paths, exposed inputs, or sensitive data flows instead of treating every match as equally urgent.
- Pair code scanning with runtime validation Add API testing, authentication checks, and runtime telemetry so security teams can confirm whether the issue still exists after deployment.
- Reduce noise through rule governance Tune rulesets, document suppression decisions, and review false-positive rates regularly so developers retain confidence in the programme.
What's in the full article
LEVO's full analysis covers the operational detail this post intentionally leaves for the source:
- A feature-by-feature walkthrough of the SAST tools discussed in the article and how they differ in developer workflow fit.
- Detailed guidance on how the vendor evaluates false positives, CI/CD integration, and remediation ergonomics.
- Practical comparisons of enterprise deployment considerations such as scale, reporting, and policy tuning.
- The full tool landscape assessment for teams choosing between developer-friendly and enterprise-focused SAST approaches.
👉 Read LEVO's analysis of why SAST alone is not enough for modern application security →
SAST limitations in DevSecOps: what practitioners need to re-evaluate?
Explore further
06/09/2026 5:19 pm
SAST is a code quality control, not an identity governance control. It can flag insecure patterns in source code, but it cannot govern how credentials, tokens, and access decisions behave once software is running. That distinction matters in applications where identity and authorisation are implemented through APIs and services. Practitioners should use SAST as one input to secure development, not as evidence that identity risk is controlled.
A question worth separating out:
Q: How can teams tell whether their SAST programme is actually working?
A: Look for reduced false-positive churn, faster remediation on high-confidence issues, and consistent developer adoption across repos and teams. If engineers ignore findings, suppress everything by default, or route issues outside the normal delivery process, the programme is not working. Effective SAST changes behaviour, not just dashboards.
👉 Read our full editorial: SAST is not enough for modern application security
