Read a security-testing report
Review coverage, evidence, impact and limitations, then turn an annotated fictional security finding into an actionable remediation task.
Read the scope and limitations before counting the findings. A short list may describe a well-protected service, a narrow engagement or a test blocked by missing access. The report should let you distinguish those situations.
Then examine whether an engineer can act on each finding and whether a business owner can understand the consequence. OWASP's reporting guidance separates executive communication from the evidence and remediation detail needed by technical readers. It presents a suggested structure, not a universal mandatory template.
Review the report in three passes
First, check what the conclusion covers. Identify the service, release, dates, tested roles and included functions. Compare these with the approved scope. Note accounts that did not work, excluded dependencies and functions that changed during testing.
Second, examine the important findings. For each one, locate the observed behaviour, affected assets, required access, likely consequence and proposed remedy. Distinguish the tester's observation from an inference about wider impact.
Third, turn findings into owned decisions. Confirm who will investigate or fix each issue, what additional evidence is needed and how the change will be verified. The test report can support those decisions; it does not assign your organisation's business priorities automatically.
Annotated fictional finding
This original example concerns a service built for illustration. The named accounts and records are synthetic; it is not a report of a vulnerability in a real organisation.
| Report element | Example content | What the reader should check |
|---|---|---|
| Reference and title | HWP-04: a customer can retrieve another test customer's attachment | A stable reference connects the report, engineering work and retest |
| Asset and version | Customer portal release candidate 2.4; attachment-download function | Enough detail to identify the tested implementation |
| Preconditions | Authenticated ordinary customer account; two authorised test tenants with synthetic attachments | The access required is explicit |
| Observed behaviour | The tester's first account received the second test tenant's synthetic attachment through an agreed check | The claim describes what was demonstrated, without implying that real customer records were accessed |
| Evidence | Redacted request/response record, test-account IDs and timestamps in the restricted evidence store | Engineers can reproduce the issue in the authorised environment without sharing secrets widely |
| Impact | A broken customer boundary could disclose attachments belonging to another customer if the same condition exists in production | Conditional wider impact is separated from the staging observation |
| Severity | High under the provider's documented method | The rating has a stated method and rationale |
| Remediation | Enforce the caller's entitlement to the requested record on the server, consistently across attachment access paths | The recommendation addresses the control, not only the visible interface |
| Verification | Repeat the original test and check an agreed set of adjacent access paths with synthetic records | The reader can identify the evidence needed to close the finding |
A screenshot of the attachment is not enough on its own. It may show what appeared on screen while omitting the account, environment and exact conditions that produced it. Ask for a safe reproducible record appropriate to the audience.
Separate observation, inference and uncertainty
For HWP-04, “the first test account retrieved a second tenant's synthetic attachment” is an observation. “The same flaw may affect other attachment routes” is a hypothesis to investigate. “Every production attachment has been exposed” would be an unsupported conclusion on this evidence.
The distinction changes the next step. Engineers can address the confirmed control failure while the service owner checks production applicability and any need for incident triage. Avoid delaying necessary action solely because the full extent is not yet known, but keep unverified claims clearly labelled.
Read severity scores correctly
If a report uses CVSS, ask for the version and vector as well as the number. FIRST's CVSS v4.0 user guide states that the Base score describes severity and should not be used alone to determine risk. Environment and threat context matter.
A “high” label without a definition is hard to compare across providers. A documented score is more useful, but still needs your service context: exposure, affected data, compensating controls, observed exploitation and recovery implications. Keep the technical assessment and the organisation's prioritisation decision visible rather than silently editing one into the other.
Ask these questions at the report readout
- Which parts of our original objective remain unanswered, and why?
- Which findings are demonstrated and which require further validation?
- Could one underlying cause explain several findings?
- Are recommendations precise enough to implement without guessing?
- Which urgent issues need an immediate interim action?
- What change or evidence would alter a finding's conclusion?
- What will the retest examine, and what will it leave untested?
Restrict the report and detailed evidence to people who need them. Provide leadership with an appropriate summary rather than circulating credentials, personal data or detailed attack paths in ordinary status emails.
Convert the finding into a work item
For HWP-04, a useful ticket names the service owner, release identifier, engineering owner, agreed interim control and closure test. It links to the restricted evidence instead of copying it into every tool. It also records related routes to inspect and the person who can accept any remaining risk.
Use prioritising remediation for the backlog decision and retesting for a defensible closure record.
Sources and further reading
- OWASP Web Security Testing Guide v4.2: Reporting — checked 2 November 2026
- FIRST: CVSS v4.0 User Guide — checked 2 November 2026