Skip to content

docs: add SECURITY.md with a private reporting route and explicit scope - #55

Open
stefanwb wants to merge 1 commit into
mainfrom
worktree-security-policy
Open

docs: add SECURITY.md with a private reporting route and explicit scope#55
stefanwb wants to merge 1 commit into
mainfrom
worktree-security-policy

Conversation

@stefanwb

@stefanwb stefanwb commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

The repository is public and had no security policy and no private intake
channel, so the only route available to an outside reporter was a public
issue — which is how a finding ends up disclosed badly.

Private vulnerability reporting has been enabled on the repository, so the
"Report a vulnerability" button is now live on the Security tab. This adds the
written policy behind it.

What it says

  • Report privately, with a direct link to the advisory form, and a fallback
    (open an issue asking for a private channel, no details).
  • What to include — commit/release, wrapper flags, runtime and host OS,
    impact. Explicitly asks for the class of problem rather than a working
    exploit, and asks reporters to keep real credentials, tokens and transcript
    content out of reports.
  • Honest expectations — best-effort maintenance, no bounty, no guaranteed
    response time, no backports before 1.0, and a note that the image is rebuilt
    rather than pulled so "upgrade" means rebuild.

The scope section is the load-bearing part

It lists the threat-model properties that are documented rather than defective
— no egress filtering, runtime code-fetch via npx/pnpm dlx/uvx/tfenv,
read-write workspaces without --ro, in-session visibility of opted-in
credentials, cross-session persistence in the named volumes, and --yolo as a
deliberate mode — then draws the distinction that matters:

A finding that a documented boundary does not hold as documented is in
scope and welcome — that is different from reporting the documented boundary
itself.

That keeps genuine findings welcome while pre-empting a stream of "the
container has network access" reports. Upstream CLI vulnerabilities are routed
to their own projects, and image CVEs to the existing Trivy + .trivyignore
accepted-risk process.

Notes for review

  • Docs only. No spec touched and no behaviour changed, so per AGENTS.md this
    needs no OpenSpec change.
  • Both relative links resolve (README.md#install, README.md#threat-model,
    .trivyignore); CI markdownlint and lychee are both continue-on-error and
    lychee runs offline, so the external advisory URL is not fetched.

🤖 Generated with Claude Code

The repository is public and had no security policy and no private intake
channel, so the only route available to an outside reporter was a public issue
— which is how a finding ends up disclosed badly. Point reporters at GitHub
private vulnerability reporting, and set expectations honestly: best-effort
maintenance, no bounty, no backports before 1.0, and the image is rebuilt
rather than pulled so "upgrade" means rebuild.

The scope section is the load-bearing part. It lists the threat-model
properties that are documented rather than defective — no egress filtering,
runtime code-fetch via npx/pnpm dlx/uvx/tfenv, read-write workspaces without
--ro, in-session visibility of opted-in credentials, cross-session persistence
in the named volumes, and --yolo as a deliberate mode — and then draws the
distinction that actually matters: a documented boundary failing to hold as
documented is in scope; the documented boundary itself is not.

Also asks reporters to describe the class of problem rather than attach working
exploits, and to keep real credentials and transcript content out of reports.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant