Deeper dive into project ideas taken from Brainstorm Initiatives which could fit into ASF Infrastructure projects.
Release Publication Policy enforcement
We already have policies around releases including creation of hashes and signing, https://www.apache.org/legal/release-policy.html#release-signing. Recently Infra wrote a tool (download-integrity-checker) to validate that all our hosted download artifacts meet that policy. However this need further development; see INFRA-23469 - Getting issue details... STATUS . Future tooling changes are proposed that will specifically require and check things are to policy prior to them being made available for download.
Measuring Health
We occasionally have to retire projects that have lost their community and are unable to produce releases and therefore are unable to fix security issues. This project would create a type of health scorecard that would give us more advance warning of problems, but it could also be useful to trigger actions to help communities recover before they get to this state. This could be an ASF dashboard (that is visible), or it could be something that can be incorporated into external scorecards, such as those by OpenSSF. (The OpenSSF scorecards do already score Apache projects, but mostly incorrectly due to them being unable to access the right metadata, making github assumptions, and so on).
We can also include here some way of indicating project EOL status to our users. We have some process, but our web pages are not always consistent, we need a standard format for announcement emails when projects reach EOL, have a future planned EOL, etc
Simplify Signing
We already have policies and enforcements around signing of artifacts, however there's been a lot of work on things like Sigstore which could remove a lot of the issues and complexities faced with the current GPG and KEY file system. A project to look into Sigstore, perhaps with a pilot, to see if it makes sense to switch to it.
Builds, Dependencies
ASF produces releases in the form of source materials. However "convenience" compiled versions may also be distributed https://www.apache.org/legal/release-policy.html#compiled-packages but as this becomes more common, along with container and other distributions, we need a better policy around builds, more infra to allow projects to do builds on ASF controlled infrastructure, etc. See for example ASFP-23 - Getting issue details... STATUS
Related to this are dependencies. We do sometimes include these in source distributions but it becomes more of an issue when they're in builds, containers etc too. Figure out some dependency tracking stuff, such as SLSA (then we'd end up with formulas for builds as well as dependency tracking) https://slsa.dev/provenance/v0.2
Fuzzing and Security Tool Services
What services are useful that we can provide as a service to all our projects. We did a pilot and rejected SRC:CLR, but there are others worth looking at (for example OSS-Fuzz). This would be a selection of pilots of tools.
SBOM
See SBOM
Some projects are starting to get requests to provide SBOM. But there are different formats and different advice. This project would look at the existing SBOM advice for open source, work on pilots with some projects, leading to recommendations for the final ASF advice to our projects, possible tooling, etc.
CVE and OSV improvements
Having SBOMs requires also being able to test for vulnerabilities against our projects, and the CVE JSONv4 metadata around affected versions is not consistent or sufficient to allow machine parsable affected version calculations. OSV files are going to be used with SBOM for this, and at the same time CVE JSONv5 allows better automated machine comparison of affected versions. Look at updating our CVE portal to generate machine parsable affected versions such that we could generate and publish OSV files as well, across all our projects. We could also produce EOL statements using OSV.