TL;DR: Application security teams are under pressure to replace fragmented AST with broader posture management as software supply chains, developer-owned security, and cloud complexity widen exposure, according to OXSecurity. The real shift is from point-in-time scanning to continuous governance across code, pipelines, and runtime, where identity, access, and dependency trust now matter as much as vulnerability counts.
NHIMG editorial — based on content published by OXSecurity: Application security posture management and software supply chain security
By the numbers:
- Between 40-80% of code in new software projects comes from third parties.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read OXSecurity's analysis of application security posture management and supply chain risk →
Application security posture management: is your AppSec model keeping up?
Explore further
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.
A question worth separating out:
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.
👉 Read our full editorial: Application security posture management is replacing fragmented AST