On Wed, Feb 16, 2022 at 9:00 PM Brian Russell <[email protected]> wrote: The Google Open Source Security Team (GOSST) has reviewed the Brainstorm Initiatives page and has several additions that we think may be helpful. To ensure context is retained (and make it easier for any future copy/pasting to the Brainstorm Initiatives page), each proposed addition has been placed within the respective WH theme and under any associated/existing points.
Hi Brian, thanks for reaching out and your content. Much of what you have written is really for this list and for any follow up we do when any projects start getting picked up and worked on - the idea of the brainstorm list is just a sentence per idea so we can get a really high level view of what things we want to prioritise and what things anyone wants to work on. Once we've a few projects that are plausible and being worked on, we can drill down into the detail. So I've updated the wiki to add some of your links and clarifications and a couple of new items in a shorter form. One thing that's coming up a lot are the Scorecards. - [existing ASF point] Consider if projects that are not releasing > regularly are really healthy > <https://lists.apache.org/thread/o3d4jflb39y1m49q8588z9bp8xlp06hc>. > Could they realistically respond to a security vulnerability in a > reasonable time frame? > > – [GOSST/OpenSSF addition] OpenSSF Scorecards > <https://github.com/ossf/scorecard> could be used to show when a project > meets this criteria. Scorecard looks for commit frequency and issue > activity by maintainers to identify whether a project is being actively > maintained. This can act as a reasonable approximation of number of eyes on > the project and whether maintainers can respond to a security > vulnerability. See the maintained check > <https://github.com/ossf/scorecard/blob/main/docs/checks.md#maintained> > for more details. > The difficulty, as mentioned elsewhere, are that OpenSSF Scorecards expect to find data for the scorecard in places that assume a certain way for OSS projects to work. In our case, at the ASF, we have long established, working, and sufficient, ways for projects to do and announce releases, to do signing of releases, and so on. So really, if we want a plausible solution in a short time frame, it's going to have to be to try to find a way to have the scorecards work with what our projects are currently providing than change what is working at the moment for 300+ projects. Maybe the tool has to scrape our download and archive site or release announcement mail archive (for example). For "are releases signed" the answer will always be "Yes" for example. Those two are probably the easiest to fix and automate though, some of the others look harder. But, again, this is the high level project "make openssf scorecards properly represent ASF projects" Cheers, Mark
