If a specification here would lead someone to build a guard that does not defend what it says it defends, report it privately. Use the Report a vulnerability button on this repository's Security tab. That opens a private advisory between you and the maintainer, and nothing becomes public before a fix does.

Please do not open a public issue for that kind of report.

This repository publishes build specifications, not scripts. Nothing in it executes. So the thing that can be wrong is an instruction, and the damage lands later, on someone else's machine, in a guard that was built exactly as described and still lets something through.

In scope:

• A described control the described logic does not perform. The page asserts a check; the passes it lays out never carry it out.
• A bypass of the described logic. An input the page says is denied, which its own passes would let through — command chaining, quoting, shell wrappers, argument splitting, encoding.
• A path that fails open where the page says it fails closed. The reverse counts too: a session-start notice that can block a session.
• Wiring that does not connect. An entry in settings.json naming the wrong event, matcher or response shape, so the guard builds, runs, prints, exits zero, and reaches nobody.
• A configuration template that is unsafe as shipped. Everything under security/ is meant to be safe on the day it is copied, before it is filled in.

A report is most useful with the exact input, the pass it should have been caught by, and what was expected instead.

• Anything a specification already names. Each one states its own posture and its own non-denying paths, and the readme names the package-manager commands that reach the same registries with no gate at all. A gap that is written down is a limit, not a finding.
• A generated script that differs from its specification. These are instructions, so the script is the builder's own. A guard weaker than its page describes is a generation defect rather than a defect here — but report it anyway if the page was ambiguous enough to cause it, because that ambiguity is in scope.
• False positives. A guard that fires on ordinary work is a real defect and worth reporting, since a guard that cries wolf gets switched off. It is not exploitable, though, so it does not need a private channel. An ordinary issue is the right place.
• Bugs in other people's software — the agent host, jq, bash, the package managers, or the scanners named in the readme. Those belong with their own projects.

Only the current main. There are no tagged releases yet, and this section changes when there are.

Best effort, on a solo and unpaid project, with no service level attached. A report naming the exact input and the exact pass is the one that moves fastest.