If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private. (URL required)
Examples include a private defect report submitted on the web using HTTPS (TLS) or an email encrypted using OpenPGP. If vulnerability reports are always public (so there are never private vulnerability reports), choose "not applicable" (N/A).
Is unencrypted (but otherwise private) email intended to pass this criterium?
If so, that might be worth clarifying: from "encrypted using OpenPGP" you could get the impression it needs to be encrypted.
If it is intended that unencrypted email does not pass this criterium, I think it is worth considering changing it to 'SUGGESTED' or moving it to the silver/gold level. Anecdotally, we had PGP keys on the ASF security reporting page, but haven't received an encrypted email in years - reporters seem to be happy to use plaintext email. While platforms like GitHub Private Vulnerability Reporting are getting more popular, they don't fit all workflows.
The description for
vulnerability_report_privateon https://www.bestpractices.dev is currently:Is unencrypted (but otherwise private) email intended to pass this criterium?
If so, that might be worth clarifying: from "encrypted using OpenPGP" you could get the impression it needs to be encrypted.
If it is intended that unencrypted email does not pass this criterium, I think it is worth considering changing it to 'SUGGESTED' or moving it to the silver/gold level. Anecdotally, we had PGP keys on the ASF security reporting page, but haven't received an encrypted email in years - reporters seem to be happy to use plaintext email. While platforms like GitHub Private Vulnerability Reporting are getting more popular, they don't fit all workflows.