Vulnerability Disclosure Toolkit
Making it easier for you to create a vulnerability disclosure process
Security vulnerabilities are discovered all the time and people want to be able to report them directly to the organisation responsible. The NCSC's Vulnerability Disclosure Toolkit contains the essential components you need to set up your own vulnerability disclosure process. This updated version also includes additional information on implementing a disclosure process, including validation and triage.
Even if your organisation already has a process in place, please download the toolkit (pdf) as it may help you to improve on what you already have in place.
On this page
About the toolkit
The NCSC’s Vulnerability Disclosure Toolkit is for organisations of all sizes who want to learn more about implementing a vulnerability disclosure process.
It is not intended to be a comprehensive guide to creating and implementing a vulnerability disclosure process, but instead focuses on the essential components to get you started.
- 1
Communication
Having a dedicated email address (such as [email protected]) or contact web form ensures that the vulnerability information gets to the right person who can help fix the issue. The NCSC recommend vulnerability information is protected, and one of the easiest ways to achieve this is to use a secure web form. You should make sure this contact route is easy to find. You can add it to your ‘Contact Us’ web page (or privacy or security pages) and publish a security.txt. If you don’t want to highlight it on a web page, then you should publish the contact route in a security.txt.
- 2
Policy
By providing a clear policy, you define what to expect from someone reporting a vulnerability (as well as what you will do in response). This means you can work with them in an agreed framework. The ISO standard defines the minimum requirements for a vulnerability disclosure policy. In its basic form, a vulnerability disclosure policy should contain the following information:
- how you want to be contacted
- secure communication options (for example, a secure web form)
- what information to include in the report
- what the finder should expect to happen
- guidance on what is in and out of scope for the finder to do in finding vulnerabilitiesIf you are a UK government department, you can use our GitHub hosted vulnerability disclosure policy by linking directly to this policy on your website or in your security.txt file (or both). An example vulnerability disclosure policy (that you can base your own organisation's policy on) is included in the toolkit.
- 3
Security.txt
One of the most important elements of vulnerability disclosure is understanding who to contact. Security.txt is an IETF Internet informational specification (RFC 9116) and it describes a text file that webmasters can host in the “/.well-known” directory of the domain root. It advertises the organisation’s vulnerability disclosure process so that someone can quickly find all of the information needed to report a vulnerability.
The file contains three key fields:- CONTACT: How finders should report vulnerabilities. For example, the email address of a link to the secure web form.
- POLICY: A link to the organisation’s vulnerability disclosure policy.
- EXPIRES: Indicates the date and time after which the data contained in the "security.txt" file is considered stale and should not be used. The value of this field is formatted according to the Internet profile of [ISO.8601] as defined in [RFC3339]. It is recommended that the value of this field be less than a year into the future to avoid staleness.
The ENCRYPTION field is optional and should link to the PGP public key you wish to be used for encrypted communication.
The security.txt file should be published to all your domains and subdomains in the standard location of /.well-known/For example:
# Only applies to example.com:https://example.com/.well-known/security.txt# Only applies to subdomain.example.com:https://subdomain.example.com/.well-known/security.txt
You can see the NCSC’s security.txt file at https://www.ncsc.gov.uk/.well-known/security.txt
How to respond to vulnerability disclosure
An unsolicited message from someone telling you about a vulnerability may sound scary at first, but don’t panic. You are not under attack, and this is not a cyber incident, but remember to follow our phishing guidance. To effectively respond to a vulnerability report, take the following steps.
- Don’t ignore the report. Respond promptly to the finder, and thank them. Feedback encourages engagement and they'll be more inclined to help you again in the future.
- Pass the report to someone in your organisation who is responsible for the affected product or service. If it is managed by a third party, discuss the report with them.
- Avoid forcing the finder to sign documents such as non-disclosure agreement as the individual is simply looking to ensure the vulnerability is fixed.
- If you need more information to confirm and fix the issue, you should politely request that additional information from the finder.
- Once you have decided on a course of action, let the finder know that the issue is being managed. You don't need to provide lots of technical information or commit to timescales.
- If the issue takes time to fix, you should send periodic updates back to the finder.
- Once the issue is fixed, let the finder know. They might be able to retest the issue to confirm the fix.
- Consider publicly acknowledging and thanking the finder as this creates a sense of trust and transparency.
Why encourage vulnerability reporting?
Security vulnerabilities are discovered all the time and people want to be able to report them directly to the organisation responsible. These reports can provide you with valuable information that you can use to improve the security of your systems. It really is in your best interest to encourage vulnerability disclosure.
Having a clearly signposted reporting process demonstrates that your organisation takes security seriously. By providing a clear process, organisations can receive the information directly so the vulnerability can be addressed, and the risk of compromise reduced. This process also reduces the reputational damage of public disclosure by providing a way to report, and a defined policy of how the organisation will respond.
In addition, vulnerability reporting will shortly be embedded into legislative frameworks. The UK government is currently developing legislation that will require manufacturers of smart devices to provide a public point of contact as part of a vulnerability disclosure policy. This is also a requirement for other international efforts on smart device security including the standard EN 303 645.
