Implementing OSSF Scorecard

[UlisesGascon]

Some time ago, we implemented the monitoring and review of the OSSF scorecard in the Node.js org, and it significantly contributed to the improvement of many repositories. I believe adopting a similar approach for Express would be highly beneficial. We've developed tools, such as the OpenSSF Scorecard Monitor and OpenSSF Scorecard Visualizer, along with processes that make handling the evolution of scoring straightforward. Despite initial appearances, the process is quite simple.

Context

The goal of Scorecards is to auto-generate a “security score” for open source projects to help users as they decide the trust, risk, and security posture for their use case. This data can also be used to augment any decision making in an automated fashion when new open source dependencies are introduced inside projects or at organizations. For example, organizations may decide that any new dependency with low scores has to go through additional evaluation. These checks could help mitigate malicious dependencies from getting deployed to production systems like we’ve seen recently with malicious NPM packages.
source: openssf Blog

Resources

• OpenSSF Scorecard
• You should use the OpenSSF Scorecard
• OpenSSF Scorecard API
• Security Scorecards for Open Source Projects

Next Steps:

• Define when/how to review the scoring as a team. For example, in Node.js, we conduct this review in every Security WG Meeting. Watch example (minute 04:00 to 10:00) and the dashboard
• Add the Scorecard pipelines to the projects. View example
• Improve the scoring by patching the bugs. See example

I'm enthusiastic about leading these changes in the repos. While we may not be familiar with the OSSF Scorecard, we already have scores for most of our projects. Here is a simple dashboard that I auto-generated. The OSSF team is already tracking our projects using a CRON job, but we can easily enrich them and make some simple patches to increase the scoring.

Most of these changes won't require significant alterations and can be performed in isolated PRs, making them easy to review. If we're in agreement, I can start with the Express project to showcase the process. 👍

[dougwilson]

If we're in agreement, I can start with the Express project to showcase the process. 👍

Go for it. And if it makes it amy easier you are always welcome to start with any of the smaller, simplier middleware repos.

[inigomarquinez]

Good afternoon!

I've had a chat with @UlisesGascon to tell him that I am interested in contributing to this initiative, as the OpenSSF Scorecard is something that I like and that I have also helped to implement in the Open Source community of the company where I work.

[UlisesGascon]

Yeah! Welcome aboard @inigomarquinez 🎉

[carpasse]

Good Morning!

I've also had a chat with @UlisesGascon and I am interested in contributing to this initiative too.

[UlisesGascon]

As discussed with @inigomarquinez, he will champion this initiative 🎉

[inigomarquinez]

Thanks for the opportunity @UlisesGascon !

[carpasse]

@expressjs/express-tc As @jonkoops mentioned in this comment, we should decide on which tool to use—Dependabot or Renovate—so that we don’t have to perform these version updates manually.

[wesleytodd]

Ah, just seeing this after checking the previous notification for updating. Sorry if that comment is not necessary now. Anyway, if this is a way to unblock those from failing I am good merging them, but we should work on a non-distributed way to manage these. Maybe have a shared workflow we update in one place?

[sheplu]

Ah, just seeing this after checking the previous notification for updating. Sorry if that comment is not necessary now. Anyway, if this is a way to unblock those from failing I am good merging them, but we should work on a non-distributed way to manage these. Maybe have a shared workflow we update in one place?

one of the plan I have (and will be starting soon) is to centralize all workflows - allowing full reusability across all projects :D

[UlisesGascon]

Actually, I started to experiment running the analysis in a DIY mode with the official Docker Image in VisionBoard and seems like maybe it will replace some of this CI overhead ref. I am checking with the Scorecard maintainers if there is a way also to report this info back to the official API (that is the only piece missing with this new approach for now).