Security policy

A SECURITY.md answers one question: where does someone send a finding that should not be public yet. Without it the only obvious route is the issue tracker, and the issue tracker is public. A reporter who understands what they have found will usually say nothing rather than publish it.

GitHub takes the report for you

With private vulnerability reporting enabled, a Report a vulnerability button appears on the repository’s Security tab. The report lands in a draft advisory that only the reporter and the maintainers can read, with a thread for follow-up questions and, at the end, an advisory that can be published once a fix exists. There is no email address in the open and the reporter needs no account beyond their GitHub one.

It is off by default. You turn it on in the repository settings, in the security section, per repository or for every repository in an account at once. The repository has to be public.

That still leaves the policy file worth writing. The form collects a report. It says nothing about what a useful report contains, what the tool is expected to protect, or what will be closed as working as intended.

Why a local tool is a different problem

For a hosted service the reporter is probing a machine the maintainer runs, and the fix reaches every user the moment it deploys. Neither holds here. These tools run on the reader’s own laptop, from source they cloned, and a fix reaches them only when they pull it.

So the interesting reports are the ones about what the tool does to the machine it is already trusted on. Both policies that exist today are written that way.

molo states that it binds to 127.0.0.1 by default, that LAN access is token-gated with a per-installation token stored at mode 0600, and that traffic on your network is plain HTTP with no TLS, which means the pairing token is visible to anyone sniffing the network. It also states what is out of scope: extractor bugs belong upstream at yt-dlp, and reports that a downloader can download things are declined.

claude-codex-bridge states that the session formats it reads are vendor-owned and can change without notice, that a format compatibility failure is not by itself a security issue, and that anything exposing secrets, writing outside the intended session directory, corrupting an existing session, or bypassing an approval boundary should be reported privately. It asks reporters to use synthetic transcripts, because a real one is a transcript of somebody’s work.

Where these repositories stand

Checked against the GitHub API on 4 August 2026, across the eleven public repositories:

• Two ship a SECURITY.md: molo and claude-codex-bridge. The other nine do not.
• Private vulnerability reporting is disabled on all eleven.
• GitHub’s community profile does not measure this at all. The files it reports are readme, license, contributing, code of conduct, issue template and pull request template. A repository at 100 percent, which molo is, and the nine sitting at 42 percent are equally unmeasured on security.

Both existing policies point at a form that is switched off

molo and claude-codex-bridge tell a reporter to use the private reporting form on the Security tab. That form is not enabled on either repository, so the instruction currently fails and the reporter is left with a public issue or nothing. Enabling it takes one setting per repository and is the first thing to fix here.

The template

Short enough to actually fill in, and shaped around the sections that carry information a reporter cannot get from the README:

# Security

## Reporting a vulnerability
Use the private "Report a vulnerability" form on the Security tab.
Include the version, the OS, the smallest reproduction, and the impact.
Use synthetic data. Please do not open a public issue for something
exploitable. Expect a first reply within a week. This is a side project.

## What this tool exposes
What it binds to, what it writes, what it executes, what leaves the machine.

## Known and accepted
Trade-offs already made on purpose, and why.

## Out of scope
What will be closed, stated in advance rather than argued afterwards.

The middle two sections are the ones that make the file worth reading. “What this tool exposes” is the shortest honest description of the attack surface, and it takes ten minutes to write while the code is fresh. “Known and accepted” prevents the same report arriving four times.

nerln/molo on GitHubThe SECURITY.md this template is drawn from, including the accepted trade-offs on cleartext traffic and unsigned builds.