The gap
There is no SECURITY.md in this repository, in .github/, in docs/, or in the org-level feast-dev/.github repo. Neither the README nor the contributing guide mentions vulnerability reporting.
Private vulnerability reporting is enabled and works: CVE-2026-55563 was published in June and credits an outside reporter. But with no policy file, GitHub only surfaces that path on the Security tab. A reporter has to already know to look there, and the contributing guide's getting-started step points everything at "create a GitHub issue or make a draft PR", which is the wrong advice for a vulnerability.
Why it is worth closing
This has already cost the project once. In #3684, a security researcher asked how to disclose privately in July 2023. They were pointed at Slack, replied that joining a Slack workspace to report a bug was awkward and asked for an email address, and then waited until February 2024 for one. That address bounced, and disclosure completed only through a maintainer's personal email. The issue was closed as completed, but the missing signpost was never added.
It came up again this week: someone asked the same question in the community Slack, could not find a SECURITY.md, and pushed back when told to open an issue, correctly pointing out that a public issue discloses the problem before a fix exists.
So the same question has now been asked by two outside reporters roughly three years apart, and the ad-hoc answers have measurably failed. Unlike 2023, the fix is nearly free, because the reporting channel already exists and only needs a sign pointing at it.
Proposed fix
A SECURITY.md at the repository root that routes to the advisory form, states plainly that vulnerabilities do not go in issues, PRs, or Slack, and notes that fixes land in the latest release. Plus a line in the contributing guide's getting-started step, since that is where the misdirection currently happens.
Deliberately not proposed: any response-time commitment, triage roster, or email address. Those are yours to add if you want them, and the #3684 history suggests an address is worth confirming before publishing one.
PR attached.
The gap
There is no
SECURITY.mdin this repository, in.github/, indocs/, or in the org-levelfeast-dev/.githubrepo. Neither the README nor the contributing guide mentions vulnerability reporting.Private vulnerability reporting is enabled and works: CVE-2026-55563 was published in June and credits an outside reporter. But with no policy file, GitHub only surfaces that path on the Security tab. A reporter has to already know to look there, and the contributing guide's getting-started step points everything at "create a GitHub issue or make a draft PR", which is the wrong advice for a vulnerability.
Why it is worth closing
This has already cost the project once. In #3684, a security researcher asked how to disclose privately in July 2023. They were pointed at Slack, replied that joining a Slack workspace to report a bug was awkward and asked for an email address, and then waited until February 2024 for one. That address bounced, and disclosure completed only through a maintainer's personal email. The issue was closed as completed, but the missing signpost was never added.
It came up again this week: someone asked the same question in the community Slack, could not find a SECURITY.md, and pushed back when told to open an issue, correctly pointing out that a public issue discloses the problem before a fix exists.
So the same question has now been asked by two outside reporters roughly three years apart, and the ad-hoc answers have measurably failed. Unlike 2023, the fix is nearly free, because the reporting channel already exists and only needs a sign pointing at it.
Proposed fix
A
SECURITY.mdat the repository root that routes to the advisory form, states plainly that vulnerabilities do not go in issues, PRs, or Slack, and notes that fixes land in the latest release. Plus a line in the contributing guide's getting-started step, since that is where the misdirection currently happens.Deliberately not proposed: any response-time commitment, triage roster, or email address. Those are yours to add if you want them, and the #3684 history suggests an address is worth confirming before publishing one.
PR attached.