Page History

...

• Have a better EOL policy with defined communication routes, policy for CVE in EOL releases.  See also this thread about Attic 
• Have a policy around projects that depend on other EOL projects (ASF and non-ASF)
• More 2FA requirements
• Consider if projects that are not releasing regularly are really healthy.  Could they realistically respond to a security vulnerability in a reasonable time frame?
• Make sure we upgrade our CNA CVE process to JSON 5.0 to make use of the additional record data
  • We probably ought to fix every CVE entry so the version_data works well for 5.0, see for example https://vulnogram.github.io/seaview/?CVE-2021-44549 
• Would OpenSSF sigstore be a future replacement for current signing policies.  See also mail from GOSST
  • In July 2022 we implemented automated checks (INFRA-23459) to ensure packages contained the right signatures and met policy
• Should have more complete policy around production of "builds" https://www.apache.org/legal/release-policy.html#compiled-packages
• Look at OpenSSF AllStar
• Sometimes communication with vulnerability reporters breaks down, is it time to have a more structured tool for handling reports which forces the process? or is it more people engagement? or can we just require checkboxes before allocating CVE names in our existing tool?
  • In July 2022 we started hiring for a dedicated person to perform vulnerability handling who can add structure and consistency

WH Theme: Preventing Defects

...

WH Theme: SBOMS /  Notifications

• See SBOM page
• Consider adopting https://osv.dev/ (instead of CVE/CVSS). (These are not mutually exclusive)
• We have no way to know who is using our projects, nor do we want to capture that data (so is the current vulnerability notification system sufficient?)

Unsorted / Not Security

• 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 (covered in a different bullet)
  • 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.
• Creating messaging for community members, e.g.
  
  • Popularizing, re-affirming The Apache Way
  • Presentations for community members to share with Colleagues on how to give back, how to handle Open Source contributions  (covered in a different bullet)
  • 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. 
• 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.  (summarised under notiifcations)