# What Makes a Vulnerability Report Excellent > Source: > Published: 2026-06-30 15:48:02+00:00 # What Makes a Vulnerability Report Excellent curl maintainer Daniel Stenberg has triaged 1,000+ vulnerability reports. His field guide on reporting well is the other half of safe harbor — and the antidote to AI-generated slop. *Cross-posted with commentary. The original — "Do excellent vulnerability reports" by Daniel Stenberg — is well worth reading in full.* A huge amount of what we do at disclose.io is about one half of the disclosure handshake: making it **safe** for a researcher to walk up to an organization and say "here's a problem." Safe harbor, clear policy, a published point of contact — all of it exists to lower the cost of doing the right thing. But there's a second half, and it gets talked about far less: once you've got a safe channel to report through, **report well**. Daniel Stenberg — who maintains curl and has personally handled over a thousand vulnerability reports — just published a field guide on exactly that, and it's the clearest short version we've seen. ## What he's saying Stenberg's framing is blunt and correct: most maintainers are overloaded volunteers, and a vulnerability report lands as *work* on someone else's desk. The best researchers minimise that work. His checklist, in short: **Open with the point.** A few sentences up front: what the problem is and why it matters. Don't make the reader excavate it.**Include a reproducer.** Standalone, runnable code that demonstrates the issue beats any amount of prose.**Offer a patch**— even an imperfect one. As he puts it,*"getting 80% towards the target is still valuable."***Pin the versions.** Where you found it, and the earliest version affected. Teams need this to write the advisory.**Use the front door.** Follow the project's stated reporting method; don't route around it.**Confirm it's real** before you send — not documented, intended behaviour.**Stay in the conversation.** Be available for follow-ups on severity, scope, and the advisory wording.**Sound like a human**— even (especially) when AI helped you find it. His one-line thesis: *"Make your report as easy as possible for the team to manage."* ## Our take Two things make this land for us. **First, it's the other half of safe harbor.** We spend a lot of breath arguing that organizations should protect the people who report to them. The reciprocal is just as real: a researcher who sends a tight, reproducible, good-faith report is protecting the *maintainer's* time and attention. That mutual consideration is the whole game. The internet's immune system only works when both sides hold up their end — policy that welcomes the report, and a report that respects the person receiving it. **Second, the "sound like a human" point is quietly the most important one right now.** AI has made it trivial to *generate* something that looks like a vulnerability report. Maintainers across open source are drowning in confident, well-formatted, completely wrong submissions — the curl project has been one of the loudest voices about exactly this. As the cost of producing a report falls to zero, the signal that matters is no longer formatting; it's whether a competent human stands behind it, has actually reproduced the issue, and will stay in the conversation. Stenberg's checklist is, read one way, a list of the things AI slop reports consistently fail to do. If you're building or refining a disclosure program, this is a useful companion piece: your [VDP tells researchers how to report](https://disclose.io/?ref=blog.disclose.io); guidance like Daniel's tells them how to report *well*. The two meet in the middle, and that's where good outcomes actually happen. **Read the full post:** [Do excellent vulnerability reports — daniel.haxx.se](https://daniel.haxx.se/blog/2026/06/29/do-excellent-vulnerability-reports/?ref=blog.disclose.io)