This lesson's interactive features are locked, please to keep using them

Responsible Disclosure

Sometimes the person who finds a vulnerability in your system is not an attacker. It might be a security researcher, an employee, or just someone who wants to make a responsible disclosure.

How you handle that report will determine whether you fix the issue quietly or your boss hears about it through an X post.

Publish a Security Policy

If someone finds a bug in your application, they need an easy way to tell you. RFC 9116 standardizes a security.txt file served at /.well-known/security.txt, something like:

Contact: mailto:security@example.com
Policy: https://example.com/security-policy
Expires: 2027-02-06T00:00:00.000Z

Contact and Expires are required. Policy is optional, but useful when you publish disclosure guidance. The Expires field marks when the document becomes stale, and RFC 9116 recommends setting it less than a year in the future. Update it before then! Without security.txt, researchers are left digging around your (probably terrible) marketing website for a contact form.

When a report arrives, acknowledge it! A reporter who gets nothing but silence may decide that public disclosure is the only way to get the issue fixed.

Bug Bounties

Some organizations go further and offer bug bounties: cash rewards for valid vulnerability reports. Programs like HackerOne and Bugcrowd are managed platforms for this, but it's certainly not a requirement, especially for smaller companies.

Watch out for spammy "bounty hunters" who report negligible or even non-existent vulnerabilities hoping for a small chance of a payout. It's usually obvious from the low-quality nature of the report. If you don't have a bug bounty program, you don't owe anyone money.

Assignment

Security researchers should not have to hunt for a way to report a Bearly Secure vulnerability.

Serve a security.txt response with Go's HTTP server.

Add an unauthenticated handler for GET /.well-known/security.txt.
Generate an RFC 3339 expiration timestamp 180 days from the current UTC time, within RFC 9116's recommended one-year limit.

Set the response's Content-Type to text/plain and write these fields with that timestamp:

Contact: mailto:security@bearlysecure.example
Policy: https://bearlysecure.example/security-policy
Expires: GENERATED RFC 3339 TIMESTAMP

Start the app.

With Bearly Secure still running, run and submit the CLI tests from the project root.