• Preferred: open a private security advisory on this repository (GitHub → Security → Advisories → "Report a vulnerability").
• Do not open a public issue for an exploitable finding.
• Include the affected policy id, reproduction steps, and impact.

Expect an acknowledgment within 7 days.

Framework vulnerabilities — the compiler, the gate runner, the validator — belong in open-coder-ai/chock, not here. This repository is content.

This is a policy catalog, so the interesting failures are not crashes:

• A gate that does not block what it claims to block. A scan-secrets pattern that misses a common credential format, or a protect-main-branch gate that a plausible branch name slips past. An overstated policy is the failure mode this catalog cares most about — it is worse than a missing one, because someone is relying on it.
• A gate that cannot be satisfied. A guard with no path to a passing commit gets disabled within a week, which removes the control entirely.
• Malicious or unsafe content in a guard script. See below.

A policy correctly labelled advisory that an agent ignores is not a vulnerability. That is what advisory means, and the README says so up front.

A policy's compiled output is not documentation. Installed via chock add, it becomes:

• a git hook that runs on every commit in the adopter's repository, compiled from the policy's declarative gate, and
• a guard consulted before the adopter's coding agent runs a command, for the policies that ship an implementations/ script.

Two policies run their own program at commit rather than a declarative gate: java-security and no-a11y-regression, both Python.

So a change to a guard script in this repository runs on other people's machines.

For reviewers: treat any PR touching implementations/ as a code-execution change. Read the whole script, not the diff hunk. The criteria are written down in docs/review-criteria/, and CI runs each guard in a throwaway workspace to check its declared effects against what it actually writes — but that covers only the argv its eval suite exercises, so it narrows the reading rather than replacing it.

For adopters: chock add fetches over git clone and is trust-on-first-use. There is no signing key and no trust root, so pin and verify when the catalog is not one you control:

chock add scan-secrets --ref <commit-sha> --verify-sha <sha256>

This catalog publishes no tags, so pin a commit SHA. --ref takes any ref the remote has; --verify-sha refuses the install unless the fetched pack hashes to the value you name.

add prints the resolved commit and content hash and records them in chock.lock; chock check --only verify re-checks them later. The full trust model, including what it does not cover, is in the framework's SECURITY.md.

• git commit --no-verify skips every git hook, and therefore every enforced policy here. block-no-verify refuses the flag before the command runs on the agents chock sync wires natively — eleven of them, including Claude Code, Cursor, Codex, Copilot CLI and VS Code — with Codex's own conditions: Codex hooks are untrusted until a human approves them, and an unavailable, untrusted or failing hook permits the command (repo-level coverage records Codex as advisory for exactly this reason). On agents without hooks, and for a human at a terminal, nothing stops it.
• Git hooks live in .git/hooks, which is not cloned. A fresh clone of an adopting repo enforces nothing until someone runs chock sync.
• Most policies are advisory (twenty-two of the forty-two at this writing — the README badges carry the current counts). They compile to text an agent reads and may or may not follow. Their eval cases report as skipped, never as passing.