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
Collaborator

Summary generated by LLM agent

Adds a SECURITY.md and points at it from the README.

The project had no security contact. The only route for reporting a vulnerability was the public issue tracker, where filing the report is the disclosure. The file gives a private address, dejima@branderson.io, and asks people not to use the tracker for it.

It carries only what is specific to this repository. What is promised in return, the support position, supported versions and warranty are organisation-wide, so the file links to dejima's SECURITY.md for those rather than keeping a second copy that can drift out of step. That link 404s until the organisation-wide policy is published, in the same way #12's attribution links do, but the parts a reporter needs are local and this can merge before it resolves.

"What dejima-ci-hardener claims" comes first, ahead of the reporting instructions, so nothing reads as a pitch with the caveats appended afterwards. It says the tool reduces what a job can reach and does not make a host safe, that neither tier holds against an attacker already root on the box, and that the privileged tier's containment is the hypervisor firewall and the scheduled rollback rather than anything the program does inside the guest. The README's "How it fails" already covers this, so the section links there rather than restating it.

Reporting stays local because a policy that makes a reporter follow a link before they can find the address is a bad policy, and because one of the things worth including is project-specific: which tier the report applies to.

The README mentions it twice. Once in the opening block, where somebody deciding whether to deploy will see it before investing effort, and once as a row in Further reading. Nothing was added near the License section, which keeps this clear of the region #12 edits.

Tested: bats test/ passes, 87 ok and 0 failed. The #how-it-fails anchor was checked against the heading it targets. No functional code is touched.

This does not depend on #12 and can merge on its own.

**Summary generated by LLM agent** Adds a `SECURITY.md` and points at it from the README. The project had no security contact. The only route for reporting a vulnerability was the public issue tracker, where filing the report is the disclosure. The file gives a private address, `dejima@branderson.io`, and asks people not to use the tracker for it. It carries only what is specific to this repository. What is promised in return, the support position, supported versions and warranty are organisation-wide, so the file links to dejima's `SECURITY.md` for those rather than keeping a second copy that can drift out of step. That link 404s until the organisation-wide policy is published, in the same way #12's attribution links do, but the parts a reporter needs are local and this can merge before it resolves. "What dejima-ci-hardener claims" comes first, ahead of the reporting instructions, so nothing reads as a pitch with the caveats appended afterwards. It says the tool reduces what a job can reach and does not make a host safe, that neither tier holds against an attacker already root on the box, and that the privileged tier's containment is the hypervisor firewall and the scheduled rollback rather than anything the program does inside the guest. The README's "How it fails" already covers this, so the section links there rather than restating it. Reporting stays local because a policy that makes a reporter follow a link before they can find the address is a bad policy, and because one of the things worth including is project-specific: which tier the report applies to. The README mentions it twice. Once in the opening block, where somebody deciding whether to deploy will see it before investing effort, and once as a row in Further reading. Nothing was added near the License section, which keeps this clear of the region #12 edits. Tested: `bats test/` passes, 87 ok and 0 failed. The `#how-it-fails` anchor was checked against the heading it targets. No functional code is touched. This does not depend on #12 and can merge on its own.
dejima-agent added 1 commit 2026-08-08 23:06:40 -07:00
State plainly that there is no support, and where to send a vulnerability
tests / runner-env (confined) (pull_request_target) Successful in 1m24s
tests / runner-env (confined) (pull_request) Successful in 1m26s
tests / tests (pull_request) Successful in 1m53s
tests / compose-schema (pull_request) Successful in 1m32s
tests / tests (pull_request_target) Successful in 1m51s
tests / compose-schema (pull_request_target) Successful in 1m32s
tests / runner-env (privileged) (pull_request) Successful in 1m24s
tests / runner-env (privileged) (pull_request_target) Successful in 1m23s
b34b1a016c
The project had no security contact, so the only route for a vulnerability was the public issue tracker, where filing one is the disclosure. SECURITY.md gives a private address and asks people not to use the tracker.

The file carries only what is specific to this repository: what dejima-ci-hardener claims, and the reporting details. What is promised in return, the support position, supported versions and warranty are organisation-wide, so it links to dejima's SECURITY.md for those rather than keeping a copy that can drift.

What the software claims comes first, ahead of everything else. Neither tier holds against an attacker already root on the box, and the privileged tier's containment is the hypervisor rather than anything the program does inside the guest. The README's How it fails section covers it, so SECURITY.md links there too.

The README mentions it in the opening block and in Further reading.
dejima-agent force-pushed security-policy from 2595ce2826 to b34b1a016c 2026-08-08 23:06:40 -07:00 Compare
branderson approved these changes 2026-08-09 03:13:35 -07:00
branderson merged commit 3af05cb943 into main 2026-08-09 03:13:40 -07:00
Sign in to join this conversation.