Small nit - I'd argue that more attention is focused on any product after a vulnerability announcement, whether open source or not. Researchers often get inspired by the work of others, and find new issues in software recently found in the spotlight.
There might be benefit to provide a short discussion in the read-ahead around "black box" vs "white box" security testing. Anything *can* be tested - particularly if nation-state resources are available (Siemens ICS comes to mind). Through the transparency of open source, though, we allow a more diverse group to both test and improve our software, resulting in a better final product. (would be awesome if studies/stats can be quoted on this) On Fri, Dec 31, 2021 at 11:40 AM Mark Thomas <[email protected]> wrote: > A few minor typo corrections in-line and one potential additional topic. > > On 31/12/2021 19:06, Sam Ruby wrote: > > In addition to the in-person meeting next month, we are invited to send > > read-ahead material and there will be a brief phone call. Given that > > the call will only last 30 minutes, I presume that call will be consumed > > by introductions, logistics, and perhaps questions about the read-ahead > > material. That call will be on Wednesday, so I would like to send any > > read-ahead material that we might have late morning EST on Monday. > > > > My thoughts are to lead with a summary/bulletized version of what has > > been discussed recently on this list, followed by actual pointers to the > > original emails. Here's a first draft... additions/corrections welcome, > > both to the bullet points and new posts (preferably to this list) that > > should be added. > > > > Key bullet points > > > > * This will require collective action > > o There are things we can do, both individually and together, to > > reduce the number of vulnerabilities. > > o There are things, such as SBOMs, that can help identify what is > > affected once a vulnerability is found. > > o Much of this is moot if patches are never applied. > > * Volunteers/community/participation > > o Out contributors tend to be seasoned software professionals > > whose employers include ASF releases in their commercial > products. > > Out -> Our > > > o Our communities are healthy, open, and transparent. > > o Companies an government agencies that want to help don't need > > money or formal contracts to do so. Join our mailing lists, > > review our code, contribute fixes. > > an - > and > > > One side-effect of the original log4j issue is that a lot more eyes have > been focused on that code. As a result of this increased scrutiny, there > have been a handful of additional security issues identified. I think we > need to make clear that we view this as a good thing. > > This isn't unique to log4j. We have seen it in other projects as well. > Generally, the more severe the issue, the more security researchers are > attracted to look at the code more closely. > > This additional scrutiny on the original issue, the applied fix, the > surrounding code and any similar functionality is something that only > happens with open source. This is because security researchers have free > access to the source and the fix and are able to go and poke around and > see what else they can find. It is a lot harder (arguably impractical) > to do something similar with closed source. > > Mark > > > > > Background reading: > > > > * EO - Mark Cox - https://s.apache.org/3nctr > > * SBOM - David Nalley - https://s.apache.org/hccur > > * Applying updates - Mark Thomas - https://s.apache.org/5jqab > > * Collective action - Phil Steitz - https://s.apache.org/ljzn0 > > * Volunteers - Sam Ruby - https://s.apache.org/3vkpr > > * Contributors/maintenance - Dominik Psenner - > https://s.apache.org/3lrk1 > > * CISA - David Nalley - https://s.apache.org/1gr1c > > * Get Involved - https://www.apache.org/foundation/getinvolved.html > > > > - Sam Ruby > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: > [email protected] > >
