Hope @mttaggart doesn’t mind me stealing the format but Zachs Newletter ( Zack Whittaker: "New by me: I analyzed the websites of America's t…" - Mastodon ) got me thinking:
What is everyones experience with Vulnerability Disclosure Program from the inside, not as a reporter?
Does your org have one? If you have one how did it come about, how do you run it, what issues were encountered & what mistakes were made? If you don’t have one whats blocking it or is it an intentional choice?
I’ll already provide my experiences - for perspective: Working at a medium-to-large international non-IT company with a couple of customer-facing webservices & a couple of mobile apps.
We introduced a VDP 2-3 years ago. The entire project was driven by an enthusiastic employee with pentest/red team experience & comprises a published policy, a form-based reporting portal (custom development), and a Hall of Fame. Management was very happy to support the project as long as it costs little/nothing, so bounties were out of the window. All public-facing websites are required to link the portal in the footer (on the same level as data protection & imprint) but unfortunately security.txt creation wasn’t mandated. With the launch it was handed over to our CDC/VM team, without any real process or anything being established, without technical documentation existing or additional resources being allocated.
This is where the issues start: Without available resources & properly defined responsibilities literally nothing happened for about a year, all reports went unanswered, sorry for that, after learning about this & stealing the topic I shouted at the colleague “owning” it before 
. Additionally I inherited a shitload of technical debt with the setup I will not be able to clean up by the time I leave the job - in fact: This is consuming more time to technically maintain than to triage the vulnerabilities.
This brings me to the first “lessons learned” part: KISS. This means: security.txt, security@… email (for ALL your domains on which you receive email) flowing into one central inbox (shared with your IR/SOC!). A simple static webpage for your HoF or your public disclosures. That’s it if you aren’t a large IT company & can’t convince management to pay to outsource the entire thing to hackeroni or something.
Second “lessons learned”: security.txt is absolutely mandatory, even if you go with a custom portal or outsource it. I’d love to say that security researchers are smart but a good 20% of the valid reports we receive do not find our portal.
The reports one receives absolutely depends on what exposure & capabilities one has, so the question “who does the initial review” will have very different answers. If you have in-house pentesters (or similar) try to get them involved! They are best able to verify/replicate findings & sniff out hallucinations or out-of-scope stuff.
Process-wise… make sure there is a process with external visibility & deadlines. If you have an established process for handling pentest findings or vulnerabilities in general see if you can integrate there, otherwise make sure the process is written down - even low volume VDPs can easily have stuff slip through the gaps. You can absolutely run such a program with very limited time-cost but this becomes a trap leading to neglect of the program (idk, lesson learned the third?)
But I wanna make one thing clear, even though I complain about this part of my job more than anything else: It’s also probably the most rewarding part of my job. A good chunk of the valid reports we receive are very human interactions with curious people trying to make the world better. It’s a great counterbalance to just grinding away.
Also make sure to check the Junk folder of the security@ mailbox 