Notifications
Clear all
Topic starter
22/06/2026 9:51 am
TL;DR: Application security testing spans threat modeling, SAST, SCA, DAST, and IAST, but findings only become actionable when teams add cloud, IAM, and runtime context to separate theoretical defects from exposures that can actually be reached, according to Orca Security. Static checks alone do not resolve production risk; governance must connect code, infrastructure, and identity.
NHIMG editorial — based on content published by Orca Security: application security testing in cloud environments
Questions worth separating out
Q: How should security teams prioritise application security testing findings?
A: Prioritise by combining defect severity, exploitability, cloud exposure, identity reach, and data sensitivity.
Q: Why do cloud environments change application security testing results?
A: Cloud environments add permissions, public exposure, secrets, and cross-account paths that code-only testing cannot see.
Q: What do teams get wrong about SAST and SCA?
A: They often treat SAST and SCA as a complete risk picture when they are really early signals.
Practitioner guidance
- Map AST findings to runtime exposure Join code findings to cloud context, public exposure, and identity permissions before assigning remediation priority.
- Version threat models with architecture changes Revisit data flows when you add APIs, federation, new service accounts, or cloud integrations.
- Triage dependency risk with ownership and reachability Require SBOM-backed SCA results to identify which package is actually shipped and whether the vulnerable path is reachable in production.
What's in the full article
Orca Security's full article covers the operational detail this post intentionally leaves for the source:
- The article walks through SAST, SCA, DAST, and IAST in more depth, including where each fits in the development lifecycle.
- It explains how cloud context changes AST prioritisation when the same defect exists in multiple environments but only one is exposed.
- It outlines how Orca's cloud risk view relates code findings to IAM permissions, public exposure, and attack paths across AWS, Azure, and GCP.
- It includes FAQ-level guidance on AST frequency, metrics, and the difference between application security testing and penetration testing.
👉 Read Orca Security's analysis of application security testing in cloud environments →
Application security testing in cloud environments: are your controls enough?
Explore further
22/06/2026 10:29 am
Cloud context is now part of application security testing, not an optional add-on. AST has always found defects in code and dependencies, but those findings do not become risk until they are mapped to exposure, permissions, and reachable paths. The article correctly pushes teams to ask whether a vulnerability sits on an internet-facing workload, a privileged identity path, or an isolated build system. Practitioners should treat exposure context as the deciding layer, not a reporting enhancement.
A few things that frame the scale:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments.
A question worth separating out:
Q: How do teams know if an AST programme is working?
A: A mature AST programme reduces repeat findings, shortens remediation time, blocks critical issues before release, and aligns scanner results with actual incidents. If the programme produces many findings that never map to exposure or real exploit paths, it may be generating noise instead of governance value.
👉 Read our full editorial: Application security testing needs cloud context to reduce real risk
