Vulnerability disclosure: let researchers report flaws safely

Vulnerability disclosure is how a flaw someone else found in your app reaches you, gets fixed and is told to your users. Sooner or later a security researcher, a customer or a curious developer will find something. Whether you hear about it first, or read about it online, depends on what you set up before that day. This guide follows the organization's side of the OWASP Vulnerability Disclosure Cheat Sheet and ends with a setup a small team can finish this week.

Vulnerability disclosure: what each side owes the other

OWASP calls this an area where collaboration matters a great deal but conflict is common, so it starts with what each side should do. Organizations should give researchers a clear, secure way to report, respond in a reasonable time, communicate openly, publish clear advisories and changelogs, offer credit and, where they choose, rewards. They should not threaten legal action against researchers.

Researchers, in turn, should test only where it is legal and authorized, respect other people's privacy, make reasonable efforts to reach the security team, give enough detail to reproduce the problem, and not demand payment outside an established bug bounty program.

Three ways a flaw becomes public

The cheat sheet describes three models, and it helps to know which one your process invites:

• Private disclosure. The researcher reports only to you, and you decide whether details are ever published. Most bug bounty programs require this. Its weakness, OWASP notes, is that an unresponsive or unwilling vendor can leave a flaw hidden indefinitely.
• Full disclosure. All details, sometimes with exploit code, are published as soon as they are found, often before a fix exists. It is mostly used to pressure organizations that ignore reports. The cheat sheet calls it very controversial, seen by many as irresponsible, and generally a last resort.
• Responsible or coordinated disclosure. The report is private, and details are published once a fix is out, often with a deadline. For example, Google's Project Zero generally gives vendors 90 days to make a patch available.

Publishing working exploit code after a fix is its own debate. Some see it as directly helping criminals attack users. Others point out that defenders and penetration testers use it to check their systems, and that attackers can build exploits anyway when a flaw is valuable enough. The cheat sheet presents both views.

From report to published fix. Simplified from the OWASP Vulnerability Disclosure Cheat Sheet.

Make your team easy to reach

OWASP calls this the most important step: the easier you are to contact, the more likely you are to receive reports. The more of these you set up, the better:

• a dedicated security contact on your Contact page;
• reporting instructions on your bug tracker;
• the common security@ email address;
• a security.txt file at /.well-known/security.txt, as defined in RFC 9116, with at least the required Contact and Expires fields;
• a third-party bug bounty program.

Then tell the people who answer your main email, chat and phone lines how to recognize a security report and who to pass it to. A report that reaches the wrong inbox and sits there is the most common way this goes wrong.

Publish reporting guidelines

Next to your contact details, say what you need and what researchers can expect. The cheat sheet suggests asking for specific information that helps you confirm and fix the issue, a confidential category on your bug tracker, PGP keys for encrypted reports, a timeline for your first reply and triage, and safe harbor terms that say what testing you consider authorized. For safe harbor wording, OWASP points to the disclose.io project and is clear that legal terms should come from lawyers.

Talk to researchers while you fix it

Communication is where OWASP says both sides most often end up frustrated. Its example process:

1. Reply to the first contact with a clear way to send the details.
2. Acknowledge the report and give a timeline for triage.
3. Ask for any clarification you need.
4. Confirm the flaw and give a timeline for the fix.
5. Confirm any reward or bounty.
6. If needed, ask the researcher to retest.
7. Confirm that it is resolved.

Send regular updates throughout, even without a firm date, so the researcher knows the report has not been forgotten. If someone demands payment before sharing any details, the cheat sheet warns many such requests are scams; one option is to ask them to report through a mediated bug bounty platform.

Bug bounties themselves are a later step. OWASP lists the challenges for smaller organizations, such as the time to triage, junk reports and live testing that is hard to tell from attacks, and says bounties suit organizations that already have a mature disclosure process.

Publish the advisory

Once a flaw in your software is fixed and retested, publish a security advisory. The cheat sheet says it must include a short summary with the impact, the affected versions, the fixed versions, any conditions that limit when it applies, any workarounds, and a CVE ID if one was assigned. It is good to add the timeline, technical details and credit for the researcher. Put advisories where people will find them: a security page, a mailing list, and links from your changelog. OWASP's view is that publishing does not make you look bad; a clear process gives more confidence than hiding issues. For flaws in private systems, publishing is your choice, with trade-offs on both sides. Other vendors' advisories matter to you too: they are how you learn which of your packages need dependency updates.

Worked example: a disclosure setup for a small team

Say you run a web app with a small team and no security staff. Here is a setup you can finish this week:

1. Create the inbox. Set up security@yourdomain, forwarded to two named people so a holiday does not stop replies.
2. Publish security.txt. Add /.well-known/security.txt with a Contact line pointing to that address, an Expires date, and a Policy line pointing to your disclosure page.
3. Write the page. On a short disclosure page, say what to include, how quickly you will acknowledge a report and update the reporter, that you will credit them, and your safe harbor terms once a lawyer has reviewed them.
4. Brief your support team. Anyone answering email, chat or the phone knows to pass security reports to the security inbox.
5. Prepare the advisory template. Summary and impact, affected and fixed versions, workarounds, timeline, credit. Link it from your changelog when you use it.
6. Run a drill. Have a teammate send a fake report and time how long it takes to reach the right person and get a reply.

Frequently asked questions

What is a security.txt file?

A plain text file at /.well-known/security.txt, defined in RFC 9116, that tells researchers how to reach you. OWASP says to include at least the required Contact and Expires fields.

Do I need a bug bounty program?

Not to start. The cheat sheet says bug bounties suit organizations that already have a mature disclosure process and the time to triage reports; begin with a contact, guidelines and replies.

What if someone demands payment before telling me the flaw?

OWASP warns many such requests are scams, and suggests asking them to report through a mediated bug bounty platform.

Get started

Set up the security inbox and security.txt today; both take minutes. If you would rather find the flaws before a stranger does, whitehatstoic's cybersecurity and AI safety testing covers web app and API review, with a written report, fixes and a retest after fixes. It pairs well with preparing for a penetration test. No test can promise to find every weakness; the work is scoped after a short call.

Building something that has to be safe? Book a meeting with whitehatstoic: tell us the product, the deadline and your biggest worry, and we reply with a plan and a price.