OpenSSF Scorecard

In a talk at stackconf I learned about OpenSSF Scorecard and I found the idea interesting so I started to dig a bit deeper.

To explain what it is I just copied over their description:

We created Scorecard to help open source maintainers improve their security best practices and to help open source consumers judge whether their dependencies are safe.

Scorecard is an automated tool that assesses a number of important heuristics associated with software security and assigns each check a score of 0-10. You can use these scores to understand specific areas to improve in order to strengthen the security posture of your project. You can also assess the risks that dependencies introduce, and make informed decisions about accepting these risks, evaluating alternative solutions, or working with the maintainers to make improvements.

I found that theforeman/foreman is already in the list of automatically scanned repositories, so we have a preview without any work at OpenSSF scorecard report

Some scores are a bit wired for me like getting ten points for packaging based on the container workflow, others are interesting findings like the binaries for jumpstart which are 13 years old and so very likely something to think about!

There are also other parts of the project already scanned like

Looking at this I am not sure if I should suggest adding it, but having a look at some of the checks and suggestions could really help to improve. For example having a SECURITY.md copying the explanation from the website and linking to it, could make finding this information more easy.

What do you think about this topic in general? Should we collect action items from this and try to fix them? If yes, which ones do you identify and how should we fix it?

I’ll be honest and say that I never knew we shipped binaries for jumpstart. AFAIK those don’t end up in our packages and I wonder who even does Solaris unattended installations with them now.

You can store SECURITY.md in GitHub - theforeman/.github: github action templates to set it organization wide. At least GitHub recognizes that and avoids the need to sync it everywhere.

Yes, because of this I think some are really easily fixed, if we want to. Should I understand this already as request to add it?

Given we already have a security.html, adding a security.md makes a lot of sense to me. It’d be a good chance to also review our security procedure.

1 Like

Just pushed Add SECURITY.md by dgoetz · Pull Request #5 · theforeman/.github · GitHub before going to lunch. Just by copying the text over I had the first question. So reviewing seems like a good idea!