dejima/dejima-ci-hardener
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

State plainly that there is no support, and where to send a vulnerability #13

Merged
branderson merged 1 commits from security-policy into main 2026-08-09 03:13:40 -07:00
Conversation 1 Commits 1 Files Changed 2
+38
2 changed files with 38 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+5
View File
@@ -16,6 +16,10 @@ For *why* any of this is necessary - what a CI run adds over a sandbox, and
why no approval gate is offered - see [dejima's `docs/ci.md`](https://gitbox.branderson.io/dejima/dejima/src/branch/main/docs/ci.md). You do
not need it to follow this.
**One maintainer, no support.** Nothing about this is promised: not a reply,
not a fix, not a release. [SECURITY.md](SECURITY.md) has the detail, and is
where to report a vulnerability rather than in a public issue.
## Do not install this next to dejima
This runs on a machine whose job is to execute untrusted code. dejima runs on
@@ -315,6 +319,7 @@ and failing it means the runner needs attention rather than the branch.
| [docs/](docs/) | Index of everything below |
| [docs/reference.md](docs/reference.md) | The two `docker.sock` settings, `CONFIG_FILE`, the `/data` volume, compose networks against job networks, sharing a job network between runners, why the privileged runner is separate, why the resolver is per-runner, the cache server |
| [proxmox/README.md](proxmox/README.md) | Building the sacrificial VM: node firewall rules, bootstrap, snapshot, scheduled rollback |
| [SECURITY.md](SECURITY.md) | What this software claims and where to report a vulnerability; links on to the organisation-wide policy for the rest |
| [dejima's `docs/ci.md`](https://gitbox.branderson.io/dejima/dejima/src/branch/main/docs/ci.md) | Why a CI runner needs any of this, and why there is no approval gate |
## License
SECURITY.md
+33
View File
@@ -0,0 +1,33 @@
# Security policy
## What dejima-ci-hardener claims
It reduces what a job can reach. It does not make a host safe.
A confined runner is given no Docker socket, its own bridge, and a
deny-by-default egress allowlist. A privileged runner is given the socket and
the host network deliberately, and its containment is the hypervisor firewall
and a scheduled rollback, not anything this program does inside the guest.
Neither tier holds against an attacker who is already root on the box.
The README's [How it fails](README.md#how-it-fails) section covers this in
detail.
## Reporting a vulnerability
Email **dejima@branderson.io**. Please do not open a public issue for a
vulnerability; the tracker is public, and a report there is a disclosure.
Useful things to include:
1. what an attacker gets;
2. the steps to reproduce it;
3. which tier it applies to: confined, privileged, or both;
4. the commit you tested.
## The rest of the policy
What is promised in return, the support position, supported versions and
warranty are set once for the whole organisation and are not restated here:
https://gitbox.branderson.io/dejima/dejima/src/branch/main/SECURITY.md