Page History

Possible security initiatives and things we've discussed doing as part of the work for this meeting.  In no particular orderbefore, 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.

Theme: Developer Education

• 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
• Is OpenSSF training something we should promote to committers
• Educate projects on the selection of dependencies, and their upkeep (see also "Help users pick secure projects") (This could possibly be OpenSSF Scorecards)
• Write up how the ASF acts as a Curator of OSS (in terms of the curation discussions happening) and what curation functions are performed

Theme: Improving our process and policy

• 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 requirementsMake sure our users know what they should be doing to find out about updates, EOL, CVEs
• 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
• Look at 2FA for Apache
• 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
• Should have more complete policy around production of "builds" https://www.apache.org/legal/release-policy.html#compiled-packages
• Look at OpenSSF AllStar
• Give more guidance on how to deal with 'low severity' issues to avoid them 'hanging around' and distracting from more urgent things

WH Theme: Preventing Defects

• 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)
  • Track the dependencies across our projects so we can see the combined-graph for the latest version of each ASF project. Work centrally to encourage that dependencies are not insecure, or excessively dated.
• Facilitate direct funding efforts such as TideLift which provide direct financial support for developers to focus on matters such as security
• How does OpenSSF Alpha and/or Omega fit with ASF
• Look at the sponsored SOS rewards program
• Think about which ASF projects would benefit from being covered by IBB (they reached out to us to expand our current set)
• Looks at OpenSSF OSS Fuzz (high false positive rate - would benefit from manual triage by OSS Fuzz team before notifications are sent to maintainers). See also mail from GOSST. 

WH Theme: Identify Critical projects / Help users pick secure projects

• How can we make the OpenSSF 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
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
• Make sure our users know what they should be doing to find out about updates, EOL, CVEs
• How can we make the OpenSSF 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).
• Consider ASF Blog Post: "How You Can Help" directed towards corporate users (evangelize a "give back" culture among consumers)

WH Theme: SBOMS /  Notifications

• See SBOM page
• Look at providing vulnerability data in a format that can be combined with SBOM such as VEX (CSAF) and/or OSV  https://osv.dev/
• Look at EOL notifications CSAF as an example https://access.redhat.com/security/data/csaf/beta/2019/rhsa-2019_1862.json
• 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?)

Completed

• Look again into SCR:CLR as a service to projects. Done. Rejected for various reasons.
• 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?
  • From September 2022 we have a dedicated person paid by ASF to perform vulnerability handling functions
• In July 2022 we implemented automated checks (INFRA-23459) to ensure packages contained the right signatures and met policyMinimize situations in which PMCs refuse contributions for anything other than strong technical reasons
• Forking increases the attack area and complexity of fixes
• Either stop accepting forks as a necessary and acceptable outcome of PMC control OR focus on enabling "constructive forking" in a controlled manner in which the forking community are welcomed and can continue to contribute to the core project
• ASF projects should consist of components for reuse and should accept contributions designed to enhance that reuse in broader contexts so as to allow the pool of contributors to grow
• ASF Projects should be encouraged to build modular solutions to enable more reuse of components in broader contexts while still enabling pluggable features for specific use cases
Re-Affirm that ASF Projects are successful when the community is optimized, not when the primary employer of PMC members is successful - this success leads to further success in the primary employer should one exist