Organisations that run SAST, SCA, DAST, secret scanning, IaC and container scanning usually end up with tens of thousands of findings, duplicated across tools, with no owner and no agreed order of work. Application security posture management (ASPM) platforms aim to fix that: they ingest results from many scanners, correlate them to applications, code owners and running services, prioritise by context and drive remediation and policy gates. Some also bring their own scanners. This vendor-neutral guide helps AppSec leads, DevSecOps engineers and buyers define what they need, compare offerings without relying on vendor rankings, and test them on their own repositories and pipelines.
Key takeaways
- ASPM is a correlation and workflow layer first. Its value comes from deduplication, ownership and prioritisation, not from adding another scanner.
- Context decides priority. Reachability, internet exposure, data sensitivity and known exploitation (CISA KEV, FIRST EPSS) matter more than raw CVSS.
- Inventory is the foundation. If the platform cannot map repositories, pipelines, artefacts and deployed services to an owning team, every other feature degrades.
- Test on your data, not a demo tenant. Deduplication accuracy, false correlation and noise reduction only show up with your real tool output.
- It holds the keys to your code. Read access to every repository and pipeline makes the ASPM connector a high-value non-human identity to scope and govern.
Define requirements
- Current tool estate: list every scanner (SAST, SCA, DAST, secrets, IaC, container, API, cloud posture), whether it emits SARIF 2.1.0, CycloneDX or SPDX, and which you intend to keep. Decide whether you want an ASPM that only aggregates or one that replaces some scanners.
- Scale and shape: number of repositories, languages, source control systems, CI/CD platforms, registries and runtime environments (Kubernetes clusters, serverless, VMs).
- Outcomes: which decisions the platform must support, for example "fix these 50 issues this sprint", "block this release", "prove SSDF conformance to a customer" or "report risk per business service".
- Framework alignment: evidence for NIST SP 800-218 SSDF practices such as PO.4 (define and use criteria for software security checks), PW.7 and PW.8 (code review and testing), RV.1 to RV.3 (identify, prioritise and remediate vulnerabilities, find root causes); maturity tracking against OWASP SAMM practices such as Defect Management and Security Testing.
- Workflow: ticketing system, chat, pull request comments, ownership source (CODEOWNERS, service catalogue, CMDB) and SLA policy by severity.
- Constraints: SaaS versus self-hosted, data residency, whether source code may leave your environment, and the access model for connectors.
Capability areas
| Area | What good looks like | Why it matters |
|---|---|---|
| Ingestion and normalisation | Native connectors plus SARIF, CycloneDX/SPDX and generic import; one schema for findings with tool, rule, location and fingerprint | Avoids lock-in and supports tools you add later |
| Deduplication and correlation | Merge the same issue reported by several tools and branches; link a vulnerable package to the image, deployment and service that run it | Turns tool counts into real issue counts |
| Asset and ownership inventory | Repositories, pipelines, artefacts, APIs and services mapped to teams; detection of unscanned repositories | Supports CSF 2.0 ID.AM-02 and SP 800-53 CM-8; findings without owners do not get fixed |
| Contextual prioritisation | Reachability, internet exposure, runtime presence, data classification, KEV listing and EPSS probability, with the reasoning shown | CSF 2.0 ID.RA-05: risk informed by likelihood and impact |
| Exploitability statements | Record and import VEX statuses (not_affected, affected, fixed, under_investigation) with justification | Documents why a finding is suppressed and makes it auditable |
| Policy and guardrails | Policies as code for pipeline gates (for example block new critical reachable issues), exceptions with expiry and approver | SSDF PO.4 criteria applied consistently |
| Remediation workflow | Ticket creation and sync, pull request annotations, fix suggestions, grouping by fix (one upgrade closes many CVEs) | Developer time is the scarce resource |
| Software supply chain posture | SBOM generation or import, pipeline and source control configuration checks, secrets exposure | OWASP Top 10:2025 A03 Software Supply Chain Failures |
| Reporting | Risk per application and team, SLA adherence, trend over time, exportable evidence | Executive reporting and customer assurance |
See the Application Security Posture Management (ASPM) Guide for the operating model, and the Application Security Testing Buyer's Guide if you also need to choose scanners.
Evaluation criteria
| Criterion | Weight (example) | How to evidence it |
|---|---|---|
| Coverage of your tools and platforms | 15% | Connect every scanner, source control system and CI/CD platform in the proof of concept |
| Deduplication accuracy | 15% | Sample 100 merged issues and 100 unmerged; count wrong merges and missed merges |
| Prioritisation quality | 20% | Compare the top 50 against your AppSec team's own triage; check that KEV-listed, reachable, exposed issues rank first and the reasons are visible |
| Ownership mapping | 10% | Percentage of findings auto-assigned to the correct team |
| Developer workflow | 15% | Developer feedback on pull request and ticket integration; time from finding to ticket |
| Policy and exceptions | 10% | Write a gate and an expiring exception as code; confirm audit trail |
| Security of the platform | 10% | Connector permissions, token handling, SSO and MFA for admins, data handling, assurance reports |
| Commercials | 5% | Pricing basis (developers, repositories, applications) modelled at three-year growth |
Smaller teams with two or three scanners may get most of the value from the reporting built into a developer platform or an open-source aggregator; ASPM earns its cost when the estate spans many tools, teams and runtimes. The Vulnerability Management Buyer's Guide covers infrastructure findings, which some buyers want in the same view.
Questions to ask vendors
- How do you fingerprint findings so that the same issue is recognised across tools, branches and refactors, and how do we correct a wrong merge?
- What exactly does "reachable" mean in your product: static call graph, runtime telemetry or both, and for which languages?
- Which context signals feed the priority score (KEV, EPSS, exposure, data classification, runtime presence), and can we see and adjust the weighting?
- Can you import and export VEX and SBOMs, and do suppressed findings keep a justification and an approver?
- What permissions do your source control, CI/CD and cloud connectors need, are they read-only, and do they support short-lived credentials such as OIDC federation instead of long-lived tokens?
- Does any source code leave our environment, where is it stored and for how long?
- How do you detect repositories and services that no scanner covers?
- If we leave, can we export all findings, history, exceptions and policies in a documented format?
Red flags
- Noise reduction claims without method: "90% fewer alerts" that cannot be reproduced on your data or explained per finding.
- Opaque risk scores: a single number with no visible inputs, which developers will not trust and auditors cannot check.
- Closed ingestion: only the vendor's own scanners are first-class, with no SARIF or SBOM import.
- Silent suppression: findings hidden by "not reachable" logic with no justification record or expiry.
- Broad standing tokens: connectors that need organisation-wide admin or write access and a long-lived personal access token. A platform that holds tokens for many systems concentrates risk, as the CircleCI breach showed when customer CI/CD tokens and keys were exfiltrated.
- Dashboards without workflow: good reporting but no ticket sync or pull request feedback, so nothing changes in the code.
Proof of concept
- Pick a representative slice: three to five applications across your main languages, including one internet-facing service, one internal service and one with heavy open-source use.
- Connect with least privilege: read-only connectors, short-lived or scoped tokens, a named owner for each integration identity; record the permissions requested.
- Ingest existing output: load current SAST, SCA, secrets, IaC and container results, ideally in SARIF and CycloneDX, and record the raw count.
- Measure deduplication and ownership: sample merges and assignments, count errors, and list repositories the platform found that were not in your inventory.
- Compare prioritisation: have the AppSec team triage the same findings blind, then compare with the platform's top 50; check each KEV-listed CVE and how EPSS and exposure are used.
- Run a gate in warn mode: apply a pipeline policy to real pull requests for two weeks, log what it would have blocked, then enforce on one repository with a documented rollback (policy toggle).
- Close the loop: push tickets to one team, fix a batch, confirm findings close automatically on rescan.
- Agree the metrics you will track after go-live: mean time to remediate by severity, percentage of repositories with complete scanner coverage, percentage of findings with an owner, open exceptions past expiry, and SLA adherence for KEV-listed issues.
Primary sources used here: NIST SP 800-218 SSDF, OASIS SARIF 2.1.0, FIRST EPSS, the CISA Known Exploited Vulnerabilities Catalog, the OpenVEX specification, the OWASP SAMM model and the OWASP Top 10:2025. In NIST SP 800-53 Rev. 5 terms ASPM supports RA-5 Vulnerability Monitoring and Scanning, SA-11 Developer Testing and Evaluation and SI-2 Flaw Remediation. See also the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our NHI and AI products directory or contact us.
Related NHI Mgmt Group resources: Application Security Posture Management (ASPM) Guide · Application Security Guide · DevSecOps Guide · Software Supply Chain Security Buyer's Guide · CI/CD Pipeline Identity Security Guide