Sooner or later, someone, a security researcher, a user, a customer's security team, may find a vulnerability in your app and try to tell you. How you handle that moment matters: a clear way to receive the report and a prompt, professional response turns a potential incident into a quiet fix, while ignoring or threatening the reporter pushes them toward public disclosure or worse. Having a vulnerability disclosure process in place before you need it is the difference. Here is what vulnerability disclosure is, how to set up a way to receive reports, and how to handle a reported flaw.
Short answer
Vulnerability disclosure is how you receive and handle reports of security flaws in your app from researchers, users, or others, and handling it well means having a clear channel to receive reports, acknowledging them promptly, assessing and fixing the issue, and coordinating disclosure. Per the security.txt standard, a common way to publish a security contact is a security.txt file on your website, alongside a vulnerability disclosure policy. When a flaw is reported, acknowledge it, reproduce and assess severity, fix it and deploy the fix, including forcing an update for serious issues, and credit the reporter. Treating reporters as allies and responding professionally turns a potential incident into a managed fix.
What you should know
- Disclosure is how you receive reports: of security flaws in your app.
- Have a clear channel: a security contact and a disclosure policy.
- Acknowledge promptly: a fast, professional response matters.
- Coordinate the fix and disclosure: fix first, then disclose.
- Treat reporters as allies: do not ignore or threaten them.
What is vulnerability disclosure?
It is the process by which someone who finds a security flaw in your app reports it to you, and you handle it. Researchers and users do find issues, and the question is whether they have a way to reach you and whether you respond well. Coordinated, or responsible, disclosure is the norm: the reporter notifies you privately, you fix the issue, and disclosure happens after a fix is available, rather than the flaw being made public immediately. The alternative, having no channel so a reporter cannot reach you, or reacting with hostility, tends to backfire, since a frustrated reporter may disclose publicly or the issue may go unaddressed. So vulnerability disclosure is about creating a path for good-faith reports and responding to them in a way that gets the flaw fixed, which protects your users and your reputation.
How do you set up a way to receive reports?
Publish a security contact and a simple policy. The table lists the pieces.
| Element | What it does |
|---|---|
| security.txt file | Publishes your security contact on your website |
| Security contact | An email or form for reporting vulnerabilities |
| Vulnerability disclosure policy | States how to report and what reporters can expect |
| Optional bug bounty | Offers rewards for valid reports |
| Acknowledgement process | A commitment to respond within a stated time |
The foundation is making it easy to reach you: a security.txt file on your website is a standard, machine-findable way to publish your security contact, and a short vulnerability disclosure policy tells reporters how to report and what to expect, such as not facing legal action for good-faith research. A dedicated contact, an email or form, beats hoping a report finds its way to the right person. Some organizations add a bug bounty to reward valid findings, but even without one, a clear channel and a stated commitment to acknowledge reports are the basics that make disclosure work.
How do you handle a reported flaw?
Acknowledge, assess, fix, deploy, and credit. When you receive a report, acknowledge it promptly so the reporter knows it was received and is being looked at, which sets a cooperative tone. Reproduce the issue and assess its severity and impact, so you can prioritize, then fix it and deploy the fix, and for a serious vulnerability, drive adoption of the fixed version rather than relying on organic updates, since old versions stay vulnerable. Keep the reporter informed of progress, coordinate the timing of any public disclosure with them, and credit them for the finding, which builds goodwill in the security community. Avoid the failure modes: do not ignore the report, do not threaten the reporter, and do not disclose details before a fix is out. Handled this way, a report becomes a managed fix, with the reporter as an ally rather than an adversary.
What to watch out for
The first trap is having no way to receive reports, so a researcher who finds a flaw cannot reach you and may disclose publicly; publish a security contact. The second is responding with hostility or silence, which turns a good-faith reporter against you. The third is fixing the issue but not getting users onto the fixed version, leaving them exposed. Disclosure handles flaws found by others; a pre-submission scan such as PTKD.com (https://ptkd.com) reads your binary against OWASP MASVS and helps you find and fix issues proactively before they become a report, complementing a disclosure process. The reporting channel and policy you set up on your side.
What to take away
- Vulnerability disclosure is how you receive and handle reports of security flaws in your app, and doing it well turns a potential incident into a managed fix.
- Publish a security contact, such as via a security.txt file, and a vulnerability disclosure policy so reporters can reach you and know what to expect.
- When a flaw is reported, acknowledge it promptly, assess and fix it, deploy the fix and force adoption for serious issues, and credit the reporter.
- Set up a disclosure channel before you need it, and use a pre-submission scan such as PTKD.com to find issues proactively before they are reported.
