apache
Reintroduce the Scorecard workflow
We should reconsider enabling the Scorecard action, considering especially that:
- A Scorecard for Apache Log4j is computed anyway, since Scorecards are computed for 1 million critical projects. Running the action ourselves we have more control on what the public sees.
- We enabled mandatory PR reviews, so random pushes to our default branch will not decrease our score.
Blocked by ossf/scorecard-webapp#554
We had enabled Scorecards, and it helped with
- Creating a maintenance burden (Remember how many times we needed to fix its CI workflow?)
- Bringing literally no value by any means
A Scorecard for Apache Log4j is computed anyway, since Scorecards are computed for 1 million critical projects.
Right, and hence, I don't see the reason to duplicate that work. Users interested in Log4j's Scorecards, can find it anyway.
we have more control on what the public sees
Do you imply that OSSF is manipulating the scores? Or, we can manipulate the scores as we see fit?
we have more control on what the public sees
Do you imply that OSSF is manipulating the scores? Or, we can manipulate the scores as we see fit?
No, but the data is hard to find (it requires a Google Cloud account) and it is difficult to check what the score is. We don't need to announce the score via a badge, but we can still compute it.
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?
- 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.
- 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 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.
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, and unfortunately, the Log4j scorecard there 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.