Repository navigation
security: a disclosure policy, and Dependabot for the four dependency surfaces - #44
Conversation
… 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) <noreply@anthropic.com>
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes in this run: the full PR (2 files, disclosure policy + Dependabot).
SECURITY.md— Private disclosure via GitHub vulnerability reporting, report contents, response expectations, and a supported-versions table limited to the latest0.xline (0.9.x, matching currentCHANGELOG)..github/dependabot.yml— Weekly updates for the four in-tree surfaces:gomodat/,npmat/frontend(pnpm),github-actionsat/, anddockerat/.
All four Dependabot ecosystems match files that exist on the tree (go.mod/go.sum, frontend/package.json + pnpm-lock.yaml, .github/workflows/*, root Dockerfile). No application behavior changes.
ℹ️ Enable private vulnerability reporting after merge
SECURITY.md sends reporters only to the Security tab’s Report a vulnerability button and forbids public issues/PRs. That button appears only when the repo setting Private vulnerability reporting is on. If it is still off, the policy has no working intake path.
Technical details
# Enable PVR so SECURITY.md intake works
## Affected sites
- Repo Settings → Code security and analysis → Private vulnerability reporting (not in this PR)
- SECURITY.md “Reporting a vulnerability” section assumes the button exists
## Required outcome
- After merge, PVR is enabled on Calnode/calnode so external reporters can open a private thread as documented
- Optional: confirm the Security tab shows both the policy and the report button
## Open questions for the human
- None if PVR is already on; this is a one-time settings checkGrok | 𝕏
shockalotti
left a comment
There was a problem hiding this comment.
Happy with both files in substance — SECURITY.md matches how we actually operate (latest 0.x line only, private reporting, advisory on release) and the four dependabot surfaces are the right four. Two asks before merge:
-
Cadence: monthly, not weekly. A weekly feed across four ecosystems is more bot-PR noise than this project wants — we batch dependency updates by hand (see #43) and a standing weekly drumbeat will just train us to ignore it. Please flip all four
schedule.intervalentries tomonthly. Security fixes still reach us same-day through the Scorecard badge +AUDIT.mdscanner block, so nothing urgent waits on the bot. -
Confirm the reporting button exists.
SECURITY.mdsends reporters to the Security tab's "Report a vulnerability" flow — that needs private vulnerability reporting enabled in Settings → Code security. That's a settings click on my side after merge; noting it here so it doesn't get lost. If it's already on, ignore this.
A weekly feed across four ecosystems is more bot pull requests than this project wants: dependency updates are batched by hand, and a standing weekly drumbeat trains a maintainer to ignore it. Security fixes do not wait on this schedule; they arrive through the Scorecard badge and the audit workflow's scanners the day they are published. All four surfaces keep the same directories; only the interval changes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes since the prior Pullfrog review: Dependabot schedule cadence only (ad2bf61).
- Monthly interval — All four ecosystems in
.github/dependabot.yml(gomod,npm,github-actions,docker) now useschedule.interval: monthlyinstead ofweekly.SECURITY.mdis unchanged.
Grok | 𝕏
|
Both done.
|

Two files Scorecard looks for and the repository does not have.
SECURITY.mdpoints reporters at GitHub's private vulnerability reporting (the Security tab's "Report a vulnerability" button) rather than an email address, says what to include, and says what to expect: an acknowledgement within a few days, then a fix or a written reason, a public advisory with the release, and credit if wanted. It states the support policy as it is today for a pre-1.0 project: fixes land on the latest0.xline only. If you would rather name an address or a different support window, that is a two-line edit..github/dependabot.ymlcovers the four dependency surfaces the tree actually has, all monthly:gomodat the root,npminfrontend/(pnpm is handled by the npm ecosystem),github-actions, anddockerfor the rootDockerfile. Monthly rather than weekly because dependency updates here are batched by hand, and security fixes do not wait on this schedule. No groups, no ignores; it can be tuned once the first batch of PRs shows what the noise level is.🤖 Generated with Claude Code