Build a vulnerability disclosure program people can use

A disclosure program does not have to promise a bounty

A VDP establishes a reporting and response process. A bug bounty program adds a reward policy, with eligibility and payment conditions. An organization can receive and handle useful vulnerability reports without promising money. If rewards exist, the terms should say what qualifies and who decides.

Keep those expectations explicit. A researcher should not need to infer a reward from a public thank-you page, and a program owner should not treat a report as a request to buy a service. A penetration test is another arrangement: an agreed assessment with its own scope, schedule, and deliverables. A standing public disclosure channel does not replace that engagement.

The important question at launch is whether the organization can reliably receive, assess, communicate about, and resolve reports. Buying a platform may help with the workflow, but the platform cannot decide who owns an affected service or whether the organization has authority to permit testing of it.

For program owners: settle the scope before inviting research

List the systems or product families the policy will cover and identify the owner of each. Specify how a reader should interpret domains, subdomains, applications, APIs, and third-party services. “Everything we use” is not a precise statement of authority.

Check hosted and supplier-operated services before including them. The CISA VDP template, available in its official source repository, instructs agencies to confirm permission to authorize testing of managed or SaaS services. The underlying planning problem is relevant beyond government: controlling a domain name does not settle every contractual or technical boundary.

CISA's template was written for a specific U.S. federal directive. Its agency deadlines and scope requirements are not universal rules for private organizations. Use it as a source to understand policy decisions, and have the appropriate owner review the terms that will actually apply to your program.

The scope also needs maintenance. Assign someone to update it when a service launches, is retired, moves to another provider, or changes ownership. Record the policy revision date and preserve earlier versions internally so the team can establish which terms were published at a particular time.

State permitted conduct and the point where testing must stop

A researcher needs to know what the organization authorizes, what it excludes, and what to do when a test produces unexpected access. The policy should address disruptive testing, social engineering, access to other people's information, persistence, and interaction with services outside the organization's authority.

Avoid writing a blanket prohibition so broad that it conflicts with the research the policy intends to permit. For example, if every automated request is forbidden, explain how that relates to the program's actual assessment expectations. If a method is not allowed, state it clearly and provide a way to ask about uncertainty before testing.

The policy should also establish a stop condition. If a researcher encounters sensitive information, the useful next action may be to stop and report the minimum evidence rather than download more records to demonstrate scale. Decide how the organization will receive that evidence and how it will ask for any necessary follow-up.

Authorization and safe-harbor language deserve review by someone who can make the commitment on behalf of the organization. Define the promise accurately, including its limits. Do not promise protection from actions by unrelated third parties that the organization cannot control.

For researchers: check the policy on the actual target

Before testing, find the current policy for the organization and confirm that the particular system and activity are covered. A parent company's policy may not include an acquired service. A public program on one platform may exclude a third-party login provider or a separate mobile API.

A security.txt file can help locate a contact or policy, but it does not itself grant permission. RFC 9116 explicitly distinguishes contact discovery from permission to test. Follow the linked policy and ask the listed contact when the boundary is unclear.

Record the relevant scope and terms before starting. Use only the access and methods they permit. If the behavior you discover goes beyond that boundary, stop the activity that would cross it and report what you can explain from the authorized observation. More access is not automatically necessary to make a report useful.

Make the reporting channel work before launch

Test the contact route end to end with a harmless internal submission. Verify that it reaches the people responsible for triage, that attachments can be handled appropriately, and that an acknowledgement can reach the reporter. Check what happens outside normal working hours and during staff absence.

Ask for enough information to investigate:

• The affected system and the account role used.
• A concise description of the behavior and expected boundary.
• Reproduction steps using the least sensitive evidence needed.
• Relevant timestamps, versions, requests, or screenshots.
• A way to contact the reporter, if they choose to provide one.

Avoid requiring a polished report, a guessed severity score, or unrelated personal information before the team will read a submission. A researcher may have a meaningful observation without knowing the organization's internal architecture.

Decide how confidential material should be sent. An ordinary public issue tracker may expose a weakness before the team has assessed it. A submission form needs its own access controls, retention decisions, and attachment handling. The report itself is untrusted input; receiving a file does not make it safe to open in an unrestricted working environment.

Promise response times the team can maintain

Separate acknowledgement, initial assessment, progress updates, and resolution. These are different milestones. An automatic acknowledgement can confirm receipt without claiming that the vulnerability is valid. A meaningful initial assessment may require the service owner and additional evidence.

Set commitments from actual staffing and escalation arrangements. If a report suggests active exploitation or immediate harm, provide a path to incident response rather than leaving it in the normal queue. If an issue is complex, communicate the uncertainty and the next update instead of silently missing a promised fix date.

Have a rule for duplicates and rejected reports. Explain the decision at a useful level without exposing another reporter's identity or unrelated confidential details. Keep a way to reconsider the outcome when new evidence changes the technical understanding.

Coordinate disclosure as a separate decision

Receiving a report, deploying a patch, and publishing an advisory are related steps with different audiences. A product affecting other organizations may require coordination with suppliers, downstream users, or a third-party coordinator. An internal website issue may require a different communication path.

The CERT Guide to Coordinated Vulnerability Disclosure covers preparation, useful reports, communication, coordination, and disclosure. Use that process perspective when deciding who needs information and when. A public countdown alone does not resolve those dependencies.

Agree how the organization will discuss timing and credit with the reporter. If a fix is delayed, provide a status update and identify the unresolved work. If public details could expose people who remain vulnerable, explain that concern as part of coordination rather than treating silence as agreement.

Do not claim that every report needs a CVE or a public advisory. Determine the appropriate identification and communication process for the affected product or service. Keep the decision and its owner in the case record.

Maintain the program after the policy is published

Track whether reports are acknowledged, whether an owner is assigned, how long validated issues wait for action, and whether reporters receive promised updates. Use the figures to find a broken handoff. A large submission count alone says little about the quality of the program or the security of its systems.

Review a few closed cases for evidence of resolution. Check that accepted risks have an owner and review date, and that unresolved issues did not disappear because someone changed the ticket state. Periodically test the contact route again.

Keep discovery information current too. RFC 9116 defines an Expires field for security.txt and cautions against stale contacts. Source: RFC 9116. Set an owner and renewal task instead of publishing the file once and forgetting it.

Prepare the decisions before drafting the final policy

The VDP planning worksheet collects scope, authority, research conditions, report handling, response ownership, and disclosure decisions. It is a planning document with empty fields, not a ready-to-publish policy with invented commitments.

A working vulnerability disclosure program gives a researcher a clear route to report and gives the organization a reliable route from evidence to repair. Publish the policy when those routes agree with what the team is prepared to do.