How to report a security problem

If you find a security problem on this site, you should not have to guess where to send it, whether anyone will read it, or whether reporting it is safe. As of today, all three have a written answer.

The policy

namegarage.com/security/ is our vulnerability disclosure policy. It is short. It says what is in scope (this site, its subdomains, every form, and the endpoints those forms post to), what is not (denial of service, social engineering, the third parties we build on, which run their own programs), and what we ask of you: stop at the minimum needed to show the problem, do not read or keep data that is not yours, and give us up to 90 days before going public.

In return we commit to acknowledge every report within five business days, keep you informed until it is fixed, and not pursue legal action against research that follows the policy in good faith. There is no paid bounty — this is a one-person portfolio, not a company with a security budget — but there is a thank-you, and we mean it.

Like our Terms and Privacy pages, the policy is versioned: every version is published at a permanent dated address with the SHA-256 hash of its source, and a change is a new version, never an edit. What the policy said on the day you tested stays provable.

The address, and a key

Reports go to [email protected]. If you would rather not send the details in plain text, there is an OpenPGP key at /security/pgp-key.txt to encrypt them with. Its fingerprint, which the policy page also prints, is:

fc561d0a77ff466db2f59c7147db09db5de7c0b4

The machine-readable version

Security scanners and researchers' tools look for a file called security.txt at a well-known address, defined in RFC 9116. Ours is at /.well-known/security.txt, and it carries the same three things — the contact, the key, and a link to the policy — in the format the RFC lays out.

Two details are worth knowing. The file is signed with that same key (an OpenPGP cleartext signature, the RFC's recommendation), so a copy of it can be checked against the published key: import the key, run gpg --verify on the file, and the reported fingerprint should be the one above. And its Expires line is renewed automatically with every deployment, so it never quietly goes stale — a security.txt past its expiry is one the RFC tells readers to disregard.

The older spelling, /security.txt at the site root, redirects to the well-known one, so tools that still look there land in the right place.

Why now

Nothing happened. That is the point of doing this before something does: the day someone finds a problem, the way to tell us is already written down, and the promise about how we will treat them was made before we knew who they were.

X LinkedIn Email