How to make a coverage statement a buyer can verify

A buyer can verify a security coverage claim when it names the application and revision, the source and behavior actually assessed, the versioned requirements, the methods used, the exclusions, the result status and the evidence available for review. “Scanned 100% of code,” “OWASP covered” and “no vulnerabilities found” lack those boundaries. The answer changes if the assessment was partial or source-only: say that directly, and identify what additional evidence would support the buyer’s question. OWASP’s ASVS assessment guidance stresses communicating scope and approach; the Top 10 is an awareness starting point, not proof that an application passed ten tests.

The statement should let a procurement or security reviewer challenge it without needing raw customer source. A CTO should be able to trace each public sentence to a private evidence record, and should be willing to narrow the sentence when that record is missing.

A claim is a chain, not a badge

A credible statement has six links:

1. Binding: the named product, environment or release and immutable source or artifact revision.
2. Scope: components, routes, data flows and shared controls included, with exclusions and inventory limits.
3. Criteria: versioned security requirements or precisely described questions, including applicability decisions.
4. Method: source review, configuration inspection, architecture review, controlled runtime validation or a combination.
5. Outcome: what was checked and supported, what failed, what remains unresolved, and who reviewed it.
6. Evidence access: where an authorized buyer or independent reviewer can inspect the record without receiving secrets or other customers’ private material.

If one link breaks, narrow the claim. A source-only assessment can support “these paths were reviewed at this commit for these issues,” but it cannot establish all deployed controls or certify the application. Indexing every file does not show that every requirement was examined. A clean result in a chosen path is not evidence that all possible vulnerabilities are absent. OWASP separates ASVS security requirements and verification levels from testing methods such as those in the Web Security Testing Guide.

Illustrative ASVS example: rewrite a claim a buyer cannot check

Illustrative case; names, revision and findings are invented. Fern Ledger sells a multi-tenant SaaS service. Its sales draft says: “Our scanner covers OWASP ASVS Level 2 and found zero cross-tenant vulnerabilities.” The underlying review inspected the invoice API source at commit F12A6. The reviewer traced the detail and list endpoints and the shared authorization helper. The export worker’s deployed revision was unavailable, and object delivery policy was not supplied. No controlled cross-account check was performed.

The broad sentence fails at scope, method and outcome. It equates a review of selected source paths with assessment of an entire ASVS level. It treats “no verified issue in the reviewed API paths” as “zero vulnerabilities” across workers and production configuration. It also obscures an important buyer concern: can a normal user retrieve another customer’s invoice?

The CTO and AppSec lead replace it with this:

Fern Ledger assessment statement — illustrative. At source commit F12A6, our AppSec reviewers examined the invoice detail and list API paths and the shared authorization helper for object-level and cross-tenant access rules mapped to OWASP ASVS 5.0.0 requirements v5.0.0-8.2.2 and v5.0.0-8.4.1. No verified failure was established in those reviewed API paths. The export worker and production object-delivery policy were not assessed, and no controlled runtime validation was performed. We therefore make no claim that invoice export, the production deployment or ASVS Level 2 as a whole passed. The worker and platform owners are supplying the missing evidence for a separate decision.

Those two requirement IDs point to the pinned ASVS 5.0.0 Authorization chapter. The new statement does not assert that the application is safe; it tells the buyer what can be checked. A private reviewer packet can contain the pinned manifest, scope policy, obligation record, source references and counterevidence, with access controlled to the right people. The public or executive version need not reveal exact vulnerable paths or proprietary code.

Use this checklist before sending a buyer a statement

Can the buyer identify the thing assessed? State product or service, environment and immutable revision. If code was reviewed but production artifact mapping is missing, say “source at commit X” and leave production applicability unresolved. Do not say “our platform” if the assessment covered only one service.

Can the buyer tell what was included? Name important flows and shared controls in plain language. A route list can live in a controlled appendix, but the statement should say whether background jobs, mobile clients, APIs, infrastructure and external services were in scope. Record whether the inventory itself was complete.

Can the buyer find the criterion? Use a versioned ASVS identifier, such as v5.0.0-8.2.2, or another exact control reference. “OWASP” alone could mean the Top 10, ASVS, a testing guide or a cheat sheet. If only a category was used to organize work, label it as a category rather than a passed requirement.

