Brig exists to hold a boundary. An agent gets one directory and the credentials it was named, and nothing else on the host. Anything that weakens that boundary, or that reaches something the agent was never given, belongs here rather than in a public issue.

Tell us privately first and we will fix it with you before it is public. If you are unsure whether something counts, report it and we will work that out with you.

There is no stable release yet. Brig ships prereleases only, currently the 0.1.0-rc series, and the version you are on is whatever brig version prints. Fixes land on main and go out in the next prerelease. We do not backport to an earlier rc, so the supported version is the latest one. If you are reporting against an older prerelease, check that the issue still reproduces on the newest before you send it. Expect the fix to arrive as a newer prerelease, not as a patch to the one you filed against.

Use GitHub's private vulnerability reporting. Open the advisory page and press Report a vulnerability:

https://github.com/brig-sh/brig/security/advisories

That opens a private thread visible only to you and the maintainers, so nothing is disclosed while we work on a fix. Please do not open a public issue for a security problem. Do not send a pull request that reveals the flaw before an advisory exists.

To use email instead, write to security@brig.sh. Both reach the same people.

Include what a fix needs: the version from brig version, the operating system, and the runtime. Name the runtime as hull on macOS, nerdctl with the urunc shim on Linux, or runc when BRIG_CONTAINERD_RUNTIME=runc is set. Also include what you did, what happened, and what you expected instead. A proof of concept helps, even a rough one.

• First response within 3 working days. That is an acknowledgement from a human that the report arrived and is being looked at, not a fix.
• A disclosure window of 90 days. We aim to have a fix released and an advisory published within 90 days of the report. If it takes longer we will say so in the thread and agree a new date with you rather than let it lapse silently. If a fix ships sooner, the advisory goes out sooner. We are happy to credit you in the advisory, or to leave you out of it, whichever you prefer.

These are targets a small project can meet, not a contract. If you have not heard back inside the response window, send a reminder to security@brig.sh.

In scope is anything that breaks a promise Brig actually makes:

• a run that reaches a host credential it was not given, or a file outside the guest home
• a credential that leaks off the intended channel
• the secret store handing back an item it must not
• image verification passing something it must reject
• a tampered release verifying as genuine

CONTRIBUTING.md calls the first two the two promises. docs/security.md is where the exact edges of all of them are written down.

Out of scope are the limitations Brig already declares. docs/security.md lists them under Things brig does not claim:

• Brig does not sandbox the agent from the network by default
• Brig does not isolate one sandbox from another under the default shared network (--network isolated and --network offline are the postures that do)
• Brig does not filter terminal escape sequences the agent writes
• Brig does not stop an agent misusing a credential it was deliberately handed

A report that Brig does one of those is describing a known limitation, not a vulnerability. That page is the authority on the boundary, so we point at it here rather than restate it, which keeps the two from drifting apart. If you think one of those limitations is worse than the page admits, that is worth a report. The same is true if the page is wrong about where a line sits.