Security Research 101, Part 6: Make the Report, Then Coordinate

Finding a vulnerability is only half the job. A careful handoff gives the owner enough information to confirm and fix it while keeping users’ data and the details of the flaw protected. ## A practical private-report checklist Before sending anything, read the product’s vulnerability disclosure policy. Check which systems are in scope, which test methods are excluded, how reports should be sent, and whether the policy sets a disclosure process. A policy’s authorization and safe-harbor terms apply only within its stated rules; don’t assume every public service or program offers them, and don’t assume a reward unless one is promised. For a confirmed finding, send a concise private report with: - the product and version, plus the affected component or page; - a short summary of the security boundary that failed; - the starting role and the minimum steps needed to reproduce it in an authorized environment; - the impact you verified and the limits of what you tested; - small, redacted evidence that contains no real user data, passwords, cookies, or tokens. Ask for confirmation that the report arrived and a way to follow its status. Then coordinate on next steps and a reasonable disclosure timeline. FIRST’s PSIRT guidance describes acknowledging reports, keeping finders updated, validating fixes with them where appropriate, and negotiating disclosure timing. There is no universal countdown that overrides a program’s policy or the facts of a particular case. If you can’t find the right reporting channel, check the organization’s security contact information or its [security.txt file](https://www.rfc-editor.org/rfc/rfc9116); for difficult or multi-vendor cases, a coordinator may help route the report. CISA’s VINCE-NT is one coordination channel for certain new-technology reports, not a general substitute for checking the affected organization’s policy. Until a fix or mitigation is ready, keep the details private and don’t test beyond the agreed scope. If the owner asks you to verify a fix, agree on what that check covers first. Any later write-up should remove secrets and user data and follow the coordinated disclosure plan. Sources: [FIRST: PSIRT Services Framework](https://www.first.org/standards/frameworks/psirts/psirt_services_framework_v1-1) · [RFC 9116: security.txt](https://www.rfc-editor.org/rfc/rfc9116) · [CISA: VINCE-NT reporting](https://vulnerabilities.cisa.gov/cvdp/report/) Continue from [Part 1](https://www.mushimu.com/post/9177), [Part 2](https://www.mushimu.com/post/9178), [Part 3](https://www.mushimu.com/post/9179), [Part 4](https://www.mushimu.com/post/9182), and [Part 5](https://www.mushimu.com/post/9186). ~cybersecurity