Open-source software (OSS, for short) has become quite dominant in the industry. According to the estimates of The Linux Foundation, 75% to 90% of any modern software product contains at least one OSS component. These components are typically known as dependencies, and they help development teams move quickly and stay productive. Most organizations are adopting OSS quickly, resulting in thousands of direct and transitive dependencies. The health of these dependencies becomes crucial as the chain is as weak as its weakest link. That’s where OpenSSF Scorecards come in.
OpenSSF
Before I start talking about Scorecards and how you can leverage them to examine the health of open-source projects, I would like to introduce you to OpenSSF. OpenSSF, which stands for Open Source Security Foundation, is a cross-industry organization that brings together the industry’s most important OSS security initiatives and the individuals and companies that support them. They are committed to advancing open-source security for all.
Learn more about OpenSSF at: https://openssf.org/about/
Why should we care about open-source security?
As I stated in this article’s lead, open-source has become quite dominant in the industry, and most organizations make their products and services dependent on OSS components. In the past years, open-source packages have become a target of malicious users. Compromising one of them could trigger an avalanche effect, rendering every company that has been using it vulnerable. Making sure that the components you are using are “healthy” plays a crucial part in the overall security of your supply chain.
What does “healthy” mean?
You might wonder what it means to have a healthy open-source component. Whenever you are thinking about bringing in a new dependency, you should ask yourself these questions.
- Is the component well maintained?
- How often has it been updated?
- Are there multiple maintainers or does it rely on a work of an invidividual? (In case that individual leaves, it might crash the whole project down)
- Are there any critical vulnerabilities? (Additionally, you should also check whether a project is using any SAST tool)
- Does the project have any security policies set up in place?
- Does the project also use any dependency update tool?
Imagine you are tasked with evaluating a bunch of the packages your company is using for their security posture (you don’t have to be an AppSec person to receive this kind of task). In the worst (and usual) scenario, you would have to go by the dependencies one by one, trying to get the answers for each and every question above. The process would be tedious and prone to human mistakes. Wouldn’t it be nice to have a tool that would do all the hard work for you? Enter OpenSSF Scorecards.
What are OpenSSF Scorecards?
Scorecards allows you to assess open source projects for security risks through a series of automated checks.
The Scorecard project has been announced for late 2020, and it aims to automatically generate a security score for OSS projects to help consumers and organizations make better, risk-informed decisions. You can use the tool to assess risks within your codebase as well as evaluate other projects and dependencies. Scorecards can help you enforce best practices and protect yourself and your organization against:
- Malicious maintainers
- Build system compromises
- Source code compromises
- Malicious packages
It does so by checking for vulnerabilities that would affect the software supply chain (source code, build, dependencies, testing, and most importantly, maintenance). The checks are automated, and every check returns a score on the scale from 0 to 10 and a risk level (low, medium, high, and critical). The risk level affects the returned score by adding weight and helps to produce the final score.
The checks and holistic security practises
Scorecards revolve around three themes: holistic security practices, source code risk assessment, and build process risk assessment. The holistic security practices can then be divided into five more subsections. Each section can be described using these questions.
- Code Vulnerabilities: Does the project have unfixed vulnerabilities?
- Maintenance: Does it use any tools to help update it’s dependencies? Is it even maintained? Does it have a security policy? Does it adhere to some kinda of a licence?
- Continuous Testing: Does the project run tests in CI? Does it use any fuzzing tools? Is there a static code analysis tool set up?
- Source Risk Assessment: Are there any binary artifacts present? Are there any dangerous coding patterns in their GitHub Actions? Are its branches protected? Does the project require a code review before the code gets merged to main branch? Are the contributors from at least two different organizations?
- Build Risk Assessment: Does the project declare its dependencies? Are the workflow tokens read only? Does the project build and publish official packages from CI/CD? Are the releases cryptographically signed?
If you want to learn more about the scoring criteria for each and every check, I would much suggest you to visit the detailed documentation.
Note: One of the criteria the Scorecards are checking is the presence of SAST tool. I personally like Snyk’s SAST tool. You can check it out as it’s free to set up a repository scan. Visit snyk.io for more info.
Running a Scorecard scan
Okay, so now we know everything we need to know about the Scorecards. The next step would be to run the scan ourselves. Luckily for me, running a scan is pretty easy, as there are multiple ways you can run scorecards. I have opted for using Docker. For Windows users, there is a Docker Desktop that you can download and run.
Do you have your Docker set up? Great! Let’s start by pulling the Docker container.
docker pull gcr.io/openssf/scorecard:stableAfter that, create your GitHub personal access token with ‘public_repo’ scope and store the token somewhere safe, as you will need it later.
To run the scan, use the following command and change the access token and URL as needed.
docker run -e GITHUB_AUTH_TOKEN=<your_token> gcr.io/openssf/scorecard:stable --show details --repo=<repo_you_want_toscan>I have used the Scorecard to evaluate one of the projects I was working on previously.
Under the aggregated score, there is always a detailed report with the check scores. Not only is there a detailed explanation, but the Scorecard also provides a link to documentation and remediation of the respective problem.
Setting up Scorecards took me less than 15 minutes (provided that I was catching up on the episode of “Silicon Valley” at the same time), which makes it quite an intuitive tool to use. Anyone can do that. The next goal for me is to automate the process of scanning (using a simple bash script, probably) as well as create some kind of more visually appealing report.
If you have read so far, you might want to follow me here on Hashnode. Feel free to connect with me over at LinkedIn or Mastodon.
