Application security posture management is replacing fragmented AST

At a glance

What this is: This is an analysis of why traditional application security testing is struggling and why application security posture management is being positioned as the broader control model.

Why it matters: It matters because AppSec now intersects with software supply chain trust, developer workflow control, and the identity and access boundaries that determine what code, tools, and pipelines can do.

By the numbers:

• Between 40-80% of code in new software projects comes from third parties.

👉 Read OXSecurity's analysis of application security posture management and supply chain risk

Context

Application security is moving from isolated vulnerability scanning to continuous control across code, pipelines, dependencies, and runtime. That shift is happening because modern SDLCs are faster, more distributed, and more dependent on third-party software than the older AST model was built to handle. For IAM and NHI practitioners, the important point is that application security now depends on who and what can reach build systems, secrets stores, deployment paths, and production services.

Traditional AST assumes security can be bolted on around development. In practice, the control gap is broader: fragmented tooling, manual triage, and limited visibility leave risk moving through the software supply chain faster than teams can review it. That makes application identity, secrets handling, and workload authorization part of AppSec governance rather than adjacent concerns.

Key questions

Q: How should security teams govern application security across the SDLC?

A: They should treat the SDLC as a chain of trust, not a sequence of isolated review steps. That means combining vulnerability scanning with provenance checks, secret governance, pipeline identity controls, and runtime monitoring. The goal is to know which identity can change code, which dependencies were introduced, and whether anything suspicious reached production.

Q: Why do fourth-party dependencies increase operational risk for security teams?

A: Fourth-party dependencies increase operational risk because they create shared exposure across services that appear separate on paper. If several vendors depend on the same hosting layer, identity provider, or software component, one incident can interrupt multiple business processes at once. Security teams need dependency visibility to understand that concentration risk.

Q: What do teams get wrong about application security posture management?

A: They often treat ASPM as another scanning layer instead of a governance model. ASPM is most useful when it connects findings to ownership, identity, dependency lineage, and response actions. Without those links, it becomes a dashboard that describes risk without changing it.

Q: How can organisations measure whether AppSec controls are working?

A: They should look for fewer repeat vulnerabilities, lower false-positive burden, faster developer adoption, and measurable reduction in high-risk bug classes. A healthy AppSec programme changes the shape of risk, not just the number of alerts. If findings remain high but exposure does not fall, the control model is not scaling.

Technical breakdown

Why traditional AST breaks in modern delivery pipelines

Application Security Testing focuses on finding vulnerabilities in code, but modern delivery risk is distributed across source control, dependency resolution, CI/CD, artifact promotion, and runtime. That creates a control gap between what is scanned and what actually ships. False positives, disconnected tools, and manual workflows make AST a point-in-time gate rather than a live security control. As software becomes more dynamic, the security model has to follow the asset and its identity through the lifecycle, not stop at source code inspection.

Practical implication: teams need continuous posture visibility across the pipeline, not just pre-merge scanning.

How software supply chain security changes the AppSec problem

Software supply chain security extends the perimeter to the third-party libraries, build components, and CI/CD processes that influence what gets deployed. The article’s use of SBOM and SCA reflects a key shift: knowing what is in the software is necessary, but not sufficient. You also need to understand how components were assembled, what dependencies were introduced, and where trust was delegated. In identity terms, every build system and automation path is a privileged actor that can inject risk downstream.

Practical implication: inventory dependencies and bind them to build-time identity, provenance, and approval controls.

Why active ASPM and ADR are converging

Active ASPM aims to provide continuous context across the SDLC, while Application Detection and Response pushes that visibility into live environments. Together, they reflect a move from finding issues to continuously governing exposure. PBOM is part of that direction because it describes not only what software contains, but what it has experienced. That matters for threat response, policy enforcement, and trust decisions about components, pipelines, and production workloads.

Practical implication: align build-time and runtime controls so dependency risk, deployment trust, and live detection share the same governance model.

Threat narrative

Attacker objective: The attacker wants to introduce or preserve exploitable software paths that survive scanning and reach production.

1. Entry occurs through exposed or over-trusted supply chain paths such as third-party dependencies, build pipelines, or leaked secrets in developer workflows.
2. Escalation follows when fragmented tooling and weak workflow controls allow malicious code, compromised components, or unauthorized changes to move through the SDLC.
3. Impact is realised when vulnerable software reaches production, creating exploitable application exposure and widening the organisation’s attack surface.

NHI Mgmt Group analysis

Fragmented AppSec is now a governance failure, not a tooling inconvenience. Traditional AST assumes security can be enforced at discrete checkpoints, but modern delivery pipelines distribute trust across code, dependencies, build systems, and runtime. Once those layers are disconnected, teams lose the ability to answer a simple governance question: what changed, who approved it, and what identity made it happen? For IAM and NHI programmes, that means software delivery must be treated as an identity-governed system, not just a development workflow. The practitioner conclusion is that AppSec control ownership now spans engineering and identity teams together.

