I have stared at enough scanner dashboards to recognize the pattern. SAST flags theoretical flaws that never execute. DAST shrugs because the route to the vulnerable function is blocked. SCA floods the zone with CVEs that never touch a hot path. MAST scolds my mobile app for secrets I retired last quarter. These tools are still essential, yet they now form a baseline rather than a destination. The next chapter is not another “silver bullet” product; it is a shift toward posture, provenance and proof.
Sunil Gentyala
Over the past year the community has admitted the obvious: the battleground is the software supply chain and the running system, not only pre‑release scans. OWASP’s 2025 update elevated software supply chain failures to A03, reframing vulnerable and outdated components as a systemic ecosystem risk that spans dependencies, build systems and distribution infrastructure (Endor Labs overview here). In parallel, CISA pushed SBOM guidance forward with a 2025 draft that demands richer, machine‑readable metadata and emphasizes automation for scale.
Posture, provenance and proof: The new trinity
Application security posture management (ASPM) is the control plane that makes the old quartet useful again. Gartner’s 2025 Innovation Insight described how ASPM connects scattered signals across the SDLC, enforces policy and prioritizes based on context, such as reachability and exposure in practice, which means pulling SAST, DAST, SCA, IaC and runtime findings into a single view, then filtering for the small subset that really matters.
I prefer framing ASPM through a code to cloud lens because it mirrors how our systems actually work. The Wiz Academy guide lays out ASPM’s core capabilities, unified visibility, risk prioritization, policy enforcement and stresses continuous discovery across development, build and deployment. The goal is to cut alert fatigue while connecting code issues to runtime impact ASPM. This aligns with Gartner’s premise but adds practical detail about correlating repository signals, pipeline policies and cloud reality.
Posture is the ‘what.’ Provenance is the ‘how’. The SLSA framework gives us a shared vocabulary and verifiable controls to prove that artifacts were built by hardened, tamper‑resistant pipelines with signed attestations that downstream consumers can trust (OpenSSF overview here). When I insist on SLSA Level 2 for most services and Level 3 for critical paths, I am not chasing compliance theater; I am buying integrity that survives audit and incident.
Proof is where SBOMs finally grow up. Binding SBOM generation to the build that emits the deployable bits, signing them and validating at deploy time moves SBOMs from “ingredient lists” to enforceable controls. The CNCF TAG‑Security best practices v2 paper is my practical map, personas, VEX for exploitability, cryptographic verification to ensure tests actually ran, and prescriptive guidance for cloud‑native factories.
Advisory: if your SBOM describes developer intent rather than what executes, you will miss the next recall. Generate SBOMs from the build that produced the binary, sign them, ingest VEX and gate deployments on verification.
From dashboards to decisions: ASPM in practice
A posture program is a set of habits, not just a platform. I start by unifying scanner outputs into a single risk register, but I refuse to triage in a vacuum. Findings must carry reachability evidence, data sensitivity tags and exposure context. That is where ASPM earns its keep. The Wiz Academy material underscores this code to cloud connection and shows how to reduce noise so developers see the few issues that block business rather than a wall of theoretical risk. Gartner’s framing makes the case for adoption in regulated environments where fragmented signals undermine remediation velocity.
Two implementation notes from my own programs. First, wire ASPM to owners. Every finding needs a resolver and an SLA, or it is just a report. Second, gate risky builds. Policy enforcement is not a dashboard; it is a decision. If an artifact lacks provenance or a VEX shows exploitability in a reachable path, it does not ship.
Advisory: Keep one policy source of truth. If security policy lives in three tools, developers will ignore all three.
Supply chain rigor without theater
Supply chain work can degrade into paperwork if we forget what matters. Integrity is the point. I keep SLSA simple. Level 2 quickly, Level 3 for critical paths. That means a hardened build service, isolated builds, signed provenance and a verified chain from source to artifact. SBOMs become operational once they are machine-readable, signed and validated on deploy. CISA’s 2025 draft tightened expectations for fields, formats and automation, which I welcome because it makes procurement and incident response faster and cleaner.
The CNCF paper fills in the gaps. It explains how to couple SBOMs with VEX, add cryptographic checks for pipeline steps, and treat developer infrastructure as part of the supply chain. That last point matters because attackers increasingly target repositories, CI settings and artifact registries, not just code dependencies. Public sector guidance from CNCF echoes the same priorities for government workloads, with concrete lessons from SolarWinds, Log4Shell and xz.
Advisory: never accept a vendor SBOM without a signature and a provenance attestation. If they cannot prove how the software was built, your risk calculus is guesswork.
Runtime reality: Instruments, not illusions
Prerelease testing is necessary but not sufficient. IAST instrumentation gives me runtime truth during QA, observing actual execution paths to reduce false positives and preserve developer context. In production, the mental model shifts to RASP, which blocks exploitation inside the application at the exact moment risky operations occur: SQL construction, OS exec, serialization, where WAFs cannot see. This is not a knock on WAFs; it is a recognition that network layer inspection and application layer introspection solve different problems.
If you think perimeter controls are enough, two weeks in November 2025 should dispel that. CISA issued emergency guidance for Cisco ASA and FTD vulnerabilities (CVE‑2025‑20333, CVE‑2025‑20362) because agencies reported devices as “patched” that were still on vulnerable trains. The directive prescribed minimum versions, forensic checks and timelines, and reminded everyone that all devices must be updated, not only Internet‑facing ones (CISA press release).
The lesson is portable: treat “patched” as a state with proofs. Validate minimum release trains, verify fleet‑wide and decommission end‑of‑support gear. Pair perimeter controls with application‑layer sensors and container runtime protection because your workloads increasingly live in Kubernetes and managed platforms. Market analyses confirm the shift toward orchestrated, cloud‑native estates where consistent runtime policy is possible (CNCF trend post here).
Advisory: wire runtime telemetry to your TDIR practice. When RASP blocks an injection in production, that event should spawn code fixes, not just a closed alert.
Securing AI and the supply chain ecosystems
Among the nexts, AI is the most mercurial. NIST’s final 2025 guidance on adversarial ML split threats across PredAI and GenAI and called out prompt injection in direct and indirect form as the dominant exploit in agentic systems where trusted instructions co mingle with untrusted data (Meritak Overview; IBM explainer). The U.S. AI Safety Institute published work on agent hijacking evaluations, which I treat as required red‑team reading for anyone delegating actions to tools (NIST AISI blog).
For builders, the July 2024 NIST SP 800‑218A community profile extends SSDF into generative AI and dual-use foundation models. It covers threat modeling prompts, securing training data pipelines, isolating model operations and binding model documentation to secure development practices.
At the language layer an unfashionable recommendation turned mainstream. In June 2025 NSA and CISA urged adoption of memory‑safe languages with pragmatic migration guidance for legacy estates—start where it matters most, integrate incrementally and shield old modules behind hardened FFI (NSA/CISA CSI).
Language choices that erase entire bug classes
If you want to delete vulnerability classes, stop writing them. In June 2025, NSA and CISA published a joint CSI urging adoption of memory-safe languages with pragmatic migration guidance for legacy estates. Start where it matters, integrate incrementally and shield old modules behind hardened FFI. This is not academic posturing. Buffer overflows, use after free and data races erode resilience and cost real money. Memory-safe languages reduce those risks by design.
Advisory: mandate memory-safe languages for net new development, plan migrations for high-risk modules and publish a runway with dates and metrics. Explain the why using NSA and CISA guidance, then measure the results.
Where SCA, SAST, DAST and MAST fit now
They remain foundational when docked into a posture‑centric program.
SAST still catches design and implementation flaws, but I insist on reachability analysis and developer‑first remediation inside the IDE; feed SAST into ASPM for context so theoretical issues do not overwhelm real ones.
DAST is indispensable for pre‑release exposure, yet I pair it with IAST to observe live code paths and reduce false positives.
SCA moves beyond CVE lists when SBOM generation binds to builds and VEX cuts noise; CNCF best practices and CISA’s 2025 SBOM draft describe how to do this well.
MAST keeps mobile hardening honest, but I roll secret hygiene and secure storage checks into the same lifecycle controls used for server apps.
Leadership advisory: what I implement next
This is the operating model I have shipped in regulated environments that cannot afford to be wrong.
ASPM as control plane. Unify signals, deduplicate and rank by exploitability—reachability, exposure, data sensitivity. Route ownership automatically and use policy gates on risky builds.
Supply chain rigor. Adopt SLSA levels, require signed SBOMs and attestations, and validate at deploy. No artifact without provenance, no deploy without verification.
Runtime protection. Embed RASP in application stacks, enforce container runtime controls and keep WAF at the edge. Wire events to your TDIR pipeline so blocking in production triggers fixes in code.
Secrets lifecycle and machine identities. Central vaulting, automated rotation, least privilege everywhere, mutual TLS for service‑to‑service authentication.
AI security program. Adopt NIST SP 800‑218A, red‑team agents for hijacking, enforce privilege separation and monitor outputs.
Language policy. Mandate memory‑safe languages for net‑new development, plan migrations for high‑risk modules and use NSA/CISA’s guidance to educate stakeholders.
Conclusion
SCA, SAST, DAST and MAST remain the bedrock, but they are most effective when orchestrated by ASPM, proven by SLSA and SBOMs, and defended by runtime controls. Add AI-specific safeguards and memory‑safe languages, and you move from chasing findings to making decisions with confidence. That is my “what next.”
This article is published as part of the Foundry Expert Contributor Network.
Want to join?
No Responses