Don’t do this. Compromised packages because of burned-out maintainers aren’t a time to shill your scorecards that no one cares about.
A malicious or compromised maintainer is extremely difficult to guard against using automated tools or supply chain security technologies. Looking back at the last OpenSSF Scorecard report on the xz repository, we do see a number of best practices such as Code-Review, Token-Permissions, Branch-Protection, and Static-Analysis were not enabled, nor did xz have the OpenSSF Best Practices badge. It’s difficult to predict whether these settings on their own would have prevented this backdoor, however, security best practices were not followed.
OpenSSF’s Scorecard shows that the Django project is barely rated higher than xz. Django is a good test of the quality of rating systems and scorecards. When Django ranks poorly or average, you are measuring the wrong things.
This isn’t a mistake that only OpenSSF makes. I have seen a half dozen other services ding them for things like not having a Code of Conduct and then linking two or three examples that attribute Django’s Code of Conduct.
Pointing out that someone who is already burned out and never knew your best practices existed is a bad PR move.
Even worse, we are now paying attention to your best practices, which don’t hold water.
Even worse, if you aren’t proactively offering funding to these solo projects you knew were destined to fail, you are actively part of the problem and trying to profit from it. Please stop making it worse for the next burned-out maintainer.
Also, project maintainers hate being opted into things they have yet to ask or sign up for.
Do better OpenSSF.
