Getting a vulnerability report
If someone finds a vulnerability in your service or product that could be exploited in an attack, make it easy for them to report it to you.
A vulnerability is a weakness in software, hardware, or an online service. Vulnerabilities can be exploited to damage a system or access information.
When someone finds a vulnerability, they’ll often try to let the owner of the software, hardware, or service know about it. This is known as vulnerability disclosure. People who find and report vulnerabilities (the ‘finder’) are typically not malicious. Their intention is to let you know it exists so you can mitigate the risk for your organisation. For example, the finder could be:
- a professional security tester, testing the software for a client, or
- a curious university student testing their security knowledge.
While getting a report is often unexpected, it’s generally not something to panic about. To make sure you’re prepared to receive reports:
- make sure people know how to report vulnerabilities to you
- have a process in place to investigate them.
Make it easy for people to report
There’s some simple steps you can take to make sure it’s easy to report vulnerabilities to your organisation.
Ensure contact details are available
The first thing the finder will do when they want to report a vulnerability is try to find out who to send their information to. This is often the hardest part of making a report — it can be difficult to find the right contact details. Vulnerability reports should go directly to your IT or security team. If the only contact details available on your website are for media or general enquiries, there’s a risk the report could get:
- lost, or
- sent to the wrong part of the organisation.
You can avoid this by:
- having a security.txt file on your site. Security.txt is a standard that gives people an easy way to contact your organisation about security issues. It’s a file that sits on the web server, and gives details of your PGP fingerprint, email address and vulnerability reporting policy. You can find the security.txt file for any website through the well-known path.
- listing full contact details on your site. Include contact details for your IT support or security team on your main Contact us page, or add them to your privacy or security policy page
- making sure you keep your WHOIS profile up to date. WHOIS is a searchable domain details database. You can list your domain registrant’s contact information there, like emails and phone numbers. It’s often the first place people will look to find an organization’s contact details.
Provide a secure means of contact
The finder will need a secure way to send you details of the vulnerability they’ve found. They should be able to:
- use PGP encryption to send their report. The finder should be able to find your PGP fingerprint on your website, in your security.txt file or on your security policy page. You’ll also need to have your public key available elsewhere — on a public key server like pgp.mit.edu, for example. This lets the finder verify your PGP fingerprint to make sure they have the right public key.
- send their report to you by email in an encrypted zip file using a strong algorithm. They can share the password for it by phone or SMS. If your organisation does not allow encrypted ZIP files, you should consider using PGP. You can also consider using an HTTPS website, like PrivateBin, that accepts text reports sent straight to your security team.
Responding to a report
When you receive a report, make sure you acknowledge the finder if you can. Let them know what steps you expect to take to investigate the vulnerability they’ve found. Don’t ignore either the vulnerability, or the report.
In some cases, the finder will want to remain anonymous so you won’t be able to contact them. This is standard practice and nothing to worry about. If you are able to contact them — by email, for example — they may not respond.
- Some people will want to report a vulnerability but not get involved further. Their main concern is to make you aware of it, and then let you deal with it.
- In other cases, the finder may be someone who might not ordinarily feel like their report would be listened to. This could be someone within the organisation who’s concerned about possible repercussions, for example.
If the vulnerability looks credible, get someone to investigate it. This could be either your own IT team, or a neutral IT specialist. How you approach the investigation depends on your organisation’s internal processes. For example, it may be that you:
- assess the vulnerability (or get someone to do it for you)
- see how critical it is
- do a risk assessment
- kick off a change response process (or incident, if it’s critical or risky).
Put a vulnerability policy in place
Your organisation should have a vulnerability disclosure policy that’s available on your website. It will let people know:
- how they can make a report to you
- how you’ll treat any reported vulnerabilities
- if you’ll provide any kind of reward or thanks for reporting.
Some people — or companies — may try to charge you for details of a vulnerability. Make sure your policy is clear about what you’ll do if you’re asked to pay for a report. If you’re asked for payment and aren’t comfortable with the request, contact another company to investigate the vulnerability on your behalf.
Should you have a bug bounty?
Some organisations have a programme where they offer rewards or recognition for people who find vulnerabilities. This kind of programme is known as a ‘bug bounty’. Organisations with a mature and well-tested vulnerability responding process usually have a bug bounty programme. They encourage people to try to find vulnerabilities in their systems and software. This can lead to a high number of vulnerability reports.
If you want to offer a bug bounty, it’s important to start off with a vulnerability disclosure policy first, so people know how to report any issues they find to you. You can consider implementing a bug bounty programme once your organisation has developed strong internal:
- vulnerability response processes, and
- security testing processes.