Reporting a bug you have found

People come across faults in software all the time, often while doing something ordinary on a website or an app. Some faults are only annoying. A few could let an attacker in.

These notes cover how to report a security flaw to the people who can fix it, and how to stay on the right side of the law while doing it. They draw on the National Cyber Security Centre (NCSC), GOV.UK, the OWASP Foundation and GitHub's documentation.

A bug or a security flaw

GOV.UK describes a vulnerability as a technical issue that attackers could use to exploit a website and its users. An ordinary bug stops something working as it should.

The difference changes how the report is made. GitHub calls it good practice to report a security flaw privately to the people who maintain the software. The full details come out later, once there is a fix.

Finding the right contact

Many organisations publish a file called security.txt in a standard place on their website, at /.well-known/security.txt. The format is set out in an internet standard, RFC 9116. The file gives a contact for security reports and can also link to the organisation's disclosure policy.

Open source projects often keep a security policy in their code repository. On GitHub, some projects also switch on private vulnerability reporting, which sends the report straight to the maintainers. GitHub suggests that if neither exists, the finder can open a public issue asking for a security contact. That issue should contain nothing about the bug itself.

Writing a report someone can act on

GOV.UK asks for the address of the page where the problem was found, the type of vulnerability and the steps needed to reproduce it. GitHub's default form asks for a summary, the details, a proof of concept and the likely impact.

OWASP's guidance says the finder should give enough detail for the flaw to be checked and reproduced. It also says finders should not demand payment outside an established bug bounty programme.

Staying within the law

In the UK, the Computer Misuse Act 1990 makes unauthorised access to computer material an offence. OWASP advises anyone researching security to understand the law where they live, and to make sure any testing is legal and authorised.

A disclosure policy sets the limits. GOV.UK's policy, for example, rules out destructive scanning tools, denial of service attempts and attacks on staff. It also forbids telling other people about the flaw before GOV.UK has disclosed it. Any data seen during the research must be kept secure and deleted within a month of the fix.

What happens after the report

GOV.UK confirms a report within 5 working days and tries to assess it within 10. It pays no reward. The NCSC advises organisations to reply promptly, thank the finder and send updates while a fix is under way. It also advises them not to make finders sign non-disclosure agreements.

GitHub's guidance says a finder may publish a flaw after a period of time if the owner has not responded, or has asked them to wait too long. OWASP describes this middle path as coordinated disclosure, where full details come out once a fix is available.

Smart devices

Since 29 April 2024, UK law has required makers of consumer connectable products to say how people can report security issues with them. The maker also has to say when the person reporting can expect an acknowledgement and updates. The Office for Product Safety and Standards enforces these rules.