Modern software is built on hundreds if not thousands of third-party open-source components, typically known as dependencies. These dependencies help development teams move fast and stay productive.
Because of the productivity boost, most organizations are adopting OSS quickly, leading to mission-critical applications that rely on thousands of direct and transitive dependencies. As open source packages become a bigger target for malicious users, the health of these dependencies becomes a crucial part of overall supply chain security.
A dependency’s health can have a number of factors: Is it well maintained? Is it updated often? Are there multiple maintainers, or will the whole thing come crashing down if a single maintainer leaves? Are there any critical vulnerabilities in the code?
Whenever you consider bringing in a new dependency, wouldn't it be nice to get a score on its health and security? Enter OSSF Scorecard.
The OpenSSF Scorecard is an automated tool that assesses several important heuristics ("checks") associated with software security and assigns each check a score of 0-10. These scores help understand specific areas to improve to strengthen the security posture of a dependency.
Some of these checks include:
- Determining whether the project requires code review before pull requests are merged
- Checking if a project’s default and release branches are protected with GitHub’s branch protection
- Check if the project generates executable (binary) artifacts in the source repo.
- A bunch more!
The scorecard project scans more than 1 million repositories every week. The scan results are stored in BigQuery.
The Scorecard API
Today we’re excited to announce that Scorecard is now even better - with the release of Scorecard API. With this latest release of scorecard API https://api.securityscorecards.dev can be used to access the dataset available.
An example of using this API is as simple as https://api.securityscorecards.dev/projects/github.com/sirupsen/logrus
Why the Scorecard API is a big deal
Given the criticality of the supply chain in a project's overall security posture, it's desirable to have an explicit policy. Ideally, machine-checkable/enforced to ensure a high-quality bar for new dependencies, slow unnecessary growth, and address structural concerns (duplicated dependencies, known problematic dependencies).
Our policy should address:
- How have they changed over time?
- What do they do?
- How do they affect security posture?
- How are they updated?
- How can you limit your exposure?
Rapid growth of dependencies is problematic since it becomes challenging to keep track of:
- How stale a dependency is relative to its upstream.
- Are there any known Common Vulnerabilities and Exposures (CVE) that apply to the project's dependencies?
- How closely the external dependencies follow best practices, e.g., code reviews, updating dependencies, two-factor authentication (2FA), vulnerability disclosure process, regular release practices, etc.
Here is an example of how Envoy uses an explicit external dependency policy: https://github.com/envoyproxy/envoy/blob/main/DEPENDENCY_POLICY.md
Up until now, it was hard to answer these questions and have an automated check to enforce these policies. Enter the Scorecard API!
Using the API to identify the dependencies health
A chain is strong as the weakest link. Identifying the weakest link on an ongoing timeframe is both difficult and daunting. Below, we will demonstrate how we can use the Scorecard API to evaluate whether a set of dependencies in a Golang project are using fuzzing internally in their projects. Fuzzing is one of the critical ways to identify zero days.
Steps involved in solving this problem:
- Get the list of dependencies and transitive dependencies for a given project, find the code here.
The above code is not production-ready code :). This is only for demonstration. The above code returns all the transitive dependencies for the project.
- Here is the func that fetches the Scorecard result from the API and checks if a given project is being fuzzed.
- The final step is to combine these two to get the results.
The full working example is available at https://github.com/naveensrinivasan/scorecard-api-demo.
The Scorecard project makes it easier for you to measure and create policy around the health of the dependencies you use. The Scorecard API makes it easier to automate and enforce those policies. If you have any questions, feel free to reach out to the Scorecard Community.
SBOMs are just a means to an end
Software has eaten the world. Modern society is dependent on software for everything from communicating with family to the medical devices keeping our loved ones alive. But do you know what goes into that software? If your answer was sticky tape and glue you clearly work in technology. Congratulations, this article is for you.