Application security posture management is replacing fragmented AST

At a glance

What this is: OXSecurity argues that fragmented application security testing is giving way to Application Security Posture Management because modern SDLC complexity, cloud adoption and third-party dependencies require continuous governance.

Why it matters: This matters to IAM and security practitioners because software delivery now depends on trusted identities, pipeline access and dependency control, which means application risk management increasingly overlaps with NHI, secrets and supply chain governance.

By the numbers:

• Between 40-80% of code in new software projects comes from third parties, according to OXSecurity.
• More than 40% of code in new software projects comes from third parties, according to OXSecurity.

Context

Application security posture management is a governance shift, not just another scanning layer. Traditional AST struggles when development moves faster than point-in-time checks, when third-party code dominates the codebase, and when cloud delivery turns applications into moving targets. The identity angle is real here because build pipelines, developer workflows and dependency trust all depend on credentials, permissions and machine identities.

Fragmented tooling creates blind spots because no single control plane can explain how code, pipeline and runtime risks connect. In that environment, posture management becomes the practical response: continuous visibility, policy enforcement and contextual prioritisation across the SDLC. For application teams, this is increasingly the difference between owning risk and merely finding it after the fact.

Key questions

Q: What breaks when application security relies on fragmented AST tools?

A: Fragmented AST breaks when teams need continuous governance rather than isolated scans. It leaves gaps between code, pipeline and runtime, so risk can move faster than review cycles and the organisation only learns about exposure after changes are already in motion. That makes prioritisation, not just detection, the real control problem.

Q: Why does third-party code make posture-based AppSec more important?

A: Third-party code expands the trusted surface beyond what internal teams directly build or review. Once dependencies account for a large share of the codebase, security has to understand provenance, update paths and exploitability, not only local code defects. Posture-based AppSec matters because it connects inherited risk to actual delivery and runtime impact.

Q: How can security teams tell whether Application Security Posture Management is working?

A: ASPM is working when teams can explain which issues matter, why they matter and where they sit in the delivery chain. Good posture management reduces false urgency, correlates findings across code and pipelines, and shows whether a vulnerability is reachable or simply present. The test is whether decisions get faster and more defensible.

Q: What should teams do when developer-owned security meets cloud delivery complexity?

A: Teams should formalise shared ownership without assuming developers can absorb every control manually. That means embedding security into workflows, governing machine identities used in delivery, and using posture data to focus attention on the few issues that truly increase blast radius. The aim is secure speed, not security as a separate gate.

Technical breakdown

Why traditional AST breaks down in continuous delivery

Traditional application security testing is built around discrete scans and report cycles. That model works poorly when code changes daily, pipelines are automated and cloud deployments can shift faster than manual review queues. The result is not simply more findings, but a governance gap where risk is discovered out of phase with delivery. AST also tends to optimise for vulnerability enumeration rather than operational context, so teams get lists of issues without understanding how code, dependency and pipeline trust combine into exploit paths.

Practical implication: security teams need control coverage that follows the delivery flow, not a separate scan artefact at the end of it.

How ASPM changes the control model across code, pipelines and runtime

Application Security Posture Management extends AppSec from testing to continuous posture oversight. It pulls together monitoring, vulnerability management, threat detection and compliance enforcement so teams can see how issues relate across the software lifecycle. That matters because modern application risk is rarely confined to a single flaw. The exposure often comes from the interaction between code quality, dependency trust, build integrity and live runtime behaviour. In identity terms, this also means pipeline access, service credentials and machine identities become part of the AppSec control surface, not a separate concern.

Practical implication: practitioners should govern application risk as a lifecycle control problem, with identity and dependency trust built into the same operating model.

Why software supply chain security belongs inside AppSec governance

The article’s supply chain point is decisive: third-party packages, open-source libraries and inherited build inputs now form a large portion of application risk. Software supply chain security brings visibility into what software is made of and how it was produced, while tools such as SBOMs and PBOMs help teams trace components and build lineage. That is more than inventory. It creates the evidentiary layer needed to prioritise exploitability, understand provenance and stop assuming that internally built software is inherently trusted.

Practical implication: teams should treat dependency provenance and build lineage as core AppSec controls, not as separate compliance artefacts.

Threat narrative

Attacker objective: The attacker objective is to introduce or weaponise trusted software paths so malicious code, compromised dependencies or unsafe changes reach production.

1. Entry often begins through trusted third-party code or a compromised development workflow that bypasses the assumptions of point-in-time AST.
2. Credential or pipeline misuse then allows malicious changes, vulnerable dependencies or build tampering to move through the SDLC with legitimacy.
3. The impact is application compromise, delayed detection and wider supply chain exposure because fragmented controls cannot correlate the attack path across code, build and runtime.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

