Reporting a vulnerability.
If you've found a security issue affecting PRML, falsify, falsify-inspect, prml-verify-action, the registry, or any related infrastructure: thank you. Please report it privately using one of the channels below. We aim to acknowledge within 72 hours and patch high-severity issues within 30 days.
Primary contact
[email protected]
GitHub Security Advisory (preferred for code-level issues)
github.com/studio-11-co/falsify/security/advisories/new
Scope
In scope:
falsify.dev,spec.falsify.dev,registry.falsify.devgithub.com/studio-11-co/falsify(Python reference impl)github.com/studio-11-co/falsify-inspect(Inspect AI adapter)github.com/studio-11-co/falsify-integrity-index(data + scoring)github.com/studio-11-co/falsify-cookbook(patterns + examples)github.com/studio-11-co/prml-verify-action(GitHub Action)- PyPI:
falsify,falsify-inspect - Cryptographic claims about PRML canonicalisation rules (cross-impl byte-equivalence)
Out of scope:
- Studio 11 marketing site (
studio-11.co) - Third-party dependencies — report upstream (we'll patch on receipt)
- Phishing or brand impersonation — report to the impersonating host's registrar
- Issues in
inspect_aiitself — report to UK AISI
What counts as a vulnerability
The PRML threat model (v0.1 §5) is narrow. Examples that do count:
- A canonicalisation bug that produces different hashes for byte-equivalent inputs across reference impls
- A path that lets an attacker forge a valid PRML hash without a corresponding manifest
- An RCE or supply-chain compromise in the published PyPI artefact or GitHub Action
- An unauthenticated write path to
registry.falsify.dev - A leak of stored manifest content beyond the hash + timestamp metadata
Examples that do not count (for this report channel):
- "PRML doesn't fix selective publication" — that's PRML §8.1, not a bug
- "A publisher could lie about pre-registration" — that's the trust boundary the spec names; report it as a research finding to the spec's discussion forum, not as a vulnerability
- Rate-limit avoidance on the public registry — open a regular issue
Disclosure process
| Step | Target |
|---|---|
| Initial acknowledgment | 72 hours |
| Triage + severity assessment | 7 days |
| Patch + release for high severity | 30 days |
| Public advisory + coordinated disclosure | After patch ships |
If you do not receive a reply within 7 days, you may escalate by tagging @cuneytozturk on a private GitHub Security Advisory.
Acknowledgments
We credit security researchers who consent to be named. (No reports received yet.)
RFC 9116 file
The machine-readable security policy is at /.well-known/security.txt.