Application security testing tools are usually bought on a demo against the bidder's own sample application, and then disappoint on real code: false positives, slow pull request scans, frameworks only partly understood and developers who stop reading the results. This template is a ready-to-issue request for proposal for application security testing: static analysis (SAST), software composition analysis (SCA), secrets scanning, infrastructure as code scanning, dynamic testing (DAST), interactive testing (IAST) and API testing, plus developer workflow, AI fix suggestions, data handling and the scanner's own access to your source code. Every requirement has an ID, a type and a proof of concept test. It is vendor-neutral and written for AppSec leads, engineering managers, procurement and evaluation panels. For capability areas and known blind spots of each technique, read the Application Security Testing Buyer's Guide first.
How to use this template
- Replace text in square brackets, such as [Organisation], [languages] and [source control platforms], with your own details. Delete testing types you are not buying in this round.
- Each requirement has an ID (for example AST-SAST-02) and a type: M mandatory (pass or fail), S scored (0 to 5, then weighted) or I informational.
- Weights, volumes, timings and percentages in brackets are illustrative, not benchmarks. Fix them before issue and do not change them after responses arrive.
- Issue sections 1 to 9 to bidders. The Implementation guidance section is for your panel only.
- If findings from several tools will be aggregated and prioritised in a separate platform, align section 4.8 with the ASPM RFP Template. For dedicated runtime API protection, use the API Security RFP Template.
1. Purpose and scope
[Organisation] invites proposals for application security testing tools or a testing platform, implementation services and support for a term of [three] years. The solution must find security weaknesses in [Organisation]'s own code, dependencies, configuration and running applications early enough for developers to fix them, with accuracy that keeps developer trust and evidence that supports audit. Testing types in scope: [SAST, SCA, secrets scanning, IaC scanning, container image scanning, DAST, IAST, API testing]. In scope: approximately [number] repositories, [number] contributing developers, [number] web applications and [number] APIs. Out of scope: [penetration testing services, runtime protection, bug bounty], unless offered as separately priced options.
2. Organisation background and current state
- Languages and frameworks: [languages with versions], frameworks [for example Spring, ASP.NET Core, Django, Express], mobile [platforms], monorepos [yes or no].
- Source control and CI: [platforms], approximately [number] pull requests per day, pull request scan time budget [minutes].
- Build: [percentage] of repositories build cleanly in CI; package ecosystems [list]; container registries [list]; IaC [Terraform, Kubernetes manifests, other].
- Current tools: [testing types in use and approximate open findings], ticketing [type], chat [type].
- Drivers: [for example secure SDLC policy, customer attestations against NIST SP 800-218 SSDF, PCI DSS v4.0.1 requirement 6, audit findings].
- Data constraints: [whether source code may leave Organisation's environment, permitted regions, retention limits].
3. Instructions to bidders
- Answer every requirement with Comply, Partially comply (explain) or Does not comply, plus how it is met and whether it is generally available, in beta or on the roadmap. Roadmap and beta items score zero.
- For language and framework support, answer per language and version in the coverage workbook provided. "Supported" without framework detail scores as Partially comply.
- Identify any engine licensed from a third party or delivered by a partner.
- State the deployment options (SaaS, single-tenant, self-hosted, scanning inside [Organisation]'s network with results only sent out) and what code or artefacts leave [Organisation]'s environment in each.
- Provide [three] references with similar languages and source control platforms.
- Submit clarification questions by [date]. Responses are due by [date].
4. Functional requirements
4.1 Static analysis (SAST)
| ID | Requirement | Type |
|---|---|---|
| AST-SAST-01 | Analyses [languages and versions] with inter-procedural, cross-file data flow and framework-aware sources and sinks for [named frameworks]. | M |
| AST-SAST-02 | Scans code that does not compile cleanly; state which analyses degrade when a build is not available. | S |
| AST-SAST-03 | Runs incremental scans of changed code in pull requests within [Organisation]'s time budget of [minutes] at [repository size]. | M |
| AST-SAST-04 | Supports custom rules written by [Organisation] in a documented language, testable before deployment. | S |
| AST-SAST-05 | Tags every finding with CWE IDs and maps findings to the OWASP Top 10 web risks. | M |
4.2 Software composition analysis (SCA)
| ID | Requirement | Type |
|---|---|---|
| AST-SCA-01 | Identifies direct and transitive dependencies from manifests, lockfiles and container images for [package ecosystems]. | M |
| AST-SCA-02 | Prioritises vulnerable dependencies using reachability of the vulnerable function where supported, the CISA Known Exploited Vulnerabilities catalogue and EPSS; state the method per language. | S |
| AST-SCA-03 | Detects known malicious packages and suspicious new versions, and applies licence policy. | S |
| AST-SCA-04 | Generates SBOMs in CycloneDX and SPDX formats and consumes VEX statements. | S |
See the Open Source Security Guide and the SBOM Guide.
4.3 Secrets and infrastructure as code
| ID | Requirement | Type |
|---|---|---|
| AST-SEC-01 | Detects secrets in commits, full history, pull requests and CI logs, with push-time blocking and custom patterns for [Organisation]'s internal token formats. | M |
| AST-SEC-02 | Indicates whether a detected secret is still valid where safe verification with the issuer is supported, without storing the secret value in clear. | S |
| AST-IAC-01 | Scans [Terraform, Kubernetes manifests, Dockerfiles, other] against policies mapped to [Organisation]'s cloud baselines, with custom policy as code. | S |
| AST-IAC-02 | Flags over-privileged pipeline and workload identities in IaC and CI configuration, such as wildcard permissions and long-lived tokens. | S |
Secrets findings are non-human identity findings: route them to credential owners, not only to code owners. See the Developer Secret Scanning Triage and the CI/CD Pipeline Identity Security Guide.
4.4 Dynamic, interactive and API testing
| ID | Requirement | Type |
|---|---|---|
| AST-DAST-01 | Performs authenticated scanning with multiple roles, including [SSO, MFA test accounts, token-based authentication], and maintains sessions through long scans. | M |
| AST-DAST-02 | Crawls JavaScript-heavy single-page applications and offers passive and safe scan modes for sensitive environments. | S |
| AST-DAST-03 | Imports OpenAPI and GraphQL schemas and tests REST, GraphQL and [gRPC] APIs, including authorisation tests with two test identities for OWASP API1:2023 and API5:2023. | M |
| AST-DAST-04 | Runs from CI/CD against ephemeral environments, with scan scope, rate and excluded paths controllable to avoid damage. | S |
| AST-IAST-01 | Provides an in-process agent for [runtimes] that confirms data flows during functional tests; state performance overhead and supported versions. | I |
See the Interactive Application Security Testing (IAST) and RASP Guide and the Authenticated vs Unauthenticated Scanning Guide.
4.5 Accuracy
| ID | Requirement | Type |
|---|---|---|
| AST-ACC-01 | Allows [Organisation] to run the solution on the OWASP Benchmark (Java v1.2, the current release; the Python v0.1 release is preliminary) and on [Organisation]'s seeded repositories during the proof of concept, and to publish the results internally. | M |
| AST-ACC-02 | Lets developers mark false positives with a reason, applies the decision to future scans of the same finding, and reports suppressions for review. | M |
| AST-ACC-03 | Explains each finding with the data flow or evidence (source, sink, request and response) needed to verify it without a security specialist. | S |
4.6 Developer workflow and AI fix suggestions
| ID | Requirement | Type |
|---|---|---|
| AST-DEV-01 | Comments on changed lines in pull requests for [source control platforms], with fix guidance for the language and framework. | M |
| AST-DEV-02 | Provides IDE plugins for [IDEs] using the same rules and suppressions as CI. | S |
| AST-DEV-03 | If AI-generated fixes are offered: fixes are proposed as reviewable changes, never merged automatically, re-scanned before merge, new dependencies are flagged, the feature can be disabled per repository, and the bidder states which code is sent to which model, where, and whether it is retained or used for training. | M |
| AST-DEV-04 | Creates and syncs tickets in [ticketing], grouped by fix rather than one ticket per finding. | S |
See the AI-Assisted Code Review and AI SAST Guide.
4.7 Policy gates
| ID | Requirement | Type |
|---|---|---|
| AST-POL-01 | Gates merges or builds on new findings by severity, CWE, reachability or secret validity, with audit (warn-only) mode before blocking. | M |
| AST-POL-02 | Records overrides and exceptions with owner, reason, approver and expiry, and reopens findings on expiry. | M |
| AST-POL-03 | Applies different policies per repository tier (for example internet-facing or in PCI DSS scope). | S |
4.8 Output, integration and reporting
| ID | Requirement | Type |
|---|---|---|
| AST-OUT-01 | Exports findings in SARIF 2.1.0 with stable rule IDs and fingerprints so results can be deduplicated across runs and tools. | M |
| AST-OUT-02 | Exposes all findings, suppressions and policy results through a documented API and webhooks. | M |
| AST-OUT-03 | Reports coverage (repositories and applications with each testing type), open findings by age and team, time to remediate and exception counts. | M |
| AST-OUT-04 | Produces evidence for SSDF attestations and PCI DSS v4.0.1 requirement 6 assessments. | S |
5. Security of the testing platform
A testing platform reads every repository, comments on pull requests and holds a token in every pipeline that calls it. It is a privileged non-human identity inside your software supply chain.
| ID | Requirement | Type |
|---|---|---|
| AST-PLT-01 | Integrates with source control through an app or installation model with fine-grained, repository-scoped permissions, not personal access tokens; document every permission requested and why. | M |
| AST-PLT-02 | Pipeline integrations use short-lived or federated credentials where the CI platform supports them; scanner components do not need access to unrelated pipeline secrets. | M |
| AST-PLT-03 | Signs scanner releases and container images, publishes checksums and provenance, and lets [Organisation] pin versions rather than follow a mutable tag. | M |
| AST-PLT-04 | States whether source code is copied, cached or only referenced, where, for how long, and how it is deleted on request and at exit. | M |
| AST-PLT-05 | Supports SSO with SAML or OIDC, enforced MFA, SCIM and role-based access by team; provides an audit log exportable to [SIEM]. | M |
| AST-PLT-06 | Provides current independent assurance (for example a SOC 2 Type II report or ISO/IEC 27001 certificate) and incident notification within [hours]. | S |
6. Implementation, services and support
- AST-SVC-01 (M): an onboarding plan covering [percentage] of repositories with SAST, SCA and secrets scanning within [90 days], and DAST on [tier 1 applications] within [120 days].
- AST-SVC-02 (S): rule tuning support, developer training and security champion enablement.
- AST-SVC-03 (M): support hours, severity definitions, response times and availability commitment of [99.9%] for SaaS components.
- AST-SVC-04 (I): roadmap process for new languages and frameworks, and typical lead time.
7. Vendor security and contract questions
- Which of your engines did you build, and which are licensed or open source components you package?
- How do you protect customer code and findings from your own staff, and who can access them for support?
- How would you notify us if a scanner release you shipped were tampered with, and how fast could you revoke it?
- What is your vulnerability disclosure process for the platform itself?
- What happens to our data, suppressions and custom rules if we leave?
8. Pricing schedule
| Line | What the bidder must state |
|---|---|
| AST-COM-01 Licence metric (M) | Unit (contributing developers, applications, scans, targets or lines of code) and how it is counted, including bots, contractors and inactive contributors. |
| AST-COM-02 Subscription (M) | Price for years 1 to [3] at current scale and [150%] growth, each testing type itemised. |
| AST-COM-03 Scan limits (M) | Any cap on scans, concurrency or DAST targets, and the price of exceeding it. Per-scan pricing that discourages scanning every pull request should be stated plainly. |
| AST-COM-04 Services (M) | Onboarding, tuning and training with day rates. |
| AST-COM-05 Exit (S) | Export of findings, suppressions and custom rules in documented formats at no cost. |
9. Evaluation method and proof of concept
Responses are scored in two stages: the written response, then a proof of concept for the [two or three] highest scoring bidders. Any mandatory failure excludes the bid. Scored requirements are rated 0 to 5 and multiplied by the area weight.
| Area | Illustrative weight |
|---|---|
| Accuracy and coverage on [Organisation]'s code (4.1 to 4.5) | [30%] |
| Developer experience and CI fit (4.6) | [20%] |
| Policy, output and reporting (4.7, 4.8) | [15%] |
| Platform security and data handling (5) | [15%] |
| Services and pricing (6, 8) | [20%] |
Proof of concept script, run on [Organisation]'s repositories and applications over [three to four weeks]:
- Seeded repositories: the panel plants known flaws (for example injection, path traversal, insecure deserialisation, a vulnerable reachable dependency, a test secret) in copies of [three] real repositories in different languages. Count true positives, false positives and missed flaws per engine.
- Benchmark: run SAST and DAST on the same OWASP Benchmark release for every bidder and compare true and false positive rates as one input, not the decision.
- Pull request experience: open [ten] real pull requests; measure scan time, comment quality and how many findings developers judge actionable.
- Authenticated DAST: scan [one application] behind SSO with two roles; confirm coverage of authenticated pages and an authorisation test between the roles.
- AI fixes (if offered): review [ten] generated fixes for correctness, behaviour change and new dependencies.
- Gate: introduce a new critical finding and confirm warn, then block, then a logged override.
- SARIF: import results into [aggregation tool or code scanning platform] and confirm fingerprints stay stable across two runs.
- Permissions: compare the source control and pipeline permissions actually granted with AST-PLT-01 and AST-PLT-02.
Implementation guidance
This section is for the evaluation panel and is not issued to bidders.
Before you issue
- Write the coverage workbook: every language, version and framework you ship, weighted by how much code is internet-facing. This is the basis for AST-SAST-01.
- Build seeded repositories: copies of real code with planted flaws and a list of true answers. This is the most useful artefact the panel can create.
- Agree the CI time budget with engineering: developers' tolerance for pull request scan time decides whether full scans can gate merges.
- Decide where findings live: in the scanner's portal, in source control code scanning, or in an aggregation platform. This decides how much weight SARIF and API output deserve.
- Count your licence units: contributing developers, bots and contractors in your own source control before bidders count them for you.
Choosing between approaches
| Approach | Fits when | Trade-off |
|---|---|---|
| Single platform covering most testing types | One source control platform, a small AppSec team, need for one developer experience | Some engines will be weaker than specialists |
| Best-of-breed engines per technique | Large estate, several business units, specialist needs (mobile, legacy languages) | Needs aggregation and deduplication; more contracts and integrations |
| Native source control security features plus targeted DAST | Most code on one platform that offers built-in scanning | Coverage limited to that platform's languages and engines |
Small organisations should weight developer experience and pricing higher and can make IAST and custom rules informational. Large organisations should weight language coverage, SARIF output, policy per tier and platform security most heavily.
Common failure patterns
- Testing on the bidder's sample application: results do not transfer to your frameworks. Always use seeded copies of your own code.
- Scoring finding counts: more findings usually means more noise. Score true positives found and false positives avoided.
- Blocking on day one: developers route around gates. Start in audit mode and block on new critical findings per tier.
- Personal access tokens for integration: a scanner integrated with one engineer's broad token fails when they leave and is a prize if leaked.
- Following a mutable scanner tag in CI: a tampered release then runs with access to pipeline secrets.
Lessons from incidents
In a 2026 supply chain incident, a widely used vulnerability scanner's release tags were rewritten to point to a malicious release. The poisoned scanner ran in a downstream project's CI pipeline with access to environment variables, exposed that project's package publishing token, and the attackers used it to publish credential-stealing package versions. Read the breach analysis. Requirements AST-PLT-02 and AST-PLT-03, and the last failure pattern above, address exactly this path.
Framework alignment
| RFP area | Reference |
|---|---|
| 4.1 to 4.5 Testing types and accuracy | NIST SP 800-218 SSDF practice PW.7 (review code) and PW.8 (test executable code); NIST SP 800-53 SA-11, RA-5; NIST CSF 2.0 PR.PS-06, ID.RA-01; OWASP ASVS 5.0 as the verification baseline; OWASP Web Security Testing Guide v4.2 |
| 4.2 SCA and SBOM | NIST SP 800-53 CM-8; CycloneDX, SPDX |
| 4.7 and 4.8 Gates, output and reporting | SARIF 2.1.0; SSDF practice group RV (respond to vulnerabilities) |
| 5 Platform security | NIST SP 800-53 AC-6, AU-2, SR-6; NIST CSF 2.0 GV.SC-05, GV.SC-06 |
Standards and references
- NIST: SP 800-218 Secure Software Development Framework Version 1.1
- OWASP: Application Security Verification Standard 5.0
- OWASP: Web Security Testing Guide
- OWASP: Benchmark Project
- OASIS: Static Analysis Results Interchange Format (SARIF) Version 2.1.0
- OWASP: API Security Top 10 2023
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Application Security Testing Buyer's Guide · ASPM RFP Template · Security Vendor Evaluation and RFP Guide · SAST Triage Guide · DevSecOps Guide