| --- |
| title: Contributing to Apache Security |
| description: |
| aliases: |
| - /mailinglist |
| --- |
| |
| There are many ways you can help the ASF become more secure! |
| |
| ## Find vulnerabilities in ASF software |
| |
| If you're a software developer or security researcher, responsibly |
| reporting security issues in ASF projects is a great way to |
| contribute. Make sure you review the projects' security model, |
| typically linked on the [projects page](/projects), to understand |
| what to expect from the project. |
| |
| To privately disclose a security vulnerability in one |
| of our projects, use [the vulnerabity reporting process](/report). |
| |
| ## Join the conversation |
| |
| To discuss ASF-wide security-related topics, join the public `security-discuss` mailinglist: read the [archives](https://lists.apache.org/list.html?security-discuss@community.apache.org) and subscribe by emailing [security-discuss-subscribe@community.apache.org](mailto:security-discuss-subscribe@community.apache.org). Once subscribed, you can send your mail to [security-discuss@community.apache.org](security-discuss@community.apache.org). If you have access to the [ASF Slack](https://infra.apache.org/slack.html) you can also join `#security-discuss` there. |
| |
| We welcome your questions and are interested in your experience. |
| |
| ## Let us know how you'd like to consume ASF security information |
| |
| If you're a downstream consumer of Security-related information, |
| we would love to hear from you at |
| [security@apache.org](mailto:security@apache.org) - we're likely |
| happy to work with you to improve this process. |
| |
| ## Help document useful security documentation |
| |
| Security knowledge relevant to the ASF is collected on the |
| [SECURITY wiki space](https://cwiki.apache.org/confluence/display/SECURITY) - contributions warmly welcome! |
| |
| ## Help review GitHub Actions |
| |
| The ASF Infra team has a [list of approved GitHub Actions](https://github.com/apache/infrastructure-actions). |
| Your can help for example by seeing if there's any actions that |
| are only sparsely used, and help the projects that are still |
| relying on those to move to more widely-trusted solutions. |
| |
| ## Help individual projects |
| |
| ### Help triage and fix security issues |
| |
| If you're already closely involved in a project, you could ask |
| the PMC whether they'd appreciate help in triaging incoming |
| security reports or developing fixes. |
| |
| ### Help creating SBOMs |
| |
| To get more insight in a projects' dependency tree, it can be |
| useful to help their build/release process to include creating |
| [SBOMs](https://sbom.security.apache.org/) for their published |
| artifacts. |
| |
| ### Analyzing advisories in dependencies |
| |
| When security advisories are published for dependencies of ASF |
| projects, it is useful to help analyze whether the project is |
| [actually impacted](https://cwiki.apache.org/confluence/display/SECURITY/Dealing+with+security+advisories+for+dependencies) |
| by these issue, share that information, and help get the |
| dependency replaced/updated. |
| |
| ### Release automation |
| |
| Making it more lightweight to create a release could help get |
| security improvements in the hands of users faster. One thing |
| that can help for that is to help projects achieve |
| [reproducible builds](https://cwiki.apache.org/confluence/display/SECURITY/Reproducible+Builds) |
| and then [stage release candidates from CI](https://infra.apache.org/release-signing.html#automated-release-signing). |
| |
| A good first step might be to offer to act as |
| [release manager](https://www.apache.org/legal/release-policy.html) |
| for a release, so you get a hands-on experience of the status |
| quo. Many projects allow committers to RM, not just PMC members. |
