docs: route vulnerability reports to the ASF security team

[ppkarwasz]

Problem

SECURITY.md currently asks reporters to send vulnerability reports to dev@geaflow.apache.org. That is a publicly archived mailing list, so anyone following our own instructions discloses the vulnerability to the world at the moment they report it, before the project has had any chance to fix it.

Change

• Reports go to security@apache.org instead, with links to the ASF reporting guide and the vulnerability handling policy.
• Document the ASF submission conventions the security team expects: plaintext, one finding per e-mail.
• Drop private@geaflow.apache.org. To be clear, that list was not part of the leak (it is not publicly archived), it is removed only to keep a single entry point.

Open question for the PPMC: which security address?

This is the part I would like discussed, since the PR picks one of two valid options and the project may prefer the other.

Option A: request security@geaflow.apache.org. Reports land directly on the project and the PPMC handles the whole lifecycle itself: triage, acknowledgement, CVE request, coordination with the reporter. Maximum control and no intermediate hop, but the project also absorbs everything that arrives, including the steady stream of automated scanner output and reports that are
not vulnerabilities at all.

Option B (what this PR implements): point at security@apache.org. The ASF Security Team takes a first pass before forwarding anything to us. That triage is admittedly very light on its own, mostly filtering the obviously invalid, and
it gets substantially more valuable once a project has documented a security model, because the team can then close out reports that fall outside that model without ever involving the project. See Documenting your security model.

My suggestion is to merge Option B now, since it is strictly better than the status quo either way, and treat "write down GeaFlow's security model" as the follow-up that makes the choice actually pay off.

If the PPMC would rather own the whole flow, switching to Option A later is a one line change plus an INFRA ticket.

[Leomrlin]

LGTM

[Loognqiang]

LGTM

[Loognqiang]

Hi Piotr, Thank you for catching this critical issue with our current SECURITY.md. You are absolutely right that sending reports to a publicly archived list is a security risk, and we appreciate your quick action to fix it. Regarding the open question, I support **Option B** (routing to ***@***.***). As an incubating project, our primary focus is on development and community growth. Leveraging the ASF Security Team for initial triage will help us filter out noise (such as automated scanner outputs and invalid reports) and allow us to focus on genuine vulnerabilities. This aligns well with the "strictly better than status quo" argument you made. We also agree with your suggestion to treat "documenting GeaFlow's security model" as a follow-up task. This will further enhance the effectiveness of the ASF Security Team's triage process in the future. +1 to merge this PR as is. Best regards, loogn Piotr P. Karwasz ***@***.***> 于2026年8月4日周二 20:30写道：

…

Problem SECURITY.md currently asks reporters to send vulnerability reports to ***@***.*** That is a *publicly* archived mailing list, so anyone following our own instructions discloses the vulnerability to the world at the moment they report it, before the project has had any chance to fix it. Change - Reports go to ***@***.*** instead, with links to the ASF reporting guide <https://security.apache.org/report-code/> and the vulnerability handling policy <https://www.apache.org/security/committers.html#possible>. - Document the ASF submission conventions the security team expects: plaintext, one finding per e-mail. - Drop ***@***.*** To be clear, that list was not part of the leak (it is not publicly archived), it is removed only to keep a single entry point. Open question for the PPMC: which security address? This is the part I would like discussed, since the PR picks one of two valid options and the project may prefer the other. *Option A: request ***@***.*** ***@***.***>.* Reports land directly on the project and the PPMC handles the whole lifecycle itself: triage, acknowledgement, CVE request, coordination with the reporter. Maximum control and no intermediate hop, but the project also absorbs everything that arrives, including the steady stream of automated scanner output and reports that are not vulnerabilities at all. *Option B (what this PR implements): point at ***@***.*** ***@***.***>.* The ASF Security Team takes a first pass before forwarding anything to us. That triage is admittedly very light on its own, mostly filtering the obviously invalid, and it gets substantially more valuable once a project has documented a security model, because the team can then close out reports that fall outside that model without ever involving the project. See Documenting your security model <https://cwiki.apache.org/confluence/spaces/SECURITY/pages/308153000/Documenting+your+security+model> . My suggestion is to merge Option B now, since it is strictly better than the status quo either way, and treat "write down GeaFlow's security model" as the follow-up that makes the choice actually pay off. If the PPMC would rather own the whole flow, switching to Option A later is a one line change plus an INFRA ticket. ------------------------------ You can view, comment on, or merge this pull request online at: #828 Commit Summary - 3fafe74 <3fafe74> docs: route vulnerability reports to the ASF security team File Changes (1 file <https://github.com/apache/geaflow/pull/828/files>) - *M* SECURITY.md <https://github.com/apache/geaflow/pull/828/files#diff-f6ed156e4bf5c791680662464b94ea5d753f219ee816b385f67870e2c0d7d4c7> (17) Patch Links: - https://github.com/apache/geaflow/pull/828.patch - https://github.com/apache/geaflow/pull/828.diff — Reply to this email directly, view it on GitHub <#828?email_source=notifications&email_token=AAUMOBJHEYMMO6CBKI26RI35IHJMRA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF42DEMBTGMZTONZQGGTHEZLBONXW5KTTOVRHGY3SNFRGKZFFMV3GK3TUVRTG633UMVZF6Y3MNFRWW>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUMOBKY2QTLBFEJMI45J7D5IHJMRAVCNFSNUABFKJSXA33TNF2G64TZHM3DIOJVGA2TKOBYHNEXG43VMU5TKMBWGA2DKNJXGQ22C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAUMOBJRML6FVVRYV5EMZMT5IHJMRA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF42DEMBTGMZTONZQGGTHEZLBONXW5KTTOVRHGY3SNFRGKZFFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/AAUMOBNLRIYDVHAZ4RA7SPD5IHJMRA5CNFSNUABEM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UF42DEMBTGMZTONZQGGTHEZLBONXW5KTTOVRHGY3SNFRGKZFFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ppkarwasz]

Hi @Loognqiang,

You are welcome. When you have some time, please take a look at apache/geaflow-website#25 and modify directly the PR branch (you should have access to it). Once we know what are GeaFlow's deployment expectation, we can reject false positives citing your own documentation.