ASPM is becoming the control plane for application risk because AppSec has outgrown scan-centric thinking. Point-in-time AST can still find defects, but it cannot govern the relationships between code, pipeline and runtime that now define exposure. The more software delivery is automated, the more security has to operate continuously rather than episodically. Practitioners should treat posture management as a lifecycle control model, not a reporting layer.

Pipeline identity is now an AppSec issue, not just a DevOps implementation detail. When developers own more security tasks and automation moves faster than review, the identities used by pipelines, build systems and deployment jobs become part of the attack surface. That creates a direct bridge between application security and NHI governance, especially where secrets, tokens and service credentials are the real enforcement boundary. Practitioners should govern machine access with the same seriousness they apply to application vulnerabilities.

Software supply chain security is no longer a companion discipline to AppSec, it is a prerequisite for it. A posture model that ignores third-party components, build lineage and dependency trust will systematically understate risk. The article’s emphasis on SBOM and PBOM reflects a broader industry truth: visibility without provenance is incomplete. Practitioners should align application governance with dependency assurance and treat inherited code as an owned control domain.

Active ASPM only works if prioritisation is contextual, not volume-driven. The article correctly points to attack path analysis and contextual analysis because teams cannot remediate every finding at once. What matters is whether a vulnerability is reachable, inherited, exploitable and connected to sensitive runtime paths. Practitioners should use posture data to reduce false urgency and focus on issues that change actual blast radius.

Application detection and response represents the next governance layer, not a replacement for prevention. Real-time response matters because modern applications fail in production as often as they fail in development. But detection without strong posture data just creates more alerts. Practitioners should see ADR as the runtime complement to posture management, with clear ownership for who can detect, contain and remediate live application threats.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

ASPM will keep displacing scan-only thinking because modern delivery no longer has a stable end point. Security leaders should expect application governance to move closer to pipeline identity, dependency provenance and runtime monitoring as a single control problem. That creates a stronger case for treating machine credentials and build trust as part of AppSec operating design, not a separate DevOps topic.

Software supply chain governance is becoming the differentiator between visible risk and controlled risk. A codebase that depends heavily on third-party components needs provenance, not just inventory, and the discipline around SBOM and PBOM will keep growing in importance. Practitioners should prepare for application risk reviews that ask where code came from, how it moved and who or what signed off on it.

For practitioners

• Map security controls across the full SDLC Define how code scanning, dependency analysis, pipeline checks and runtime monitoring relate to one another so teams are not relying on disconnected tools to represent the same risk.
• Bring machine identities into AppSec governance Inventory the secrets, service accounts and tokens used by build and deployment systems, then align their access scope with application delivery controls.
• Prioritise vulnerabilities by exploit path Use contextual analysis and attack path analysis to focus remediation on issues that are reachable, inherited from third parties or tied to production exposure.
• Add provenance checks to dependency review Require SBOM and PBOM visibility for critical applications so teams can trace what was used, what changed and where trust was introduced.
• Define runtime response ownership for applications Assign clear detection and containment responsibilities for live application threats so ADR complements posture management instead of operating as an isolated alert source.

Key takeaways

• Fragmented application security testing no longer matches the pace of modern delivery, especially when code, pipelines and cloud runtime change continuously.
• Third-party components and build dependencies turn software supply chain governance into a central AppSec concern, not an adjacent one.
• Posture management and runtime response only work when teams connect vulnerability data to provenance, reachability and ownership across the SDLC.

Key terms

• Identity Security Posture Management: Identity security posture management is the continuous assessment of identity configuration, privilege, and exposure across an environment. It focuses on drift, overprivilege, and control gaps so teams can see where IAM, PAM, and NHI governance are failing before those gaps become incidents.
• Software Supply Chain Security: Software supply chain security is the practice of protecting the people, code, tools, dependencies, and delivery paths used to build and ship software. It covers source integrity, dependency risk, build system hardening, artifact signing, provenance, and release controls so malicious changes are detected before software reaches production.
• Pipeline Bill Of Materials: A Pipeline Bill of Materials extends SBOM thinking into the delivery chain by recording what was used, transformed, and promoted during build and release. It matters because many supply chain risks are introduced after code is written, inside automation, packaging, and deployment steps.
• Application Detection And Response: Application Detection and Response is a runtime control focused on what applications do after they start running. It helps security teams identify exploit attempts, malicious behaviour, and active abuse in the application layer, where static tools often have limited visibility.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It is designed for practitioners who need to connect identity controls to broader security programmes without losing operational clarity.