What evidence belongs in a security finding?
Build findings that engineering can verify and fix. Keep the affected behavior, expected policy, version, impact, and uncertainty connected.
A security finding should let an authorized engineer understand the defect, locate the affected behavior, and verify the fix. A screenshot with a dramatic title is not enough. Connect the observed result to the expected policy and the exact version reviewed.
Use the smallest evidence set that establishes the issue. Prefer synthetic records. Do not collect more customer data to make a report look convincing. The OWASP reporting guidance provides a useful reporting framework; the checklist below is a proposed evidence record for an application team.
What should each finding contain?
| Field | What it establishes |
|---|---|
| Scope reference | Why this asset and test were permitted |
| Build or snapshot | Which version the observation concerns |
| Actor and role | The caller's legitimate permissions |
| Object ownership | The boundary the action should respect |
| Expected result | The policy or requirement being tested |
| Observed result | The behavior actually recorded |
| Evidence references | Redacted records that support the conclusion |
| Impact and limits | What follows from the evidence, and what does not |
| Remediation | The control that must change |
| Retest conditions | How to check the repair |
Keep factual observations and interpretations separate. “The response contained the synthetic tenant B record” is an observation. “Every customer's entire dataset is exposed” is a broader claim that needs additional support and may exceed the permitted test.
How do you challenge the finding?
Check for alternative explanations. Was the account intentionally a member of both organizations? Was the record shared publicly? Did a cached response belong to an earlier authorized session? Was the deployed build different from the source snapshot?
Resolve these questions using approved evidence. An independent reviewer should be able to inspect the evidence without relying only on the first reviewer's conclusion. Agreement between two models or two people does not replace the underlying record.
If an evidence file is missing, state that limitation. Do not reconstruct an exact response from memory or invent a request identifier.
What does engineering need next?
Point to the permission or data-handling decision that failed. Avoid prescribing a superficial fix, such as hiding a button, when the server must enforce the rule.
Include a legitimate allow case in the retest plan. A fix that denies all users may remove the observed symptom while breaking the product. After repair, record the new build and the result of both cases.
Contact Sourced to discuss a review with evidence and a practical remediation handoff. Share sensitive findings only through a channel agreed for that purpose.
Know what you will get from a review
Explore an illustrative finding with evidence, a proposed fix and retest criteria. Discuss your systems, review questions and deadline when you are ready.