ppkarwasz commented on issue #3604: URL: https://github.com/apache/logging-log4j2/issues/3604#issuecomment-3044011687
Hi @vy, A few months have passed since my original proposal, and in the meantime, several things have changed. Would now be a good time to revisit this discussion? > 1. Creating a maintenance burden (Remember how many times we needed to fix its CI workflow?) From what I recall, the main issue with the Scorecards workflow was caused by a mismatch between the default branch name in `logging-parent` and this repository. Fortunately, that specific problem has since been resolved in ossf/scorecard-webapp#778. > 2. Bringing literally no value by any means To better understand the value of Scorecards, I reached out to a one OSPO who manage hundreds of thousands of open source packages. Here’s a summary of why they consider Scorecards valuable: * They serve as a self-documenting benchmark for good security practices. * At scale, they help identify where gaps exist, what’s healthy, and what might need attention. * They act as a "mirror" for maintainers to understand what OSPOs and security teams prioritize. * The project evolves over time to reflect the changing needs of the open source ecosystem. * When skeptics question their utility, the typical response is: *“How else do you review 100k+ dependencies or move the security needle at scale?”* In this context, I believe reintroducing the Scorecards GitHub Action sends a strong and positive signal — that Log4j is actively maintained and aligns with recognized security best practices. With our robust review policies (e.g., a [Pony Factor](https://bitergia.com/the-pony-factor-metric-of-the-month-november-2022/) of at least two and multiple ponies in reserve), we already operate at a high standard — publishing those signals could be beneficial for security-conscious consumers. > > A Scorecard for Apache Log4j is computed anyway, since [Scorecards are computed for 1 million critical projects](https://github.com/ossf/scorecard?tab=readme-ov-file#public-data). > > Right, and hence, I don't see the reason to duplicate that work. Users interested in Log4j's Scorecards can find it anyway. I’ve come to realize that OpenSSF’s computed Scorecards are published via Google BigQuery, which requires a paid account and can be a barrier to access for smaller organizations and individuals. In contrast, many rely on what's available at [scorecard.dev](https://scorecard.dev/), and unfortunately, the [Log4j scorecard there](https://scorecard.dev/viewer/?uri=github.com%2Fapache%2Flogging-log4j2) is the one we published more than a year ago. Running the Scorecards GitHub Action ourselves ensures that public data remains current and accessible — a small step that could make a meaningful difference for those evaluating our project. **NB**: Maven is also introducing Scorecards in support-and-care/maven-support-and-care#99. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
