docs: Add a security policy - #6692
Conversation
The repository has no SECURITY.md in any location, including the org-level .github repo, and neither the README nor the contributing guide mentions vulnerability reporting. Private vulnerability reporting is enabled and in active use, but with no policy file GitHub only surfaces it on the Security tab, so a reporter has to already know to look there. Issue feast-dev#3684 shows the cost: a researcher asked how to disclose privately in July 2023, was pointed at Slack, and waited seven months for a contact address which then bounced. Disclosure completed only via a maintainer's personal email, and the gap itself was never closed. Adds a policy routing to the advisory form, states plainly that vulnerabilities must not go in issues, PRs, or Slack, and points the contributing guide's getting-started step at it, since that step currently sends everything to an issue or draft PR. Claims no response-time commitment and lists no email address: the maintainers can add those if they want them. Signed-off-by: Larry Singleton <166439969+larrysingleton007@users.noreply.github.com>
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #6692 +/- ##
=======================================
Coverage 46.77% 46.77%
=======================================
Files 414 414
Lines 50191 50191
Branches 7181 7181
=======================================
Hits 23475 23475
Misses 25077 25077
Partials 1639 1639
Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
|
@ntkathole @franciscojavierarceo Could one of you take a look, or route it? It needs a |
|
@larrysingleton007 Thanks, this looks good, I also think we need to add some guidelines notes on
|
Adds the three points ntkathole asked for in review: a duplicate check against published advisories before reporting, explicit report requirements (affected version, proof of concept or reproduction steps, actual impact), and a statement that unverified bulk, automated or AI-generated submissions may be closed without further response. Folded into the existing reporting section rather than appended as new sections, since the previous text already asked for reproduction detail and the advisories link already existed at the bottom. Also notes why raw scanner output alone is not enough: it does not establish that the issue is reachable in Feast. Signed-off-by: Larry Singleton <166439969+larrysingleton007@users.noreply.github.com>
|
@ntkathole The duplicate check now comes first, before the report requirements. Requirements are affected version or commit, a proof of concept or reproduction steps, and actual rather than theoretical impact. The last paragraph covers unverified bulk, automated and AI-generated submissions being closable without further response. One thing I added beyond your list: a line on why raw scanner or dependency-audit output isn't enough on its own, namely that it doesn't establish the issue is reachable in Feast. That seemed to be the underlying reason for the PoC requirement, and saying it out loud gives maintainers something concrete to point at when closing one. Drop it if you'd rather keep the policy shorter. |
What this PR does / why we need it
Adds a
SECURITY.mdso the vulnerability reporting path is discoverable.Private vulnerability reporting is already enabled on this repository and in active use (CVE-2026-55563, published in June, credits an outside reporter). But there is no policy file in the repo root,
.github/,docs/, or the org-levelfeast-dev/.githubrepo, and neither the README nor the contributing guide mentions security reporting. Without a policy file GitHub only surfaces the option on the Security tab, so a reporter has to already know to look there.The policy routes to the advisory form, states plainly that vulnerabilities must not go in issues, PRs, or Slack, and notes that fixes land in the latest release, consistent with the versioning policy's best-effort community support and no LTS branch.
This also adds one line to the contributing guide's getting-started step, which currently directs everything to "create a GitHub issue or make a draft PR". That is exactly the advice that misfires for a vulnerability report.
Deliberately omitted: any response-time commitment, triage roster, or contact email. Those are the maintainers' to make rather than mine to assert, and #3684 records a mailing list address that turned out to bounce, so an address seems worth confirming before publishing one. Happy to add any of it if you would like it included.
Which issue(s) this PR fixes
Fixes #6691