...
- EO - Mark Cox - https://s.apache.org/3nctr
- SBOM - David Nalley - https://s.apache.org/hccur
- Applying updates - Mark Thomas - https://s.apache.org/5jqab
- Collective action - Phil Steitz - https://s.apache.org/ljzn0
- Volunteers - Sam Ruby - https://s.apache.org/3vkpr
- Contributors/maintenance - Dominik Psenner - https://s.apache.org/3lrk1
- CISA - David Nalley - https://s.apache.org/1gr1c
- White box testing - John Kinsella - https://s.apache.org/hn2ba
- 2016 EU Audit - Dirk-Willem van Gulik - https://s.apache.org/fhoji
...
There are really three main supply-chain related ideas that people need to get:
...
The ASF is an operating US 501(c)3 organization that supports several hundred open source projects. The operating part of the ASF is managed
by the President, supported by the Treasurer, Vice Presidents, committees and third parties. The ASF board provides oversight for operating functions as well as ASF project communities. The Legal Affairs, Security, and Treasurer departments report directly to the board, which means, for example that the Security team acts with the authority of the board.
...
ASF projects are run by Project Management Committees (PMCs). PMC members review and cast binding votes on releases, nominate and vote on new PMC members and collectively manage community, security, trademarks or other problems. The PMCs act on behalf of the ASF when they cut releases. The PMC plays a key role in technical project oversight, but not the only role. The full project community contributes by working
creating and reviewing) patches and contributing to discussion.
All ASF community members, including PMC members, officers and the board, participate in our communities as individuals, not as
representatives of companies or other organizations. Some community members are paid by their employers to contribute to ASF projects but in their ASF work they are expected to act in the best interest of the community, exercising their own best judgement. Impact on project decisions is based on publicly earned merit which accrues to
individuals, based only on their contributions at the ASF.
...
ASF software is distributed and meant to be consumed in the form of versioned releases. ASF PMCs have various ways of packaging software for distribution, but the core asset being released is always source code. Releases must be voted on by PMCs, who are responsible for validating release candidates (RCs). Most PMCs also make RCs available
to the public prior to or during release votes. Library or infrastructure projects sometimes make backward-incompatible changes as they develop new versions of their software. Sometimes, a backward-compatible version of the software is added and maintained in parallel, but it often happens that the actively supported version is
not backward compatible with an older version. When library or infrastructure components make backward incompatible changes, downstream users may have to make code changes to upgrade their applications.
...
The ASF encourages responsible disclosure of security vulnerabilities discovered in software managed by ASF projects. The ASF security team sets a common policy, maintains security contacts for PMCs, and provides support for projects responding to security issues. Reporters are encouraged to use the designated security contacts to report vulnerabilities privately. PMCs are required to respond to security reports promptly, working with reporters to investigate and if necessary develop patches. The ASF Security team may assist the PMC in publishing a CVE once the vulnerability has been patched and a release containing the patch has been made available. The security team oversee all reported issues across all ASF projects.
- How end of support works
Like all software products, ASF code lines go through a lifecycle the that terminates in end of support. Typically, ASF PMCs communicate end of support dates for products or code lines with ample time (one year plus) for users to plan upgrades or find alternatives. Once communicated end of life dates arrive, the PMC is no longer expected or required to accept or apply patches to the end of life versions. This includes security patches against identified vulnerabilities. Therefore in some cases, when users who are depending on no longer supported versions of ASF software, a version upgrade will be required to obtain a fix of an identified vulnerability and that may require code changes to integrate.
...