Can the buyer distinguish methods? State whether the team inspected source, reviewed configuration, discussed architecture, observed behavior in a controlled environment or used an automated rule. If an authorized runtime check was performed, name the environment and the selected behavior without implying every path was exercised. A scanner may find a lead; independent verification and review are needed before calling it a confirmed issue.

Can the buyer see the unresolved work? List material exclusions, unavailable evidence, incomplete work units and decisions awaiting an owner. Group minor omissions sensibly, but never bury one that could reverse the conclusion. A missing alert, inaccessible file or failed parser is not a pass. Use a separate internal exclusions record so the summary can remain readable.

Can the buyer tell the result from the effort? “12,000 files indexed” is an activity measure. “Three authorization obligations evaluated for the API; two reviewed without established failure, one unresolved” is a decision record. Report approved findings and their status separately from requirement coverage. Rejected claims and unconfirmed estimates should not be counted as confirmed vulnerabilities.

Can the buyer inspect supporting evidence safely? Offer an evidence register, assessment date, reviewer role, scope policy, versioned requirement matrix and accountable assessment summary through the organization’s normal access process. Mark which conclusions came from vendor staff, automation or an external assessor; separate authorship from independent review. Do not paste customer source, tokens, private reports or precise exploit instructions into a public page. If an independent assessor is involved, identify their actual role and method; do not imply external assurance from an internal review.

Can the statement survive a release? Define when it expires or requires reassessment: a major code change, new customer role, altered gateway policy, migration, new worker or changed deployment. Keep historical statements bound to their original revision. A new commit does not inherit the old result merely because a scanner job completed.

Let the buyer challenge one mismatched receipt

Fern's next synthetic statement draft names release F13 and claims the export worker was assessed. The buyer receives a restricted five-item index, not raw source:

The buyer's useful challenge is: “B4 is for W12 while the claim names W13. What evidence carries the worker conclusion forward?” They do not need the proprietary implementation to detect that mismatch.

The vendor first checks whether W13 differs only in packaging or whether the relevant worker path changed. In this example, the delegation adapter changed, so the old receipt cannot be inherited without reassessment. The vendor narrows the sentence immediately: “The API paths were reviewed at F13; the worker receipt concerns W12. The W13 delegation adapter and production delivery boundary remain under review.” The old receipt remains valid historical evidence for its own scope.

The buyer cannot receive raw source under the agreed access rules. The vendor offers a redacted assessor summary identifying the method, exact build, selected obligations, counterevidence considered, unresolved limits and approval role. This permits a useful challenge while preserving confidentiality. A vendor-authored summary must not be described as an independent assessor's attestation unless that is true.

The final claim register controls republication:

“Expires” here means the statement cannot be reused for a changed subject without checking it. Historical claims remain bound to their original release. The CTO approves the externally visible sentence only after its evidence index and limits agree; a new scanner job does not grant republication automatically.

Give the buyer a claim they can copy accurately

A technically precise appendix will not help if the procurement summary reduces it to “ASVS checked.” Provide a short approved sentence that carries its own boundary: the named API source paths were reviewed at F13 for selected authorization questions, while the W13 worker and production delivery remain under review. The buyer can place that sentence in an internal decision memo without needing to reconstruct the evidence packet.

Offer a separate explanation of what would change the statement. In Fern's case, matching worker evidence and the production delivery review would permit a broader claim for those paths. They would still not establish full Level 2 achievement. This gives the buyer a finite request and prevents a later partial update from being read as completion of every previously excluded area.

Keep the evidence route usable after procurement. Name the team that can answer a question about the statement, retain the report identifier, and make changed releases easy to distinguish. If a buyer receives an older packet, its historical scope should be apparent. The vendor can then provide the current scoped update instead of pretending every old assurance remains current.

A good coverage statement reduces unnecessary disclosure as well as exaggeration. The buyer can challenge mismatched subjects, unsupported methods and omitted paths from a redacted index. Raw source is needed only when the agreed review method calls for it and the disclosure is authorized.

Phrases to retire and their honest replacements

Take one sentence from your current security questionnaire and find its binding, scope, criterion, method, outcome and evidence record. If any is missing, narrow the sentence before sending it. The monorepo measurement guide supplies defensible counts, and the Top 10 planning guide helps turn an awareness category into a checkable question.