Report a vulnerability on a DBT system
Guidance on how to report a security vulnerability on any Department for Business and Trade (DBT) IT service or system.
This page explains how the Department for Business and Trade (DBT) works with the security research community to improve our online security and deal with IT vulnerabilities.
A vulnerability is a technical issue with a DBT IT platform which attackers or hackers could use to exploit the website and its users.
Vulnerabilities are covered by this policy if the security.txt file for the domain points to a DBT service or system.
You should read this guidance fully before you report any vulnerabilities. This helps ensure that you understand our policy, and act in compliance with it.
This guidance does not provide any form of indemnity from DBT or any third party for any actions if they are in breach of the law.
Report a vulnerability
DBT takes the security of our IT systems seriously.
If you believe you have discovered something you believe to be an in-scope security vulnerability on a DBT system you should:
- Read our vulnerability disclosure policy.
- Check for more information about what we consider to be in-scope.
- Submit a vulnerability report using the HackerOne platform.
Your report should provide a benign, non-destructive, proof of exploitation wherever possible. This helps to ensure that the report can be triaged quickly and accurately. It also reduces the likelihood of duplicate reports, or malicious exploitation of some vulnerabilities, such as subdomain takeovers.
Alternatively, you can report issues to the National Cyber Security Centre (NCSC). More information about how to do this is available on the NCSC vulnerability-reporting page.
You will not be paid a reward for reporting a vulnerability (known as a ‘bug bounty’).
Vulnerability disclosure policy
DBT actively endorse and support working with the research and security practitioner community to improve our online security. We welcome investigative work into security vulnerabilities, carried out by well-intentioned and ethical security researchers.
We are committed to:
- investigating and resolving security issues in our platform and services thoroughly
- working in collaboration with the security community
- responding promptly and actively
Scope
This disclosure process applies only to vulnerabilities in DBT’s products and services when:
- they are ‘in scope’ vulnerabilities which are:
- original
- previously unreported
- not already discovered by internal procedures
- they are not:
- denial of service (DoS) vulnerabilities
- reports of non-exploitable vulnerabilities
- reports indicating that our services do not fully align with ‘best practice’, for example missing security headers
The policy applies to everyone, including for example DBT, third party suppliers and general users of DBT’s public services.
What to expect when reporting a vulnerability
After submitting your vulnerability report, you will receive an acknowledgement reply usually within 24 working hours of your report being received.
The team will triage the reported vulnerability, and respond as soon as possible to let you know whether:
- further information is required
- the vulnerability is in or out of scope
- it is a duplicate report
If work is needed to rectify, it is assigned to the appropriate DBT team or supplier(s), supported by our Cyber Team.
Priority for bug fixes or mitigations is assessed by looking at the impact severity and exploit complexity. Vulnerability reports might take some time to triage or address. You are welcome to enquire on the status of the process, but should avoid doing so more than once every 14 days. The reason is to allow our teams to focus on the reports as much as possible.
When the reported vulnerability is resolved, or remediation work is scheduled, the Cyber Team will notify you, and invite you to confirm that the solution covers the vulnerability adequately.
Feedback
You are invited to give us feedback on the:
- disclosure handling process
- clarity and quality of the communication relationship
- effectiveness of the vulnerability resolution
We will use this feedback in strict confidence to help us improve our processes for handling reports, developing services, and resolving vulnerabilities.
Guidance for security researchers
Security researchers must not:
- access unnecessary amounts of data, for example, 2 or 3 records is enough to demonstrate most vulnerabilities, such as an enumeration or direct object reference vulnerability
- use high-intensity invasive or destructive technical security scanning tools to find vulnerabilities
- violate the privacy of DBT’s users, staff, contractors, services or systems, for example by sharing, redistributing and/or not properly securing data retrieved from our systems or services
- communicate any vulnerabilities or associated details using methods not described in this policy, or with anyone other than their assigned DBT security contact
- modify data in DBT’s systems or services which does not belong to the researcher
- disrupt DBT’s services or systems
- social engineer, ‘phish’ or physically attack DBT’s staff or infrastructure
- disclose any vulnerabilities in DBT’s systems or services to third parties or the public, prior to DBT’s confirming that those vulnerabilities have been mitigated or rectified
- require financial compensation in order to disclose any vulnerabilities
We ask you to delete securely any and all data retrieved during your research as soon as it is no longer required or within one month of the vulnerability being resolved, whichever occurs first.
If at any time you are unsure if your intended or actual actions are acceptable, contact the DBT Pentest Team for guidance.
Third parties
The restriction on not notifying vulnerabilities to third parties (a party other than yourself and DBT) is not intended to stop you notifying a vulnerability to third parties for whom the vulnerability is directly relevant.
An example would be where the vulnerability being reported is in a software library or framework. The point is that details of the specific vulnerability as it applies to DBT must not be referenced in such reports.
For clarification about whether or when you can notify third parties, contact the DBT’s Pentest Team.
Bug bounty
Due to DBT’s funding structure, it is not currently possible for us to offer a paid bug bounty programme.
We will, however, make efforts to show our appreciation to security researchers who take the time and effort to investigate and report security vulnerabilities to us according to this policy wherever we can.
Legalities
This policy is designed to be compatible with common good practice among well-intentioned security researchers.
It does not give you permission to act in any manner that is inconsistent with the law, or which might cause DBT to be in breach of any of its legal obligations, including but not limited to (as updated from time to time) the:
- Computer Misuse Act (1990)
- General Data Protection Regulation 2016/679 (GDPR) and the Data Protection Act 2018
- Copyright, Designs and Patents Act (1988)
- Official Secrets Act (1989)
DBT affirms that it will not seek prosecution of any security researcher who reports any security vulnerability on an DBT service or system, where the researcher has acted in good faith and in accordance with this disclosure policy.