From 568e6d3d4f2d8ebd61707f2aec14e4e0dabf1e3a Mon Sep 17 00:00:00 2001 From: Distronode <254259913+distronode-com@users.noreply.github.com> Date: Fri, 11 Sep 2026 02:07:24 -0400 Subject: [PATCH] security: a disclosure policy, and Dependabot for the four dependency surfaces There was no SECURITY.md, so someone who found a vulnerability had nowhere obvious to send it and no idea what would happen to it. The one added here points at GitHub's private vulnerability reporting rather than an email address - it is already available on this repository, it does not need a mailbox anyone has to remember to watch, and it gives the reporter a private thread instead of an issue that discloses the bug the moment it is filed. It also says what a report should contain, what response to expect and by roughly when, and that credit is offered if the reporter wants it. Supported versions are stated as what is actually true pre-1.0: fixes land on the latest release line and are not backported. The Dependabot config covers the four places this repository takes a dependency, each on a weekly schedule: Go modules at the root, the SvelteKit admin app under /frontend (pnpm is handled by the npm ecosystem), the actions pinned in .github/workflows, and the base images in the root Dockerfile. No groups and no ignores - the point is to see the updates rather than to shape them, and a config with rules in it that nobody revisits is how a surface quietly stops being watched. The commit before this one closed fourteen advisories by hand; this is the part that means the next fourteen do not have to be found by hand. Co-Authored-By: Claude Opus 5 (1M context) --- .github/dependabot.yml | 26 +++++++++++++++++++++ SECURITY.md | 51 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 77 insertions(+) create mode 100644 .github/dependabot.yml create mode 100644 SECURITY.md diff --git a/.github/dependabot.yml b/.github/dependabot.yml new file mode 100644 index 0000000..8fe4c58 --- /dev/null +++ b/.github/dependabot.yml @@ -0,0 +1,26 @@ +version: 2 + +updates: + # Go modules (go.mod / go.sum at the repository root). + - package-ecosystem: gomod + directory: / + schedule: + interval: weekly + + # The SvelteKit admin app. pnpm is handled by the npm ecosystem. + - package-ecosystem: npm + directory: /frontend + schedule: + interval: weekly + + # Actions pinned in .github/workflows/. + - package-ecosystem: github-actions + directory: / + schedule: + interval: weekly + + # Base images in the root Dockerfile. + - package-ecosystem: docker + directory: / + schedule: + interval: weekly diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..e3b7bad --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,51 @@ +# Security policy + +## Supported versions + +Calnode is pre-1.0, and fixes go onto the latest release line only. There are no +backports to earlier `0.x` minors. + +| Version | Supported | +| ------- | --------- | +| 0.9.x | Yes | +| < 0.9 | No | + +If you are running an older tag, the fix for a reported issue will be an upgrade. + +## Reporting a vulnerability + +Please report privately, through GitHub's private vulnerability reporting: open the +repository's **Security** tab and use **Report a vulnerability**. That opens a private +thread visible only to you and the maintainers. + +Please do not open a public issue, a pull request, or a discussion for a security +report. A public issue is a disclosure, and it is one made before there is anything for +people to upgrade to. + +## What to include + +Enough to reproduce it. Usually that is: + +- what the problem is, and what an attacker gets out of it; +- the version, tag, or commit you tested; +- how you are running it (Docker image, `go build`, behind which proxy) and anything + non-default in your configuration; +- the steps, request, or proof-of-concept that triggers it; +- what you expected to happen instead. + +If you are not sure whether something is a vulnerability, report it anyway and say so. +An unclear report is easier to deal with than one that never arrives. + +## What to expect + +- **An acknowledgement within a few days.** If you have not heard anything after a week, + please post a follow-up on the same private thread in case it was missed. +- **Then either a fix or an explanation.** If we agree it is a vulnerability, we will + tell you roughly when a fix will land and let you know when it ships. If we do not + think it is one, we will say why rather than leaving the report open. +- **A public advisory when the fix is released**, through GitHub Security Advisories, so + people running Calnode know what they are upgrading for. +- **Credit, if you want it.** Tell us the name or handle to use, or tell us you would + rather stay anonymous. Either is fine. + +Please give us a reasonable chance to ship a fix before publishing the details.