Fail CI before security.txt expires - #671
Merged
Merged
Conversation
RFC 9116 makes Expires mandatory, and past that date the file is invalid rather than merely stale — it keeps serving 200 while scanners treat it as unusable. Nothing renewed it: website/ has no build step and the repo has no scheduled workflow, so the date would have passed in silence and left a worse signal than shipping no security.txt at all. Graduated alarm instead of relying on memory: > 90 days passes silently 90-30 days passes, warns in CI output < 30 days fails, naming the file and the fix expired fails, reporting how many days ago > 1 year fails — blocks "renewing" it by setting a date in 2099 Verified against all four future states by moving the date, not just the current one. Also corrects the README: production confirmed Cloudflare Workers assets does upload dot-directories, so the "verify .well-known deploys" caveat is resolved. Notes the residual gap honestly — the guard only fires when CI runs, so a long-quiet repo could still let the date slip.
Contributor
Contributor
Coverage Report for Frontend Coverage (frontend)
File CoverageNo changed files found. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #670, which shipped
.well-known/security.txtwith a caveat I flagged at the time: nothing renews it.The problem
RFC 9116 makes
Expiresmandatory, and once that date passes the file is invalid, not merely stale — it keeps returning 200 while scanners and researcher tooling treat it as unusable.website/has no build step and the repo has no scheduled workflow, so the date would have slipped in complete silence, leaving a worse signal than shipping nosecurity.txtat all.The guard
frontend/src/config/__tests__/websiteSecurityTxt.test.tsturns the deadline into a CI failure with lead time:That last row is deliberate: it blocks "renewing" the file by setting
Expiresto 2099, which would pass a naive check while still being wrong.Verified by moving the date through all four future states, not just running it against today.
Renewal is intentionally a human step
The date is a claim that the contact information is still current, so auto-bumping it on deploy would defeat the purpose. Renewing means setting
Expiresone year out and confirming the Contact URL still accepts reports.Known gap
The guard only fires when CI runs. That is frequent enough for this repo, but a long-quiet period could still let the date slip. A scheduled workflow opening an issue would close it — deliberately not added here, since it would be the repo's first cron workflow. The trade is documented in
website/README.md.Also
Corrects a caveat from #670: production confirmed Cloudflare Workers assets does upload dot-directories (
/.well-known/security.txtreturns 200,text/plain), so the "verify it deploys" note is resolved.Verification
1327 frontend tests, typecheck and lint (0 errors) all pass.