Hi folks, What follows are my notes from the pre-brief meeting that occurred on 1/5/2022 at 11:00 AM Eastern. I am sure I missed bits, so please feel free to correct my errors and omissions.
ASF Attendees: Mark Cox, Mark Thomas, Roy Fielding, Sam Ruby, David Nalley WH Attendees: Anne Neuberger, Amit Mital, Mary Gingrich, Sezaneh Seymour We started the call with a summary of the purpose of the upcoming in-person meeting: Gathering together key software companies and foundations to define a set of initiatives with the goal of improving gaps in open source supply security. Anne voiced a perception that in-person was core to having a good discussion, but did say that they would add virtual options for attendees. She asked for suggestions to go out to all attendees. Anne indicated that she hadn't seen the pre-brief document that we sent along. Anne asked that we start thinking about potential initiatives that could be used to improve the situation. Anne identified three potential initiatives that her side was thinking about: 1. Identifying the most critical open source artifacts 2. Building more accountable open source management. This item particularly seemed to harp on the volunteer nature of our communities, and emphasized the belief that they needed help. 3. Working on Software Bill of Materials (SBoM) MarkC responded and called the volunteer problem a red herring and cited our existing processes, and gates for ingesting, modifying, and releasing code, as well our security processes. He noted the really fast turnaround on the log4j vulnerability as an example of that. MarkC also called out the fact that things are often fixed quickly by the open source project, but slowly consumed by downstream users. He cited example of Struts and Log4j, and particularly that many people were asking for support for Log4j 1.x which had been deprecated 7 years ago. David called out the fact that identifying the most critical open source artifacts requires that you know what's being consumed, and that short of people telling us (or someone) what they are consuming - you have a chicken and egg situation where you want to identify the most important pieces, but can't do that effectively without knowing how broadly something is consumed. Anne asked about the best way to solve that problem. She asked if SBOM would help solve that problem. MarkC said that SBOM may help us in the future, but won't help in the short or medium term because of the very long tail of software that exists. Anne asked again how we would solve identifying critical pieces of software infrastructure. MarkC, tried to turn the conversation away from solving that problem and pointed out that someone saying that something is critical doesn't change the process. Amit - asked if identifying isn't a case of the perfect being the enemy of the good and we should just identify 100 or so packages and improve their security. (SBOM, processes, etc) MarkC responded that critical designation wouldn't change speed or response or quality for our projects at the ASF. David called out that the ecosystem and various groups had done these exercises before where we go fix the "top 50" and where that materially improves the ecosystem, but with few exceptions it hasn't helped on a broad scale. MarkC cited his experience with OpenSSL and Heartbleed. He said that even following all of that clamor, no one was paying attention to log4j, and that it was on no one's list. Roy said that we manage 350 products and that in consideration of the ecosystem, that our impact is so large that we might have 200 of those be considered critical. He said that because we didn't have any idea of what was being consumed or how, and that some central registration of use (SBOM registry?) to better understand that impact. Anne seemed to latch on to Roy's idea. David noted that as a vendor of software, we see folks who are not keeping current with their dependencies. Doing all of the security work fast and well doesn't matter if the industry doesn't have mechanisms to ensure currency. Anne asked us to bring ideas like these to the table. We discussed the prebrief doc that's going out over the weekend. Our submission (if any) is due by EoD Friday, EST. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
