What is a white hat hacker and how does legal security research work?

A white hat hacker is a security researcher who tests systems with permission, or under a published disclosure policy, in order to find flaws and report them so they can be fixed. What separates white hat work from an attack is authorization and intent, and organizations make that clear with a written policy.

Where does the term come from?

It borrows from old Western films, where heroes wore white hats. Black hat describes attackers acting for gain or harm, and gray hat is used for people who test without permission but report what they find. The labels are informal. Law and policy care about authorization, not about colors.

What makes research legitimate?

Three things: permission, scope and restraint. Permission may be a contract, a penetration testing agreement, a bug bounty program or a published vulnerability disclosure policy. Scope names which systems and which techniques are allowed. Restraint means touching no more data than needed, not disrupting service and not sharing what you find.

What does a good disclosure policy contain?

CISA's Binding Operational Directive 20-01 requires US federal agencies to publish a vulnerability disclosure policy at a standard path on their website. It is a useful model for any organization. The policy must include:

• Scope: at least one internet accessible production system or service.
• Testing rules: which kinds of testing are allowed or not authorized, and a statement that reporters must not disclose any personal information they find to third parties.
• Reporting instructions: where to send reports, what detail to include, and a clear statement that reporters may submit anonymously.
• Good faith authorization: a commitment not to recommend or pursue legal action against anyone whose research the agency concludes is a good faith effort to follow the policy.
• Response expectations: when reporters can expect an acknowledgement, and transparency about remediation.

The directive also sets target timelines for handling reports: acknowledgement within 3 business days, initial assessment within 7 days and resolution within 90 days. The directive describes them as targets, not mandatory remediation deadlines.

How do researchers find where to report?

RFC 9116 defines security.txt, a machine readable file that tells researchers how to report vulnerabilities. Two fields are required: Contact, with one or more reporting methods listed in order of preference, and Expires, a date after which the file is considered stale, recommended to be less than a year ahead. The file belongs at the path /.well-known/security.txt, served over HTTPS as plain text, and it applies only to the exact domain where it is hosted.

The RFC notes that researchers often cannot find a reporting channel at all. A security.txt file removes that excuse and shortens the time from discovery to fix.

Constructed example: the forgotten admin page

A researcher notices that a small company's admin login page is reachable from the internet and accepts a default password. She stops at confirming the weakness, without opening any records. The company's site has a security.txt file with a contact address. She sends a short report: what she found, how to reproduce it and what she did not do. The company acknowledges within two days, changes the password, restricts the page and thanks her. Nobody called a lawyer. The story is invented, but it shows how a clear policy channels good faith research.

What should organizations do?

Make it easy and safe to report. Publish a policy that states scope and good faith protections, add security.txt, route reports to someone who can act, and keep your promises on response times. Treat researchers as allies. Ignoring or threatening them pushes findings to public disclosure or worse.

Software teams can also reduce what reporters find by scanning their own code and dependencies first. Safeguard's code scanning and dependency scanning are tools for that.

How to check or apply this

1. Write a vulnerability disclosure policy with scope, rules, a contact and a good faith statement.
2. Publish it on your website and link it from your footer.
3. Add a security.txt file at the well known path, with Contact and Expires, and renew it before it expires.
4. Create a shared mailbox or form that reaches people who triage reports.
5. Set and publish target response times, and measure them.
6. Agree internally on who may approve fixes and communications.
7. Seek legal advice on how your policy interacts with local law.

Quick check

Sources

• CISA BOD 20-01, Develop and Publish a Vulnerability Disclosure Policy
• RFC 9116, A File Format to Aid in Security Vulnerability Disclosure

Last reviewed: 18 October 2026.