Bug Circuit

Free tool · no signup

Vulnerability disclosure policy generator

Tell security researchers how to report a bug to you, what is in scope and what to expect back. Fill in the form and get a ready-to-publish policy page in Markdown.

By the Bug Circuit security team · Last updated

Your policy

  • Add your company or product name.
  • Contact must be an email address or an https:// web form URL.
  • List at least one system that is in scope, for example your main website and API.
Your policy (Markdown)
Fill in the company name, a contact and your scope.
  • Safe harbor wording has legal weight. Have your lawyer review it before you publish, and make sure you can honour it for every system listed in scope (including systems run by vendors).
  • Publish this page at a stable address, link it from your site footer, and put its URL in your security.txt Policy line.
What is a vulnerability disclosure policy? A public page that tells people how to report a security problem to you safely, which systems they may test and how fast you will respond. Publish it, link it from your footer, and put its address in your security.txt.

How it works

Why have one

People find security bugs by accident all the time: a customer notices they can see another account, a developer spots an exposed file. Without a clear way to report it, they either say nothing or go public. A disclosure policy gives them a safe route and gives you the chance to fix the problem first. Enterprise customers, auditors and insurers increasingly ask whether you have one, and the international standards ISO/IEC 29147 and 30111 describe the process it supports.

What a good policy says

Scope: which sites and apps may be tested, and which things are off limits, such as denial of service or attacks on your staff. How to report: one address, and what details help. What to expect: when you will acknowledge the report, when you aim to fix it, and when the reporter may talk about it publicly. The common default for public disclosure is 90 days, which Google's Project Zero popularised. Rules: act in good faith, do not touch more data than needed, and stop if you reach personal data.

The safe harbor paragraph says you will not take legal action against people who follow the policy. It is the part researchers care about most, and the part with legal weight, so have a lawyer read it before you publish, and make sure you can honour it for every system you list.

After you publish

Put the policy at a stable address such as /security-policy, link it from the footer, and add it as the Policy line of your security.txt file (the security.txt generator can build that file). Then keep the promises: acknowledge reports within the time you stated, and tell reporters when the fix ships. You do not need a paid bug bounty. Many good programs offer credit only.

Worked examples

A small SaaS company

Acknowledge in 3 business days, aim to fix in 90 days, disclose after 90 days, credit only.

## What to expect

- We will acknowledge your report within 3 business days.
- We aim to fix confirmed vulnerabilities within 90 days.
- We ask that you do not share details publicly until we have fixed the issue, or until 90 days after your report.

These numbers are achievable for a small team, which matters more than looking impressive.

Scope that keeps both sides safe

Main site and API in scope, with the usual exclusions.

In scope:
- example.com
- api.example.com

Out of scope:
- Denial of service testing
- Social engineering of staff or customers
- Third-party services we do not control

Name real hostnames. A vague scope makes researchers guess, and guessing leads to testing things you did not mean to offer.

The footer link and security.txt line

Publish the policy at /security-policy.

Policy: https://example.com/security-policy

The Policy field of security.txt (RFC 9116) points researchers to your rules before they send anything.

Frequently asked questions

Do I need a bug bounty to have a disclosure policy?
No. A policy and a reliable mailbox are enough. Credit on a thanks page is a fine reward for a small company. Paid programs add cost and triage work, and are worth it only once you can handle the volume.
Is the generated text legal advice?
No. It is a sensible starting point based on common practice. The safe harbor paragraph in particular should be reviewed by your lawyer.
Where should I publish it?
On a public page at a stable address, linked from your site footer, and referenced in your security.txt Policy line. Do not hide it behind a login.
How fast must I respond?
There is no rule, but researchers expect an acknowledgement within a few business days. Promise only what you will do, because silence is what pushes researchers to disclose publicly.
What if someone reports something out of scope?
Thank them and look at it anyway if it is real. A policy limits what you invite people to test. It does not stop you fixing a real problem someone found.
Should I promise not to sue researchers?
A safe harbor is what most researchers look for, and it makes people more likely to report. It has legal weight, so write it with your lawyer, and make sure it covers every system in scope, including those run by vendors.
How long should I wait before public disclosure?
90 days is the common default and a fair balance for most fixes. Shorter, such as 30 to 45 days, suits simple issues. Say that you may ask for more time when a fix is genuinely hard.

Keep reading

security.txt GeneratorMake the file that points researchers to your policy.CVSS CalculatorScore a report the way the industry does.How to get a penetration testFind problems before researchers do.Our own disclosure policyHow we handle reports to Bug Circuit.

See what attackers see, for free

Run the free passive check on your website. No login, no impact on your site, results in seconds.

Ready for the full manual audit? See pricing

Vulnerability Disclosure Policy Generator · Bug Circuit