Write the report
Produce a concise security record that separates observed evidence, bounded impact, uncertainty, and remediation.
This is the complete downloadable file. Open plain text ↗
---
name: report
description: "Produce a concise security record that separates observed evidence, bounded impact, uncertainty, and remediation."
---
# Write the report
Produce a concise security record that separates observed evidence, bounded impact, uncertainty, and remediation.
Defensive study and review of artifacts supplied by their owner. Record missing evidence as an open question.
## Bring to the review
- Authorized observations
- Affected boundary and policy expectation
- Vendor or primary-source remediation context
## Review guide
### 1. State the boundary
Name the intended security property, who or what it protects, and the precise condition that did not hold.
### 2. Separate evidence from inference
Mark direct observations, reproduced local results, modeled impact, and unanswered questions distinctly.
### 3. Minimize sensitive material
Use owned, redacted evidence that lets maintainers understand the issue without exposing unnecessary data or instructions.
### 4. Make the fix testable
Recommend a control and a regression assertion tied to the failed invariant.
## What to produce
- Evidence-bounded finding
- Impact and uncertainty statement
- Testable remediation criteria
## Common mistakes
- Claiming impact beyond evidence
- Including secrets or third-party data
- Describing a fix without a security invariant
## Reading and source context
### Resources
- [Quality Reports](https://vulns.co/research/resources/hackerone-quality-vulnerability-reports/)
- [OWASP Logging: trustworthy and minimal application evidence](https://vulns.co/research/resources/owasp-security-logging-evidence-quality/)
- [OWASP Secure Code Review: baseline and change-focused review](https://vulns.co/research/resources/owasp-secure-code-review-methodology/)
### Diagrams
- [Approval stays attached to the reviewed version](https://vulns.co/research/diagrams/approval-version-integrity/)
### Reports
- [Cloud Build approval was not bound to immutable code](https://vulns.co/research/reports/google-cloud-build-approval-toctou-2025/)
- [GitHub Actions trust depended on invalid repository references](https://vulns.co/research/reports/github-actions-reference-validation-2021/)
## Provenance
Editorial guide by vulns.co / GK Data. Updated 2026-10-11.
Library snapshot: 2026-10-04; commit d5550c7891119cf1379e235721541c947850a3b3.
The guide is an editorial synthesis. Linked records preserve their own sources and review dates.
Reader: https://vulns.co/skills/report/
The review
What to look for
Defensive study and review of artifacts supplied by their owner. Record missing evidence as an open question.
State the boundary
Name the intended security property, who or what it protects, and the precise condition that did not hold.
Separate evidence from inference
Mark direct observations, reproduced local results, modeled impact, and unanswered questions distinctly.
Minimize sensitive material
Use owned, redacted evidence that lets maintainers understand the issue without exposing unnecessary data or instructions.
Make the fix testable
Recommend a control and a regression assertion tied to the failed invariant.
What to produce
- Evidence-bounded finding
- Impact and uncertainty statement
- Testable remediation criteria
Common mistakes
- Claiming impact beyond evidence
- Including secrets or third-party data
- Describing a fix without a security invariant
Continue the study
Reading & source context
Editorial notes above connect these references. Open each record for its original source and review date.
Visual models
Connected disclosures
From the field toolkit
Guide by GK Data · Research snapshot 2026-10-04.
Sources and review dates are preserved in the library provenance.