Notifications
Clear all
Topic starter
21/08/2026 4:44 pm
TL;DR: DAST findings often lack enough runtime context to show which issues are actually exploitable in production, and Xygeni says its ASPM engine correlates dynamic results with static and asset signals to reduce noise and improve prioritisation. The practical shift is from assumption-based triage to evidence-based exposure analysis, which matters because unresolved alert fatigue slows remediation and hides real risk.
NHIMG editorial — based on content published by Xygeni: DAST and ASPM in continuous delivery environments
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams prioritise DAST findings in production applications?
A: Prioritise DAST findings only after adding runtime context such as exposure, authentication requirements, and asset criticality.
Q: Why do DAST and static analysis need to be combined in AppSec programmes?
A: Static analysis identifies issues in code, but it cannot confirm whether those issues are reachable in the deployed environment.
Q: What do security teams get wrong about runtime penetration testing?
A: They often focus on what the model can find and ignore what the model is allowed to do.
Practitioner guidance
- Correlate DAST with asset criticality Require every dynamic finding to be enriched with environment, exposure, and business-value metadata before it enters the remediation queue.
- Add reachability checks to triage Filter findings by internet exposure, authentication state, and route reachability before assigning engineering work.
- Separate scanner output from risk decisions Treat DAST as one signal in ASPM, not as a standalone severity list.
What's in the full article
Xygeni's full article covers the operational detail this post intentionally leaves for the source:
- Exact ingestion flow for DAST outputs from tools such as OWASP ZAP and Acunetix 360 into ASPM correlation logic
- Stepwise examples of how the exposure funnel filters issues from all findings to internet-exposed and unauthenticated paths
- Implementation detail on how runtime findings are enriched with SAST, SCA, and configuration context before prioritisation
- Practical explanation of how teams can use the model to reduce false positives without losing exploitability evidence
👉 Read Xygeni's analysis of runtime-aware DAST and ASPM prioritisation →
DAST and ASPM together: are your runtime findings keeping up?
Explore further
21/08/2026 5:04 pm
Runtime exposure, not vulnerability count, should drive AppSec decisions. DAST creates evidence about how an application behaves under attack conditions, but the number of findings alone says little about actual risk. Once those findings are correlated with exposure and asset context, teams can tell the difference between a theoretical issue and a route into production systems. That is the governance shift AppSec programmes need: prioritisation based on exploitability evidence, not on scanner volume. The practitioner conclusion is straightforward. Evidence of reachability should outrank raw finding counts.
A question worth separating out:
Q: Who should own remediation when a DAST finding reveals exposed application paths?
A: Ownership should sit with the application team, but AppSec, IAM, and platform owners may all need to participate if the issue involves secrets, authentication, or access controls. The right response is to assign remediation based on the control that failed, not only on where the scanner discovered the issue.
👉 Read our full editorial: Runtime-aware DAST and ASPM are closing AppSec prioritization gaps
