security.txt is committed but not served (kubernetes.io/.well-known/security.txt returns 404; its own Canonical points there)

[kobihikri]

This is a Bug Report

Problem:

The security.txt file is committed to this repo but is not reachable at its published URL, and the file's own Canonical field points at that unreachable URL.

• https://kubernetes.io/.well-known/security.txt returns HTTP 404 (verified today).
• The file exists in this repo at .well-known/security.txt (repo root), added in Add a security.txt #44487.
• It does not exist under Hugo's publish source, static/.well-known/security.txt (404 via the GitHub contents API). Hugo only publishes files under static/ (plus rendered content); hugo.toml has no staticDir override and no module mount covering .well-known, and netlify.toml/Makefile have no step that copies repo-root .well-known/ into the build output. So the committed file is never deployed.

The committed file's contents include:

Contact: mailto:security@kubernetes.io
Expires: 2031-01-11T06:30:00.000Z
Canonical: https://kubernetes.io/.well-known/security.txt
Policy: https://github.com/kubernetes/website/blob/main/SECURITY.md

So the Canonical: line advertises a URL that currently 404s. Per RFC 9116 §3, security.txt is expected to be served under /.well-known/; a researcher visiting the well-known path today finds nothing. (The Expires value is a valid future date, so this is a deployment/path issue, not an expiry one.)

Proposed Solution:

Move the file so Hugo publishes it — i.e. to static/.well-known/security.txt (contents unchanged) — or add an equivalent static mount/redirect so /.well-known/security.txt resolves. I'm happy to open a small PR for whichever placement you prefer (I understand PRs require the CNCF EasyCLA).

Page to Update:
https://kubernetes.io/.well-known/security.txt

Reproduction: curl -sSL -o /dev/null -w '%{http_code}' https://kubernetes.io/.well-known/security.txt → 404. I used AI assistance to help investigate and draft this; I reproduced every fact above myself and take responsibility for the report.

[Bhavesh189]

Hi! I'd like to work on this issue. I'll investigate the root cause and submit a PR if the proposed fix is confirmed. Please let me know if someone is already working on it. Thanks!

[trevdem]

/unassign

[lmktfy]

/kind feature
/sig security

[lmktfy]

/priority important-longterm

It's part bug, part feature we didn't yet implement.
/triage accepted

I wonder if a Hugo mount would be helpful as part of the solution.