Topic starter
25/10/2026 11:10 am
TL;DR: Live exploitability still slips past scanners, with Ethiack arguing that BOLA and other production paths need more than static, dynamic or composition checks. SAST, DAST and SCA need a validation layer that shows what attackers can actually reach and chain.
Editorial analysis by NHI Mgmt Group, based on content published by Ethiack: “SAST vs DAST vs SCA: The Comparison for CISOs and AppSec Leads”.
Key questions
Q: Why do SAST and DAST still miss broken object-level authorisation?
A: Because BOLA depends on whether a caller is entitled to a specific object at a specific moment, not just whether code looks unsafe or a live request succeeds.
Q: What are the signs that an AppSec programme is failing despite high scan coverage?
A: A growing backlog, long mean time to remediation, frequent reassignment, and repeated dismissals all indicate the programme is detecting issues faster than teams can close them.
Q: What breaks when SAST, DAST and SCA are used without exploitability validation?
A: Teams get a long list of findings, but they still do not know which issues an attacker can actually reach or chain in production.
Practitioner guidance
- Separate detection from validation Use SAST, DAST and SCA to generate findings, then require a validation step before remediation priority is finalised.
- Prioritise findings by reachability Rank issues that can be reached from a real entry point above findings that exist only as theoretical code or dependency exposure.
- Add access-control validation outside the scanner loop Test authorisation paths and business-logic workflows with adversarial techniques instead of assuming scanner coverage proves access control is sound.
Bottom line: SAST, DAST and SCA each contribute useful coverage, but together they still leave exploitable gaps around live behaviour, attack chaining and access control.
Glossary terms: Static Application Security Testing, Dynamic Application Security Testing, Software Composition Analysis, Reachability analysis
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:15 pm
Scanner coverage is not the same as exploitability coverage. SAST, DAST and SCA each produce findings, but the control gap is whether those findings translate into real attacker reach in the live environment. A programme that treats scan output as proof of risk will mis-rank remediation and overestimate its own assurance. The right governance model is evidence-based prioritisation, not tool counting.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should AppSec teams combine scanner findings with live validation?
A: Use SAST, DAST and SCA to discover weaknesses, then confirm which ones are reachable, chainable and exploitable before assigning remediation priority. The practical goal is a layered workflow where scanners provide breadth and adversarial testing provides proof. That gives developers clearer priorities and gives CISOs defensible evidence for risk decisions.
👉 Read our full editorial: SAST, DAST and SCA still leave exploitability gaps
This post was modified 7 days ago by NHI Mgmt Group