How I report security issues

I'm Bryce Watson, a software engineer. When I find a serious security problem in an app's public code, I tell the owner privately, for free. Many of these apps were built with AI tools like Lovable, Cursor, Bolt or Replit. If one of my notes landed in your inbox, this page tells you what I looked at, what I didn't do, and how to check it's really from me.

Last updated September 26, 2026

1 What I read, and how I found your app

I look for public apps built with AI tools through GitHub's own search and public launch pages. Then I read the public code and its public git history, with AI coding tools helping me: the same pages anyone can open without signing in. I read the history because a key that someone deleted from the code usually still sits in an older commit.

Every note points to the exact file, lines and commit in your own repository, so you can check what I describe without taking my word for it.

2 What I never do

• I don't use, test or check any key, password or token I find, not even to see whether it still works.
• I don't log in to, probe or scan your live site or API.
• I don't open anything that isn't public.
• I don't keep a copy of any key or password. My private notes say where the problem is, with any secret masked, and I delete my copy of your code when I'm done.
• I don't tell anyone else, and I don't open a public GitHub issue. There's no deadline and no public disclosure, ever.

So when my note says a key looks exposed, it means I saw it in the public code. I can't tell you whether it still works, because I didn't try it.

3 How I contact you

Privately, through the first of these that exists:

1. GitHub's private vulnerability reporting, if the repository has it turned on.
2. The repository's SECURITY.md file, or another security contact it lists.
3. A security@ address.
4. The email address on your public GitHub profile.

If I hear nothing and the problem still looks unfixed after a week, I'll send one short follow-up, only to check that the first note arrived. After that, I stop.

4 If you got a note from me

• Start with the first step in the note. If it mentions a key, rotate it: deleting it from the code doesn't make it safe, because the old commit still has it.
• Reply with any question, and I'll explain what I saw and where.
• You don't owe me anything, including a reply. The security part of the note has no sales pitch. At most, a separate last line mentions that I do paid reviews.
• If you'd like me to stop, say so, and I won't contact you again.

5 Checking it's really me

My notes come from one of these two addresses. Both reach the same mailbox, so a reply to either one gets to me.

You can also find me outside this site: GitHub, LinkedIn, and my personal site, brycewatson.com.

6 What I write about publicly

Sometimes I write about the patterns I keep seeing, like keys that stay in git history after they're deleted from the code. Those write-ups cover general patterns only. I name or describe a specific app only with its owner's written OK.

7 Found a problem in my own site?

Email bryce@watsonstandardco.com with what you found and how to see it, and I'll reply. The address is also in this site's security.txt file.

8 Want me to look at your app?

If you built an app with an AI tool and you're not sure it's safe, you don't have to wait for a note from me. Send me the repo, and with your OK I'll run the standard security tools on it, take a short look myself and reply privately. It's free.