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; 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