Page History

...

ASF projects are run by Project Management Committees (PMCs).   PMC members review and cast binding votes on releases, nominate and vote on  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  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.

...

The ASF doesn't pick technologies or set technical direction for our projects.  Projects to have to adhere to various foundation-wide policies including trademarks, release policy, security vulnerability handling policy. There are very few required policies (and However the number of mandated policies is kept to a minimum to allow projects to manage their own processes (for example there is no SDLC policy). 

...

How releases are versioned, validated and distributed (https://www.apache.org/dev/#releases)

PMCs follow ASF policies which require PMC reviews with minimum levels of voting required for new releases.

ASF software is 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.  Most projects release only source code and are not producing builds of their releases.  Releases must be voted on by PMCs, who are responsible for validating release candidates (RCs).  Most PMCs also make RCs release candidates 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 Security team are a CVE Project Candidate Naming Authority (CNA). CVE names are issued to vulnerabilities regardless if they are found by the project committers, members, PMCs, other ASF members, or third-parties.  The ASF Security team and PMCs work from time to time with third parties who wish to perform security functions such as code audits, bug bounties.  

The ASF Security team assist the PMC in publishing a CVE once the vulnerability has been patched and a release containing the patch has been made available.  Vulnerability reports are sent to common and consistent locations including security lists, project development lists, and announce@apache.org. The security team oversee all reported issues across all ASF projects.  The security team report monthly to the board and produce other public reports:

...