Software supply chain risk is really delegated trust risk. The article’s discussion of third-party code and compositional analysis points to a deeper issue: organisations inherit risk from components they do not control directly. That makes provenance, signing, approval boundaries, and build-time identity central to any credible security model. Delegated build trust: when a pipeline can introduce code, secrets, or artifacts into production without tight lineage controls, the control plane has already failed. Practitioners should treat every dependency and automation path as a potential privilege boundary.

Active ASPM only works when it is joined to identity and secret governance. Continuous monitoring and attack-path analysis are useful, but they do not solve the underlying question of who or what can make changes in the first place. The most persistent AppSec failures today come from credentials, automation tokens, and over-broad pipeline permissions that allow risky code paths to survive. For NHI governance, this is the critical intersection: service accounts, CI/CD identities, and secret lifecycle controls determine whether posture management becomes real or remains descriptive. The practitioner conclusion is to bind AppSec telemetry to identity lifecycle controls.

ADR signals that application defence is moving closer to runtime authorisation. The article frames ADR as a live-response layer, which reflects a broader market shift from static review to continuous enforcement. That only works if detection can be tied back to trustworthy application identity, workload identity, and policy boundaries. Otherwise, response remains observational rather than corrective. For security architects, the implication is clear: runtime controls need to be designed as part of the application identity model, not added after deployment. Practitioners should align detection, policy, and identity metadata before trying to operationalise ADR.

What this signals

Pipeline identity is becoming the control point that determines whether AppSec is enforceable. As delivery environments accelerate, the question is no longer whether teams can scan code, but whether they can govern the identities that move software through build and release. That is where application risk starts to intersect directly with NHI governance: tokens, service accounts, and automation identities now shape exposure as much as the code itself. Practitioners should expect identity telemetry to become part of AppSec decision-making, not a separate operations concern.

Delegated trust will remain the hardest AppSec problem until provenance and response are linked. The industry is moving toward supply chain visibility, but visibility alone does not reduce exposure unless it is tied to revocation, approval, and runtime containment. The practical signal for programmes is whether they can trace a suspicious artifact back to the identity that introduced it and to the control that should have blocked it. That is the difference between monitoring and governance.

If your organisation is already using the 52 NHI Breaches Analysis, the useful question now is whether your AppSec programme can detect the same failure pattern before it becomes a production incident. The control objective is to shrink the gap between compromise, release, and response, because that gap is where modern supply chain attacks gain leverage.

For practitioners

• Map pipeline identities and permissions end to end Inventory the service accounts, tokens, and automation identities that can change code, dependencies, build artifacts, and deployments. Remove unnecessary standing access and document which identity can promote software into production at each stage.
• Bind dependency controls to provenance checks Pair SBOM and SCA with artifact signing, build attestation, and approval rules that verify where components came from and how they were introduced. Treat provenance gaps as release blockers, not post-release findings.
• Unify secrets governance with AppSec telemetry Correlate leaked-secret detection with rotation, revocation, and pipeline access review so exposed credentials are not left valid for weeks. Use the 27-day remediation gap as a benchmark for tightening response ownership.
• Extend control coverage into runtime response Use ADR or equivalent controls to detect suspicious application behaviour in production and link it back to the originating build, dependency, or workload identity. This makes containment faster when an issue escapes pre-deployment checks.

Key takeaways

• Modern AppSec fails when scanning is treated as the whole control model.
• Secrets, pipeline identities, and dependency provenance now decide whether software delivery is trustworthy.
• Teams that can connect build-time governance to runtime response will contain supply chain risk faster than teams that rely on point-in-time testing.

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: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• 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.
• Cloud Application Detection And Response: Cloud Application Detection and Response is the practice of identifying suspicious behaviour inside live cloud applications and workloads, then containing that behaviour before it spreads. It focuses on runtime signals such as unusual access, API misuse, and escalation paths that scan-time posture tools cannot see.

What's in the full article

OXSecurity's full article covers the operational detail this post intentionally leaves for the source:

• A vendor-specific explanation of how ASPM is positioned against traditional AST in delivery pipelines
• Implementation detail on active ASPM, including PBOM, contextual analysis, and attack-path prioritisation
• A closer look at how ADR is expected to fit into live application monitoring and response workflows
• The source article's framing of software supply chain security alongside ASPM for developers and security teams

👉 OXSecurity's full article covers ASPM, software supply chain security, and ADR in more implementation detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build the governance skills needed across modern application and automation environments.