{"id":15460,"date":"2026-01-13T11:19:17","date_gmt":"2026-01-13T11:19:17","guid":{"rendered":"https:\/\/newestek.com\/?p=15460"},"modified":"2026-01-13T11:19:17","modified_gmt":"2026-01-13T11:19:17","slug":"for-application-security-sca-sast-dast-and-mast-what-next","status":"publish","type":"post","link":"https:\/\/newestek.com\/?p=15460","title":{"rendered":"For application security: SCA, SAST, DAST and MAST. What next?"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
<\/div>\n<\/section>\n

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 \u201csilver bullet\u201d product; it is a shift toward posture, provenance and proof.<\/p>\n

\n
<\/figure>\n

Sunil Gentyala<\/p>\n<\/div>\n

Over the past year the community has admitted the obvious: the battleground is the software supply chain and the running system, not only pre\u2011release scans. OWASP\u2019s 2025 update elevated software supply chain failures<\/a> to A03, reframing vulnerable and outdated components as a systemic ecosystem risk that spans dependencies, build systems and distribution infrastructure (Endor Labs overview here<\/a>). In parallel, CISA pushed SBOM guidance forward with a 2025 draft that demands richer, machine\u2011readable metadata and emphasizes automation for scale.<\/p>\n

Posture, provenance and proof: The new trinity<\/h2>\n

Application security posture management (ASPM) is the control plane that makes the old quartet useful again. Gartner\u2019s 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.<\/p>\n

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\u2019s 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<\/a>. This aligns with Gartner\u2019s premise but adds practical detail about correlating repository signals, pipeline policies and cloud reality.<\/p>\n

Posture is the \u2018what.\u2019 Provenance is the \u2018how\u2019. The SLSA<\/a> framework gives us a shared vocabulary and verifiable controls to prove that artifacts were built by hardened, tamper\u2011resistant pipelines with signed attestations that downstream consumers can trust (OpenSSF overview here<\/a>). 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.<\/p>\n

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 \u201cingredient lists\u201d to enforceable controls. The CNCF TAG\u2011Security best practices v2 paper<\/a> is my practical map, personas, VEX for exploitability, cryptographic verification to ensure tests actually ran, and prescriptive guidance for cloud\u2011native factories.<\/p>\n

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.<\/p>\n

From dashboards to decisions: ASPM in practice<\/h2>\n

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\u2019s framing makes the case for adoption in regulated environments where fragmented signals undermine remediation velocity.<\/p>\n

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.<\/p>\n

Advisory: Keep one policy source of truth. If security policy lives in three tools, developers will ignore all three.<\/p>\n

Supply chain rigor without theater<\/h2>\n

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. \u00a0SBOMs become operational once they are machine-readable, signed and validated on deploy. CISA\u2019s<\/a> 2025 draft tightened expectations for fields, formats and automation, which I welcome because it makes procurement and incident response faster and cleaner.<\/p>\n

The CNCF paper<\/a> 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.<\/p>\n

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.<\/p>\n

Runtime reality: Instruments, not illusions<\/h2>\n

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.<\/p>\n

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\u20112025\u201120333, CVE\u20112025\u201120362) because agencies reported devices as \u201cpatched\u201d 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\u2011facing ones (CISA press release<\/a>).<\/p>\n

The lesson is portable: treat \u201cpatched\u201d as a state with proofs. Validate minimum release trains, verify fleet\u2011wide and decommission end\u2011of\u2011support gear. Pair perimeter controls with application\u2011layer sensors and container runtime protection because your workloads increasingly live in Kubernetes and managed platforms. Market analyses<\/a> confirm the shift toward orchestrated, cloud\u2011native estates where consistent runtime policy is possible (CNCF trend post here<\/a>).<\/p>\n

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.<\/p>\n

Securing AI and the supply chain ecosystems<\/h2>\n

Among the nexts, AI is the most mercurial. NIST\u2019s 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;<\/a> IBM explainer<\/a>). The U.S. AI Safety Institute published work on agent hijacking evaluations, which I treat as required red\u2011team reading for anyone delegating actions to tools (NIST AISI blog<\/a>).<\/p>\n

For builders, the July 2024 NIST SP 800\u2011218A 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.<\/p>\n

At the language layer an unfashionable recommendation turned mainstream. In June 2025 NSA and CISA urged adoption of memory\u2011safe languages with pragmatic migration guidance for legacy estates\u2014start where it matters most, integrate incrementally and shield old modules behind hardened FFI (NSA\/CISA CSI<\/a>).<\/p>\n

Language choices that erase entire bug classes<\/h2>\n

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.<\/p>\n

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.<\/p>\n

Where SCA, SAST, DAST and MAST fit now<\/h2>\n

They remain foundational when docked into a posture\u2011centric program.<\/p>\n