*** Unsent and unapproved draft ***
About the Apache Software Foundation
The ASF is a US 501(c)3 non-profit charity that acts as a steward for several hundred open source projects. The ASF is one of the largest open source organizations in the world, and is home to prolific projects such as Apache Hadoop, Apache Tomcat, Apache Cassandra, and scores of others. The ASF provides a known and vetted set of governance, intellectual property, and release processes as well as providing a vendor-neutral place for contributors to collaborate. However, within those processes there is a high degree of autonomy for each project. Projects decisions are driven by the people doing the work. The ASF Board of Directors is responsible for project oversight, ensuring the health and vitality of each project.
In brief numbers the ASF has:
- 227 Million lines of code
- 630,000+ contributors
- 8,370+ committers (individuals who have earned the status of being able to directly change source code).
- 200+ projects
How the ASF keeps our projects secure
...
- ASF projects are run by Project Management Committees (PMCs). PMC members nominate and vote on new PMC members and collectively manage community, security, trademarks, or other problems.
- Projects to have to adhere to various foundation-wide policies including trademarks, release policy, security vulnerability handling policy. ASF policies require PMC reviews with minimum levels of voting required for new releases.
- All changes to project source code are tracked and visible to all interested parties.
- The ASF has a security team and a VP of security and acts with board authority. The ASF security team sets a common policy, maintains security contacts for PMCs, and provides support for projects responding to security issues.
About the recent issues in log4j
...
- We support the notion of identifying critical components. As our software is without cost and can be downloaded by anybody, we have no way of knowing how widely our projects are used. This means that by necessity determining if a component is critical can only either be determined by automated means which is always going to be incomplete and imperfect, or more manually such as by identifying critical products first, and then getting an inventory of what components those products embed. This problem is not unique to the ASF, so it makes sense for there to be industry standards and best practices. We are prepared to participate in these activities.
- We eagerly welcome audits and fixes from any source. We have a process defined for doing so: https://www.apache.org/security/. Our one caution is that we have prior experiences with audits and it is not productive when those audits produce a number of false positives. See https://s.apache.org/fhoji. It is worth noting that many automated means of performing an audit are more suited to detecting bugs inside a single component rather than identifying a vulnerability that is composed of combination of intentional features such as the one we saw with log4j. It is better when these audits are performed by skilled resources who are able to accurately identify actual issues, produce fixes, and therefore reduce the burden on each project.
- It is particularly frustrating to us that we can produces fixes for critical issues in a matter of days or weeks and not to have those fixes be picked up for months or years, despite having a common and industry standard process for disclosing vulnerabilities and fixes. This is the problem that we see as most pressing.