Security
Security policy
Report a security problem in Brig through the private channels below, and not in a public issue.
Brig holds a boundary. An agent gets one directory and the credentials it was named, and nothing else on the host. A security problem is anything that weakens that boundary, or that reaches something the agent was not given.
We fix the problem with you before it is public. If you are not sure that something counts, report it.
Supported versions #
The supported version is the latest release. brig version prints the version you are on.
Fixes land on main and go out in the next release. We do not backport.
If you report against an older version, first verify that the problem still reproduces on the latest release.
Reporting a vulnerability #
Use GitHub's private vulnerability reporting. Open the advisory page and press Report a vulnerability.
That opens a private thread that only you and the maintainers can see. Nothing is disclosed while we work on a fix.
To use email instead, write to security@brig.sh. Both reach the same people.
Warning Do not open a public issue for a security problem. Do not send a pull request that reveals the flaw before an advisory exists.
Include what a fix needs:
- the version from
brig version - the operating system
- the runtime, named as in the table below
- what you did, what happened, and what you expected instead
A proof of concept helps, even a rough one.
| Your setup | Runtime to name |
|---|---|
| macOS | hull |
| Linux | nerdctl with the urunc shim |
Linux with BRIG_CONTAINERD_RUNTIME=runc set |
runc |
Response targets #
| Target | Meaning |
|---|---|
| First response within 3 working days | an acknowledgement from a human that the report arrived and is being looked at. It is 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 a fix takes longer than 90 days, we say so in the thread and agree a new date with you. If a fix ships sooner, the advisory goes out sooner.
We credit you in the advisory or leave you out of it, as you prefer.
These are targets, not a contract. If you get no answer inside the response window, send a reminder to security@brig.sh.
In scope #
Anything that breaks a promise Brig makes is in scope:
- 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 calls the first two the two promises. Security states the edges of every promise.
Out of scope #
The limitations Brig already declares are out of scope. Security lists them under Known limitations:
- Brig does not sandbox the agent from the network by default.
- Brig does not isolate one sandbox from another when it uses the shared network. That includes a retained older session and a
vzorqemubackend fallback. The postures that do isolate areisolated, the default for newhviand Linux sandboxes, andoffline. - Brig does not filter terminal escape sequences the agent writes.
- Brig does not stop an agent misusing a credential you delivered to it.
A report that Brig does one of those describes a known limitation, not a vulnerability.
Two kinds of report about those limitations are still welcome:
- you think one of them is worse than the page admits
- the page is wrong about where a line sits