An application security posture management RFP that asks "how many scanners do you integrate with?" will get the same yes from every bidder, and tell you nothing about whether the platform can turn tens of thousands of duplicate findings into a short, owned, provable list of fixes. This template gives you a ready-to-issue request for proposal for an ASPM platform, with numbered requirements that can each be verified in a proof of concept and scored. It covers scanner ingestion, application inventory, deduplication and correlation, code-to-cloud context, prioritisation, policy and gates, developer workflow, non-human identity and secrets findings, the security of the platform itself, services and commercials. It is vendor-neutral and written for AppSec leads, platform engineering, procurement and evaluation panels. For what ASPM is, read the Application Security Posture Management (ASPM) Guide; for market capabilities, the ASPM Buyer's Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [number of repositories] and [scanners in use], with your own details. Delete requirements that do not apply.
- Each requirement has an ID (for example ASPM-DED-02) and a type: M mandatory (pass or fail), S scored (0 to 5, weighted) or I informational.
- Weights, volumes and timings in brackets are illustrative, not benchmarks. Fix them before issue and do not change them after responses arrive.
- Issue sections 1 to 8 to bidders; the Implementation guidance section is for your panel only.
- If you are also buying a CNAPP, align runtime and cloud requirements with the CNAPP RFP Template so code-to-cloud context is not bought twice.
1. Purpose and scope
[Organisation] invites proposals for an application security posture management platform, implementation services and support for [term] years. The platform must aggregate findings from [Organisation]'s existing and future application security testing tools, build an application inventory linked to owners and runtime environments, remove duplicates, prioritise by real risk, and drive remediation through developer workflows with measurable outcomes. In scope: [number] applications, [number] code repositories across [source control platforms], [number] CI/CD pipelines and [cloud and Kubernetes environments]. Out of scope: replacing existing scanners unless offered as an option priced separately.
2. Organisation background and current state
- Development estate: [number] developers, main languages [list], source control [platforms], CI/CD [platforms], artefact registries [list].
- Testing tools in use: SAST [tool type], SCA [tool type], secrets scanning, IaC scanning, container image scanning, DAST, API testing, penetration test reports, bug bounty.
- Current volumes: approximately [number] open findings, [percentage] estimated duplicates, [number] AppSec engineers.
- Ticketing and chat: [issue trackers], [chat tools].
- Drivers: [for example SSDF attestation for customers, secure SDLC policy, audit findings on vulnerability backlog].
3. Instructions to bidders
- Answer every requirement with Comply, Partially comply (explain) or Does not comply, plus a description of how it is met and whether it is generally available, in beta or on the roadmap. Roadmap items score zero.
- Identify any requirement met through a third-party product or professional services.
- State where customer data is processed and stored, and which data leaves [Organisation]'s environment (for example source code snippets).
- Provide [three] references of similar scale and toolchain.
- Submit questions by [date]; responses are due by [date].
4. Functional requirements
4.1 Ingestion and integrations
| ID | Requirement | Type |
|---|
| ASPM-ING-01 | Ingests findings from [list of the organisation's scanners] through supported connectors; list each connector, the data fields imported and the sync frequency. | M |
| ASPM-ING-02 | Imports SARIF 2.1.0 files, preserving rule ID, location, severity and fingerprints, so tools without a native connector can be added. | M |
| ASPM-ING-03 | Imports SBOMs in CycloneDX and SPDX formats and VEX statements, and links components to applications. | S |
| ASPM-ING-04 | Accepts manual and semi-structured findings (penetration test reports, bug bounty submissions) through an API or bulk import. | S |
| ASPM-ING-05 | Offers optional built-in scanners; state which, and confirm that using them is not required for any other requirement. | I |
4.2 Application inventory and ownership
| ID | Requirement | Type |
|---|
| ASPM-INV-01 | Discovers repositories, pipelines and artefacts automatically and groups them into applications; describe how grouping is inferred and how it is corrected. | M |
| ASPM-INV-02 | Assigns an owning team to each application and finding from [CODEOWNERS files, service catalogue, CMDB, commit history]; state the sources supported. | M |
| ASPM-INV-03 | Records business context per application (criticality, data classification, internet exposure, regulatory scope) and uses it in prioritisation. | S |
| ASPM-INV-04 | Reports coverage: which applications and repositories have each type of testing, and which have none. | M |
4.3 Deduplication and correlation
| ID | Requirement | Type |
|---|
| ASPM-DED-01 | Removes duplicate findings reported by different tools for the same issue and location, and explains the matching logic. | M |
| ASPM-DED-02 | Groups findings that share one fix (for example one vulnerable library version across many repositories, or one base image across many services) into a single remediation item. | S |
| ASPM-DED-03 | Tracks a finding across scans and code moves so that status, comments and exceptions persist; state how fingerprints are generated. | S |
| ASPM-DED-04 | Shows the original tool findings behind every merged item for audit. | M |
4.4 Code-to-cloud context and prioritisation
| ID | Requirement | Type |
|---|
| ASPM-CTX-01 | Links source code to the build artefact, container image and running workload in [cloud and Kubernetes environments]; describe how the link is established (for example image digests, build provenance, deployment metadata). | S |
| ASPM-CTX-02 | Prioritises using exploitability signals: CISA Known Exploited Vulnerabilities listing, EPSS, internet exposure, whether the component is deployed, and reachability of the vulnerable code where supported; state the method per language. | M |
| ASPM-CTX-03 | Lets [Organisation] define its own risk scoring formula and SLA tiers, and shows the factors behind each score. | S |
| ASPM-CTX-04 | Supports decision models such as CISA SSVC outcomes (Track, Track*, Attend, Act) or equivalent custom tiers. | I |
4.5 Policy, gates and exceptions
| ID | Requirement | Type |
|---|
| ASPM-POL-01 | Defines policies as code or through a versioned interface (for example "no new critical exploitable findings in internet-facing applications") and applies them per application tier. | M |
| ASPM-POL-02 | Enforces policies as pull request checks or pipeline gates, with a warn-only mode and a measured block mode. | S |
| ASPM-POL-03 | Records risk acceptances and exceptions with owner, reason, approver and expiry, and reopens items on expiry. | M |
| ASPM-POL-04 | Maps findings and controls to [OWASP ASVS 5.0, NIST SP 800-218 SSDF, PCI DSS, ISO/IEC 27001] for reporting. | S |
4.6 Developer workflow and remediation
| ID | Requirement | Type |
|---|
| ASPM-DEV-01 | Creates and syncs tickets two ways in [issue trackers], with configurable grouping so teams are not flooded with one ticket per finding. | M |
| ASPM-DEV-02 | Presents findings in pull requests and IDEs with fix guidance specific to the language and framework. | S |
| ASPM-DEV-03 | Proposes fixes (for example dependency upgrade pull requests or suggested code changes); state whether generative AI is used, which data is sent to which model and how suggestions are reviewed. | S |
| ASPM-DEV-04 | Verifies fixes by rescanning or tool feedback and closes items automatically only when the issue is confirmed resolved. | M |
4.7 Secrets and non-human identity findings
| ID | Requirement | Type |
|---|
| ASPM-NHI-01 | Ingests secret scanning results from code, history, pipelines and images, and identifies the secret type and the system it grants access to. | S |
| ASPM-NHI-02 | Indicates whether a detected secret is still valid where safe verification is supported, without storing the secret value in clear. | S |
| ASPM-NHI-03 | Flags over-privileged pipeline and workload identities found in IaC and CI configuration (for example wildcard cloud permissions or long-lived tokens). | S |
See the Developer Secret Scanning Triage and the IaC identity policy checks.
4.8 Reporting
| ID | Requirement | Type |
|---|
| ASPM-REP-01 | Reports mean time to remediate by severity, team and application; SLA compliance; backlog age; and coverage, exportable by API. | M |
| ASPM-REP-02 | Provides evidence exports suitable for customer security questionnaires and SSDF attestation support. | S |
An ASPM platform holds read access to source code, pipelines and cloud metadata, and stores a map of your weaknesses. Treat it as a high-value system.
| ID | Requirement | Type |
|---|
| ASPM-SEC-01 | Supports SSO with SAML or OIDC, MFA enforcement, SCIM provisioning and role-based access scoped by application or team. | M |
| ASPM-SEC-02 | Integrations use least-privilege, read-only scopes by default, short-lived or federated credentials where the source supports them, and document every permission requested. | M |
| ASPM-SEC-03 | States whether source code is copied, cached or only referenced, where it is stored, retention, and how it is deleted on exit. | M |
| ASPM-SEC-04 | Provides an audit log of user and API actions, exportable to [SIEM]. | M |
| ASPM-SEC-05 | Provides current independent assurance (for example SOC 2 Type II or ISO/IEC 27001 certificate), a secure development statement, and an SBOM for the platform on request. | S |
6. Implementation, services and support
- ASPM-SVC-01 (M): implementation plan reaching [number] applications onboarded with ownership within [90 days].
- ASPM-SVC-02 (S): named customer success and AppSec expertise, training for AppSec and developer champions.
- ASPM-SVC-03 (M): support hours, severity definitions and response times; platform availability commitment of [99.9%].
- ASPM-SVC-04 (I): connector roadmap process and typical time to add a new scanner integration.
7. Commercials
- ASPM-COM-01 (M): state the licence metric (developers, committers, applications, repositories or findings) and how it is counted, including bots and inactive contributors.
- ASPM-COM-02 (M): price for years 1 to [3] at current scale and at [150%] growth, with all modules and connectors itemised.
- ASPM-COM-03 (S): data export in documented formats at no cost during the term and on exit.
8. Evaluation method and proof of concept
Responses are scored in two stages: written response, then a proof of concept for the [two or three] highest scoring bidders. Mandatory failures exclude the bid.
| Area | Illustrative weight |
|---|
| Ingestion, inventory and ownership (4.1, 4.2) | [20%] |
| Deduplication and prioritisation (4.3, 4.4) | [25%] |
| Policy and developer workflow (4.5, 4.6) | [20%] |
| Secrets, NHI and reporting (4.7, 4.8) | [10%] |
| Platform security (5) | [10%] |
| Services and commercials (6, 7) | [15%] |
Proof of concept tests, run on [Organisation]'s own repositories and scanner output over [3 to 4 weeks]:
- Ingestion: connect [named scanners] plus one SARIF-only tool; verify finding counts match source tools.
- Deduplication: load a prepared set where the panel already knows the true duplicates; measure correct merges and wrong merges.
- Ownership: check the owning team assigned to [50] sampled findings against known owners.
- Prioritisation: confirm a known KEV-listed vulnerability in a deployed, internet-facing service ranks above the same CVE in an undeployed branch; ask the bidder to explain the score.
- Gate: open a pull request introducing a planted vulnerable dependency and a planted test secret; confirm warn and block behaviour and the developer message.
- Ticket sync: close a ticket without a fix and confirm the item does not close; fix it and confirm verified closure.
- Platform security: review integration permissions actually granted against ASPM-SEC-02.
Implementation guidance
This section is for the evaluation panel and is not issued to bidders.
Before you issue
- Measure your baseline: open findings by tool, estimated duplicates, applications without owners and mean time to remediate. Without these you cannot test the bidders' claims or show value later.
- Prepare the POC data set: a labelled sample of real findings with known duplicates, known owners and known false positives. This is the single most useful thing the panel can build.
- Decide the boundary with CNAPP and vulnerability management: who owns runtime vulnerabilities and cloud misconfiguration, so requirements are not duplicated across tools.
- Agree the licence metric internally: count developers, committers and bots in your own source control first.
Choosing between approaches
| Approach | Fits when | Trade-off |
|---|
| Tool-agnostic ASPM over existing scanners | Many scanners, several business units, existing contracts | Quality depends on connectors; more integration work |
| ASPM bundled with the bidder's own scanners | Smaller estate, wish to consolidate tools | Lock-in; weaker results for third-party tools |
| ASPM features inside a CNAPP | Cloud-native estate where runtime context matters most | Code-side depth (ownership, PR workflow) may be thinner |
Small organisations with one source control platform and two or three scanners may meet most needs with native platform features and should weight commercials higher; large organisations should weight deduplication, ownership and policy most heavily.
Common failure patterns
- Scoring connector counts: every bidder lists many; only the POC shows which import the fields you need.
- Testing on vendor demo repositories: deduplication and ownership look perfect on clean data. Always use your own.
- Turning on blocking gates on day one: developers route around the platform. Start warn-only and move to block per application tier.
- Ignoring the platform's own access: broad write tokens to source control make the ASPM tool a supply chain risk. See the Software Supply Chain Security Guide.
- Not budgeting for ownership data: without a maintained service catalogue or CODEOWNERS, prioritised findings still have nowhere to go.
Framework alignment
| RFP area | Reference |
|---|
| 4.1 to 4.4 Finding aggregation and prioritisation | NIST SP 800-218 SSDF practice group RV (respond to vulnerabilities); NIST SP 800-53 RA-5; NIST CSF 2.0 ID.RA-01 |
| 4.5 Policy and gates | SSDF practice group PW (produce well-secured software); NIST SP 800-53 SA-11; OWASP ASVS 5.0 as the requirement baseline |
| 4.1 SBOM and VEX | CycloneDX (ECMA-424), SPDX; NIST SP 800-53 CM-8, SR-3 |
| 5 Platform security | NIST SP 800-53 AC-6, AU-2; supplier assurance under your Supplier Security Policy Template |
Standards and references
Related NHI Mgmt Group resources: Application Security Posture Management (ASPM) Guide · ASPM Buyer's Guide · Security Vendor Evaluation and RFP Guide · CNAPP RFP Template · EPSS Guide