Gartner formally defined Application Security Posture Management as its own category in a May 2023 Innovation Insight report, describing it not as a new scanner but as a correlation layer that sits on top of the SAST, DAST, SCA, secrets, IaC, and container tools most AppSec teams already run. Three years on, the term has been applied to everything from a single-pane dashboard that re-lists existing scanner output to platforms that build a genuine call graph and reachability model across a codebase. The gap between those two things is the entire reason a buyer's guide is worth writing. The canonical case for why correlation matters is still Log4Shell: Chen Zhaojun of Alibaba Cloud's security team privately disclosed the flaw to the Apache Software Foundation on November 24, 2021, it went public as CVE-2021-44228 on December 9, 2021 with a maximum CVSS score of 10.0, and the vulnerable code had sat in Log4j since 2013 — eight years unnoticed, then flagged by every SCA tool simultaneously, with almost none of them able to say which of the thousand flagged repositories actually had the vulnerable class loaded at runtime. This piece walks through the questions worth asking any ASPM vendor before you sign.
What does "breadth of ingestion" actually mean?
Breadth of ingestion means the platform pulls findings and asset inventory from every corner of your software estate — not just the scanners it ships itself. A real evaluation checks whether the vendor natively ingests results from your existing SAST, DAST, SCA, secrets, IaC, and container tools via API, or whether it only "supports" them through a CSV import that nobody maintains after the pilot. It also means asset discovery across categories most vendors ignore: source repositories, container images, packages, SBOMs, AI/ML models, and runtime workloads, not just repos and containers. Ask specifically how the platform finds ungoverned assets — a repository nobody connected, an image running in production with no SBOM at all — because the assets missing from your inventory are exactly the ones a scanner-only tool will never flag. Coverage percentage across asset classes, not just finding count, is the metric that predicts whether the platform will actually see the next Log4Shell-shaped dependency before an attacker does.
How should deduplication and correlation be tested, not just claimed?
Deduplication and correlation should be tested by pointing the platform at a codebase where you already know the ground truth — a repo where three different scanners each independently flag the same vulnerable line — and counting how many tickets come out the other end. A platform doing real correlation collapses a SAST hit, an SCA hit on the same dependency, and a container-scan hit on the image that ships it into one finding tied to one code location, not three tickets in three backlogs. Ask the vendor to walk through a Log4Shell-style scenario live: if the same log4j-core version shows up in twelve microservices, does the tool report twelve identical alerts, or one vulnerability entry with twelve affected assets ranked by which ones face the internet? The volume reduction from proper correlation is usually the first number a prospective buyer notices in a proof-of-concept, and it's also the easiest thing for a vendor to fake with a demo dataset — insist on running it against your own repos, not theirs.
Why does reachability change the priority list, not just the noise level?
Reachability changes the priority list because it answers a binary, verifiable question a raw CVE match cannot: can your code actually execute the vulnerable function? A dependency scan matches your lockfile against a CVE database and reports every match regardless of whether the flagged function is ever called — this is precisely the failure mode that let Log4Shell-class findings sit buried among thousands of theoretical alerts for years before anyone builds a call graph deep enough to separate "loaded but never invoked" from "reachable from an internet-facing endpoint." A real ASPM evaluation should include a reachability spot-check: pick ten known-vulnerable dependencies already in your SBOM, ask the vendor's tool to say which are reachable from an untrusted entry point, and manually verify five of the answers yourself. If the platform can't produce a call path as evidence — not just a reachable/unreachable label — treat the reachability claim as marketing until proven otherwise.
What does business-context mapping need to include to be useful?
Business-context mapping needs to tie every finding back to a repository, the service it builds, the team that owns it, and the environment it runs in — production, staging, or an ephemeral dev sandbox — because identical CVEs in those three environments carry completely different urgency. Ask how ownership is derived: platforms that only support manual tagging fall out of date within a quarter, while ones that infer ownership from Git CODEOWNERS files, container labels, or cloud account structure stay accurate as teams reorganize. Also check whether sensitivity flags — customer data, regulated workloads under FedRAMP, HIPAA, or PCI — actually change routing, or whether they're just a column in a table nobody filters on. The test to run in a proof-of-concept: inject one critical finding into a production PCI-tagged service and one into a dev sandbox, and confirm the platform routes them to different people with different SLAs by default, not just by manual configuration you'd have to build yourself.
How should risk scoring go beyond raw CVSS?
Risk scoring should combine exploitability, reachability, and internet exposure with signals about the component itself — not stop at a raw CVSS number that treats a 9.8 in an unreachable test dependency the same as a 9.8 in an internet-facing production service. Beyond vulnerability severity, ask whether the platform scores component trustworthiness independently of known CVEs: does it check for build provenance, whether the package is signed, whether it appears in a public transparency log, and whether its install scripts or network behavior look unusual? Safeguard's own Risk Score model, for example, blends attestation level, provenance verification, package health (maintenance activity, community size, typosquat similarity), and behavioral analysis into a single 0–10 score alongside its Safeguard Component Attestation Level (SCAL) rating — a six-tier scale from SCAL 0 (fully attested) to SCAL 5 (unknown origin) — precisely so a fully unverified, unsigned dependency scores as risk even before a CVE is ever assigned to it. A platform that can only re-rank existing CVSS scores by asset criticality is doing triage, not posture management — the distinguishing question is whether it can flag risk on a component with zero known vulnerabilities at all.
Does the platform enforce policy in CI/CD, or just report after the fact?
The platform needs to enforce policy at the point code merges or deploys, not just generate a dashboard someone checks after a breach. Ask whether policy rules — for example, "block any PR introducing a component with attestation below a set threshold" or "fail the build on any reachable critical finding" — can be expressed as code, versioned in your repo, and gated directly in the CI/CD pipeline rather than configured through a UI that only the security team can touch. Also confirm SBOM support extends past generation to genuine utility: does the platform emit CycloneDX or SPDX on every build automatically, and can it answer "are we affected" against every past SBOM the moment a new CVE like Log4Shell drops, in minutes rather than days of re-scanning? A platform that reports findings without a gating mechanism is a scanner with better reporting; one that gates deploys against policy, using SBOMs as a queryable historical record, is the difference ASPM was supposed to represent when Gartner named the category in the first place.
How Safeguard Helps
Safeguard was built around the correlation and reachability gap this guide describes, rather than as a dashboard layered on top of existing scanners. Asset discovery covers seven classes — repositories, containers, packages, AI models, SBOMs, vendors, and runtime workloads — through agentless integrations, lightweight agents, and direct SBOM ingestion, with shadow-asset detection surfacing the ungoverned images and unconnected repos that most inventories miss entirely. Every discovered component gets a Risk Score built from attestation level, provenance verification, package health, and behavioral signals, so an unsigned or unattested dependency shows up as risk before any CVE is ever filed against it, and policies can gate merges and deploys directly on that score rather than on CVSS alone. The result is a single asset graph a security team can query the way Log4Shell should have been answerable in December 2021 — "which production workloads run this component, who owns them, and are they actually reachable" — in minutes, not a multi-week fire drill.