Possible initiatives and things we've discussed doing as part of the work before, during, and after the January 13th 2022 meeting at the White House. 

Note this is a brainstorming document.  Items can be added by anyone without any expectation they are plausible or will become work we do or policy we produce.  They are in no particular order.

• Make sure our users know what they should be doing to find out about updates, EOL, CVEs
• Make sure our projects are keeping track of their dependencies, especially things that are EOL, especially things that are other Apache projects and EOL (example log4j v1)
• Consider if projects that are not releasing regularly are really healthy.  Could they realistically respond to a security vulnerability in a reasonable time frame?
• Have a better EOL policy with defined communication routes, policy for CVE in EOL releases.
• Look again into SCR:CLR as a service to projects
• More 2FA requirements
• Make sure we upgrade our CNA CVE process to JSON 5.0 to make use of the additional record data
• Get involved with various OpenSSF initiatives
  • Is the training something we should promote to committers
  • How can we make the scorecard better for ASF projects
    • for example https://metrics.openssf.org/grafana/d/default/metric-dashboard?orgId=1&var-PackageURL=pkg%3Agithub/apache/logging-log4j2 which is unable to figure out many things and is wrong on others (like 'signed releases' and so on).
  • How can we make the critical projects list better for ASF projects
  • How does Alpha and/or Omega fit with ASF
  • Would sigstore be a future replacement for current signing policies
  • Look at SLSA/SBOM work
• Minimize situations in which PMCs refuse contributions for anything other than strong technical reasons
  • Forking increases the attack area and complexity of fixes - projects should be governed such that the need to fork when using the code is minimized
  • Stop accepting forks as a necessary and acceptable outcome of PMC control of ASF projects - users cannot be expected to invest in a community if the gates to the PMC are closed
  • Focus on education such that PMCs can enable "constructive forking" in a controlled manner such that the forking community are supported in improving a projects architecture to minimize the need to fork
  • Educate ASF projects that the way to a healthy community is through the production of reusable components that enable contributions designed to enhance reuse in broader contexts so as to allow the pool of contributors to grow
  • Re-Affirm that ASF Projects are successful when the broadest possible community is engaged leading to more maintainers and more eyeballs on the shared code
• Consider annual re-affirmation by PMCs towards Apache Way, with reminders of What It Is.
• Consider ASF Blog Post: "How You Can Help" directed towards corporate users.
• Should have more complete policy around production of "builds" https://www.apache.org/legal/release-policy.html#compiled-packages
• Spend Foundation resources (money) on creating messaging for community members, e.g.
  • Popularizing, re-affirming The Apache Way
  • Messaging to evangelize a "give back" culture among consumers
  • Presentations for community members to share with Colleagues on how to give back, how to handle Open Source contributions
  • Language for corporate lawyers to facilitate contributions by developers in their organization, what it means when a developer signs an ICLA (or is hired already having one on file), etc. 
• Facilitate direct funding efforts such as TideLift which provide direct financial support for developers to focus on matters such as security
• Consider adopting https://osv.dev/ instead of CVE/CVSS.
• Require a minimum of 3 PPMC members to have attended a (yet to be written) training course on Vulnerability handling at the ASF before the podling is allowed to graduate
• Require projects to maintain a security team of at least 3 people all of whom have undertaken the training described in the previous point
• One of the big Elephants-In-The-Room in terms of security is that we have no idea who is using our products. Increasingly, finding good information on the Web requires some sort of log-in requiring an email address.  If we had a registry of everyone that downloaded our code by project, we would be able to notify them of updates and security fixes.  It would be best if this was implemented ASF-wide, at least as a policy, or as a shared registry.  I realize there are privacy issues here, but I believe these can be addressed.
• Sometimes communication with vulnerability reporters breaks down, is it time to have a more structured tool for handling reports which forces the process? or just have our CVE tool give reminders / require checkboxes?