A security assessment coverage report should show the scope that was intended, what was actually examined, what evidence supports each conclusion, and which material areas remain unknown. Put the denominator beside every fraction. A list of reviewed files, a count of completed checks, and the number of findings answer different questions; none alone measures whether an application is safe. When inventory is incomplete or a production control was not observed, put that limitation in the decision summary rather than burying it in an appendix.
For a security leader, the report's job is to support a decision: release, investigate, contain, or fund more review. The answer changes when the application revision, deployment, selected scope, methodology, or evidence changes. A review of last month's commit cannot quietly stand for today's deployment.
Start with the decision the report must support
An executive may ask, “Did we assess the customer portal?” That question contains at least four smaller ones. Was the portal in scope? Did the team obtain its complete source at a pinned revision? Which important behaviors were examined? Were deployment and runtime assumptions checked? The report should answer each explicitly.
Use this opening block before charts or finding counts:
| Field | What to write |
|---|---|
| Decision and owner | The action required now and who can authorize it |
| System and revision | Named application, included repositories and immutable revisions |
| Assessment window and method | When work ran; code review, automated analysis, runtime testing, or a stated combination |
| Scope promise | The components, sensitive workflows and requirements selected before work began |
| Actual examination | What source, configuration, controls and relevant evidence a reviewer examined |
| Open findings | Evidence-supported, unresolved issues accepted under the stated review criteria; identify independent review where performed and keep candidates separate |
| Unknowns | Missing files, unreviewed paths, ambiguous applicability, runtime assumptions and stale evidence |
| Next checkpoint | Who will collect missing evidence and when the decision will be revisited |
NIST's Secure Software Development Framework treats software verification and vulnerability response as practices within a wider development process. A coverage report is an evidence record for a defined assessment, not a certificate that those practices or an entire application are complete. OWASP ASVS gives teams a structured verification standard; listing an ASVS requirement beside a finding does not establish that the requirement was fully tested or passed.
Use a coverage ledger with separate denominators
Count work at each stage independently. Discovered means the inventory found the file or component. Acquired means its content was available. Indexed means a tool could navigate it. Examined means a reviewer or defined check actually inspected relevant evidence. A search hit in an index is not the same as reviewing the surrounding authorization control. A test file excluded from the main review may still contain a relevant test of that control, so record its role and reason rather than silently dropping it.
For a source assessment, report at least these four measures:
- Inventory completeness: discovered repositories or subtrees divided by the known intended inventory. If the total inventory is unknown, say so; do not show a completion percentage.
- Source handling: acquired and eligible files divided by discovered files, with exclusions by reason. A language parser failure, oversized file, symlink, generated code and unavailable dependency are different limitations.
- Review depth: examined selected workflows or requirement/component obligations divided by selected obligations. State what “examined” required. A file-count ratio may help explain effort but should not be labeled security coverage.
- Review progress: reviewed, partial, blocked, not started and outside selected scope. Keep applicability unknown distinct from not applicable; keep findings distinct from review state.
The denominator must be tied to a scope statement and date. If a new service is discovered after planning, update the denominator and explain the change. Do not preserve a flattering percentage by leaving the new service out. OWASP SAMM's defect metrics guidance calls for both defect and verification activity information, including coverage of verification for components. This is why a report with only a finding count cannot answer how hard the team looked.
Filled report: a targeted account-service assessment
Illustrative case; all names and numbers are invented. No exploit was performed. A B2B software company asks whether an account service can move to a new release. Its security team reviews the account-api repository at immutable revision r42, focusing on sign-in, account switching, and customer-record authorization. The review does not include the separate billing service or mobile client.
Decision requested: Decide whether the release must wait for containment of one approved open finding and review of two unresolved authorization controls. Decision owner: Head of Security with the engineering release owner. Assessment date: 18 October 2026. Scope: one repository and 12 selected workflow/control obligations. Method: source and configuration review; no penetration test or production traffic exercise.
Inventory: repository listing complete for the pinned revision. Of 120 discovered files, 110 were eligible for this assessment, 110 were acquired, 110 indexed, and 64 contained source or configuration actually examined for the selected workflows. Ten excluded files were generated artifacts; exclusion was recorded. The 64/110 file ratio describes examined material, not the fraction of vulnerabilities detectable.
Control review: 7 of 12 selected obligations reviewed; 2 partial because a shared policy path needs confirmation; 1 blocked by unavailable deployment configuration; 2 not started. These categories total 12. The result is 7/12 selected obligations reviewed, not “58% secure” or “58% ASVS compliant.” One approved open finding affects customer-record access. Two scanner candidates remain under investigation and are absent from the approved finding count.
Material unknown: a production data-layer policy could change the interpretation of one unresolved candidate; the team has not yet checked that policy in the deployed environment. The billing service and mobile client were outside this assessment. Next action: service owner contains the approved finding; platform owner supplies the policy version and deployment record by 20 October; AppSec reviews the two partial obligations; security leader revisits release conditions afterward.
Notice the report does not hide a serious unknown behind “one open issue.” It also does not call the approved source-supported finding an observed customer data disclosure. A technical appendix can retain exact code and policy references for authorized reviewers; the decision summary states the harmful action, condition, and missing evidence in plain language.
Open the twelve rows behind the headline
These are the selected obligations in the fictional assessment. They are local workflow descriptions, not ASVS requirement identifiers or a claim of standards conformance. “Reviewed” means the selected evidence was examined; it can include a failed control and an approved finding.
| ID | Workflow/control obligation | State at 18 October | Result or missing evidence |
|---|---|---|---|
| O01 | Sign-in rejects an invalid credential | Reviewed | Selected source path supports rejection |
| O02 | Sign-in creates session context for the authenticated identity | Reviewed | Session provenance traced |
| O03 | Sign-out invalidates the selected session | Reviewed | Relevant session-store path examined |
| O04 | Customer-record read binds record to current account | Reviewed | Approved finding AR-4: direct lookup lacks the required boundary |
| O05 | Customer-record update checks the caller's capability | Reviewed | Checked route enforces the selected capability |
| O06 | Account member list is restricted to that account | Reviewed | Scoped lookup and caller examined |
| O07 | Invite creation checks the selected inviter role | Reviewed | Selected role path traced |
| O08 | Account switching derives current account from authorized membership | Partial | Shared policy evaluator obtained; caller/context wiring not established |
| O09 | A queued export uses the correct account context after a switch | Partial | Worker-to-policy binding missing |
| O10 | Deployed data-layer policy constrains direct lookup candidate C2 | Blocked | Effective policy and revision mapping unavailable |
| O11 | Recovery flow invalidates the selected prior session state | Not started | No evidence examined in this assessment |
| O12 | Privileged support access follows its separate authorization rule | Not started | Owner and assessment slot pending |
Seven reviewed rows, two partial, one blocked and two not started reproduce the report. O04 also demonstrates why “reviewed” cannot be converted to “passed.” The 64 examined files can support several obligations; counting a file once does not tell you how many control claims were settled.
The release concern is specific. O08 governs whether an account switch creates trustworthy context. O09 determines whether later queued work uses the intended account. Both could change the safety of the release's central workflow. By contrast, the ten generated artifacts are excluded from this source-review unit because their maintained inputs are in the acquired material; that is an inventory explanation, not permission to ignore unknown runtime behavior. If the generated output introduces behavior absent from those inputs, the exclusion must be revisited.
Show what changes when the blocked evidence arrives
On 20 October, the platform owner supplies the effective data-layer policy, its deployment mapping and the relevant caller record. In this constructed continuation, AppSec establishes that candidate C2's direct lookup is subject to a mandatory account predicate. C2 is rejected for the assessed path. O10 advances from blocked to reviewed. That policy does not cover AR-4's different storage path, so the approved finding remains open.
The revised first-page block should be short:
20 October update: Control review is now 8/12 reviewed, 2 partial, 0 blocked, 2 not started. The deployed policy resolves O10 and defeats candidate C2; candidate C3 remains under investigation. Approved finding AR-4 remains open. O08 and O09 are still incomplete, so the release condition for account switching has not been met. The platform evidence reduces one uncertainty but does not authorize the release by itself. AppSec and the service owner return with the account-switch and queue bindings at the next checkpoint.
The file count need not rise: the new material is an external policy and deployment record, not another repository file. Keep the evidence ledger linked to O10 without inventing additional examined files to make the measures move together.
Now the reader can see exactly why coverage improved while the release decision stayed the same. The remaining gap concerns the proposed feature, and the existing finding concerns a separate path. A dashboard showing only “67% reviewed, one candidate dismissed” would conceal both reasons.
Turn the report into a release conversation
Ask the engineering owner to confirm the deployed revision and any control that lives outside source. Ask AppSec to identify which selected obligations were actually reviewed and whether an approved finding has positive source evidence. Ask the decision owner to state what residual risk is acceptable until the next checkpoint. If the release proceeds, record the condition and deadline; if it pauses, record what evidence would unblock it. The NIST Cybersecurity Framework 2.0 frames cybersecurity as risk management and communication, which is the purpose of this decision record.
The report should be versioned. A later scan can add evidence, but it should not rewrite what the earlier assessment knew. If a fix is merged, require a reassessment of the original path at a new immutable revision before marking the finding fixed. If the later review cannot inspect a required control, the result remains inconclusive. Likewise, zero findings in a partially examined scope are zero approved findings observed in that scope, not evidence of zero vulnerabilities.
For the next report, take one high-value repository and fill the eight-field opening block. Require the reviewer to supply a denominator for every coverage fraction and one sentence for every material unknown. Then use the first-assessment scope guide to choose the next bounded review, or the cross-repository comparison method when leadership asks which system needs attention first.