Pre-1.0. There is no released software yet, so there is nothing deployed to attack. This policy is published now because the design, the schema, and the threat model are public and worth reviewing early — and because a policy written after the first report is written badly.

Do not open a public issue, a discussion, or a pull request. Do not post it in Discord.

There is no bug bounty. This is a volunteer project run by people with day jobs, and pretending otherwise wastes your time. Credit in the advisory is given by default; anonymity on request.

A useful report contains: the version or commit, how the instance is deployed (container, bare binary, behind which reverse proxy), the affected endpoint or code path, what an attacker gains, and a reproduction — a curl sequence beats a paragraph. If you have a patch, say so; we will usually take it under the same DCO as any other change.

Realistic numbers for a small volunteer team. If we miss one, chase us — open a public issue saying only "awaiting a response on a private report, sent ", with no details.

Self-hosted software gets patched when the operator notices, so the support window is short on purpose and the notification is loud.

Run the :1 rolling tag — ghcr.io/dragonkillparty/dkp:1. It tracks the latest 1.x and is the documented default precisely so that docker pull && docker restart is the whole upgrade procedure. Every 1.x upgrades to any later 1.y; the nightly upgrade ladder tests that from the oldest supported refdb to HEAD.

You will be told. The daily update check returns {latest, min_safe_version, security, advisory_url}. When the running version is below min_safe_version the admin UI shows a persistent, non-dismissible banner, dkp doctor fails, and /ops flags it. There is no remote kill switch and no forced auto-update — both are backdoors. Notification is the whole mechanism, and it is the single control that most affects real-world risk in self-hosted software.

Anything in this repository, in the published container images, and in the released binaries.

Ranked by what a guild actually loses. A finding in any of these gets triaged at High or above before we look at the CVSS score.

Also very much in scope, without being their own row: authentication and session handling, stored or reflected XSS in any rich-text or name field, CSRF, SQL injection, idempotency or replay flaws that double-charge a bid or double-post a tick, PII disclosure, secret leakage in logs or error bodies, and supply-chain integrity of the published artifacts.

Safe harbour. Test against your own instance. We will not pursue good-faith research that stays within this policy, does not access other people's data, does not degrade a live guild's service, and gives us a reasonable window before disclosure. Testing against somebody else's guild instance without their written permission is not good faith and is not covered.

1. Fix on a private fork. Every security fix ships with a regression test; the fix and the test land together.
2. Advisory. A GHSA is published for every security fix, with a CVE requested through GitHub's CNA. It states the affected versions, the fixed versions, the impact in plain language, and — where one exists — a config-level workaround (DKP_COMPAT_ENABLED=false, DKP_OUTBOUND_ALLOW_PRIVATE=false, revoke-all-tokens) so an operator who cannot upgrade today can still act today.
3. Release. Security releases are patch-only and isolated from feature work, so the upgrade decision is never bundled with a behaviour change. A SECURITY: commit trailer drives the generated release notes.
4. Backport. The fix goes to the latest minor and, within its 90-day window, to the previous minor, via the backport/1.x label. A release-1.x maintenance branch is created lazily, only when one is actually needed.
5. Notify. min_safe_version in the advisory feed is raised, which turns on the in-product banner and fails dkp doctor on every unpatched instance.
6. Post-mortem where it is useful. If the bug class could recur, the fix includes the mechanism that stops it recurring — a lint rule, a CI gate, a database trigger — and the ADR that explains it. A rule without a mechanism is a wish.

A control listed as planned is not running. This table states what is wired up today, because a security document that describes intentions in the present tense is worse than one that says nothing — it stops anyone from noticing the gap.

To run the two live dependency controls locally:

make licence-gate && make govulncheck

make check runs the licence gate as part of make lint. govulncheck is not in make check — not because it is slow (it takes about four seconds) but because it fetches the vulnerability database from vuln.go.dev, and make check is expected to work without connectivity. CI runs it as its own required job.

The runtime image is FROM scratch: no shell, no package manager, no interpreter, and therefore no base-image CVE feed. A :1-debug tag exists for people who need to exec in, and its larger attack surface is documented where it is offered.