Page History

Per the ASF Security Process, you must not make information about the a vulnerability in your own code public until it is formally announced at the end of this that process. That means, for example, that you should not create a public Jira ticket to track the issue, or a public GitHub issue, since those would make the issue public. Messages associated with any commits should not make any reference to the security nature of the commit.fact that it fixes a vulnerability.

This does not mean you can't privately reach out to trusted individuals to help out with specific issues - see Getting help handling security reports.

To bridge the gap between working in private and our public approach to writing software, generally the recommended approach Generally, the preferred approach to this is to still use the public commit and review process, but without leaking the security impact of the change. Best is when you can combine the security-relevant change with a general cleanup or refactor that obscures it. Alternatively, for the kind of issues that are easy to find with vulnerability scanning tools, it might be inevitably obvious that a given change is a 'security-related' change, but you could leave the fact that this is actually an exploitable vulnerability rather than a 'defense-in-depth hardening improvement' obscured.

...