...
Executive Summary / Key Take-Aways
- You don
We can't fix open source supply chain issues by focusing exclusively on the upstream producer
.If we could somehow make Even perfect releases of all ASF projects tomorrow, it would literally take years before we would see the effects. And plenty of cases where the update would never be appliedcan take years to be adopted and deployed by downstream providers.
Community is defined by those who show up
.We have many components which are widely used, yet many of the companies that build these into their product either don't review the code or chose not to contribute back their fixes.
and do the work
Companies that build open source into their products rarely participate in their continued maintenance.
The ASF provides a neutral forum for collaborative maintenance and development that empowers the individuals doing the work (often supported by their employers), which has been shown to effectively sustain software projects for over two decades.
However, only a tiny percentage of downstream companies (reusing the same code within their own products) choose to participate.
- Security directives MUST avoid placing additional unfunded burdens on the few maintainers who are already doing the work.
Vulnerabilities are rarely
Vulnerabilities aren't alwaysisolated to a single component
.In the case of the The recent Apache Log4j vulnerability , was an unfortunate combination of independently designed features within the Java Naming and Directory Interface (JNDI) is a critical part of the exploit. JNDI is a part of the Java runtime, not part of Log4j itself. platform.
Disabling antiquated and unnecessary features, at least within a default configuration, would have prevented the vulnerability.
Improving platform security to prevent indirect activation of unsafe operations The industry tends to treat concepts of "JNDI injection" as if it were a known problem, but just like "SQL injection" and other injection problems, this is demonstrably not the case. If it were possible to improve those common components, that could be a very big win.
How the ASF addresses project security
- ASF projects are run by Each ASF project is governed by a Project Management Committees Committee (PMCs). PMC members nominate and vote on new PMC members and collectively manage community, security, trademarks, or other problems.PMC) consisting of individuals who have earned merit by working on the project.
- PMC members collectively manage their own community decisions regarding technical development and releases.
- Projects
- adhere to various foundation-wide policies, including for trademarks,
- making releases, and handling reported security vulnerabilities.
- ASF policies require PMC reviews with minimum levels of voting required for new releases.
- Changes to project source code are tracked and visible to all interested parties.
- The ASF has a security team and a VP of security who acts with board authority. The
- The ASF security team sets a common policy, maintains security contacts for PMCs, and provides support for projects responding to security issues.
- We publish metadata about all vulnerabilities across all our projects in a consistent and machine-readable way.
- When faced with a critical vulnerability, we aim to get it mitigated fast. mitigate the threat before disclosure.
- Initial reports are processed in private under rules for responsible disclosure.
- Once an issue
- becomes public, the focused attention often leads to additional issues being detected
- .
- We aim to be fast to release and fast to fix
- , even if that requires multiple releases.
Recommendations
Our experiences in dealing with Open Source Software and vulnerability handling over more than 25 years inform our positions on a number of items:
...