amzn
Can/should we raise the Sonatype Safety Rating for ion-java?
When you look at ion-java in Maven Central you can see that the project is assigned a safety rating of 5/10.
Reading from the How is the Sonatype Safety Rating determined? link we learn that
Further details about OpenSSF’s Security Scorecard and the checks it runs can be found on its Github repository.
This issue should serve to track what (if any) actions we should take to raise our Sonatype Safety Rating, if that is a good investment of our time.
First question to address: can we get a more detailed breakdown for this project?
I tried listing our scorecard from the REST API and got no response, on further reading it looks like since we don't intentionally publish our scorecard it cannot be listed.
From ossf/scorecard's Using Scorecard README section we can see that incorporating the OSSF Scorecard action should surface these details for us privately, if used.
Out of the issues flagged by the OSSF Scorecard workflow we are now down to a single LOW priority issue with recommended remediation:
Sign up for the OpenSSF Best Practices program.
This seems like more work than it's worth, and I'll defer it. Our Sonatype Safety rating remains at 5 after this- which I have to assume is due to the other "variety of metrics" used by Sonatype:
This tool leverages a variety of metrics, including the project’s rate at which it updates vulnerable dependencies (also known as Mean Time to Update, or MTTU), as well as whether the project uses open source best practices, as measured by the OpenSSF’s Security Scorecard.
We can aim to improve MTTU, but other than that I don't know what else to do here. Unless this gives more weight to the OSSF Best Practices Badge? Hard to tell.
There's a much more detailed explanation of how the Sonatype Safety Rating is derived in the Sonatype article Project Quality Metrics- a key quote is:
In the previous section, we noted that various combinations of features could be used to obtain high accuracy, so we have flexibility in which features we choose to include in the training process. We thus choose to avoid features that are influenced by popularity. This means avoiding the OpenSSF Criticality metric (which includes a count of the number of projects using a component as a dependency), the Maven Central download count (a direct measure of popularity on Maven Central), and the SourceRank metric (which includes “stars” and “subscribers,” two measures of popularity). This leaves us with the individual Security Scorecard checks and MTTU, which we combine with the vulnerability data and provide as input to the learning process (our dataset for this experiment consists of 31,515 projects). For projects where MTTU does not apply (e.g., projects with no dependencies), we use a separate model trained with just Scorecard checks.
This leads me to believe that MTTU is the dominating factor here.