Security

Sealmesh handles what people are working on, including work they haven't shared. Treat a report about it as urgent even when the bug looks small.

Report a vulnerability

Privately, through GitHub: Security → Report a vulnerability. If you can't use GitHub, email security@sealmesh.dev. Don't open a public issue, and don't describe the problem in a pull request title.

Include what you can do that you shouldn't be able to, the smallest sequence that shows it, which component it's in, and the version or commit.

You'll get an acknowledgement within two working days and an assessment within five. If the finding is confirmed, you'll hear about the fix and when it ships. There's no bug bounty.

Most worth attacking

• Anything that lets one person's activity reach someone it shouldn't: an allowlist bypass, or free text escaping into the wire format.
• Anything that lets a client be attributed to an identity that isn't its own.
• Anything that makes a machine answer a query it should have refused, or more often than its rate limit allows.
• Anything that gets code or credentials out of the build and release pipeline.

Out of scope: GitHub and coding-agent products themselves, an already-compromised machine, and deliberate misconfiguration of your own allow.paths.

Known gaps

Three gaps are documented and not yet closed. A report finding them worse than described is welcome. See Security model › Known and not yet held.

How the project protects itself

• unsafe is forbidden, and panics are denied outside tests.
• CI runs a secret scan of the full history, cargo deny for advisories and licenses, and CodeQL.
• Every GitHub Action is pinned to a commit SHA. OpenSSF Scorecard grades the repository.
• main is protected and changes land through reviewed pull requests. Release tags are restricted.

Machine-readable contact: /.well-known/security.txt. The full policy is SECURITY.md.