.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
Introducing the OpenSSF Scorecard API
The Scorecard API makes it easier to automate and enforce your dependency policies. Naveen is one of the key contributors to the Scorecard projects, in this article, he walks through how it works!
The Scorecard API makes it easier to automate and enforce your dependency policies. Naveen is one of the key contributors to the Scorecard projects, in this article, he walks through how it works!
The Scorecard API makes it easier to automate and enforce your dependency policies. Naveen is one of the key contributors to the Scorecard projects, in this article, he walks through how it works!
The Scorecard API makes it easier to automate and enforce your dependency policies. Naveen is one of the key contributors to the Scorecard projects, in this article, he walks through how it works!
The Scorecard API makes it easier to automate and enforce your dependency policies. Naveen is one of the key contributors to the Scorecard projects, in this article, he walks through how it works!
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!
Projects like enoyproxy,tensorflow, and flutter use Scorecard - showing they have security awareness (and good taste).
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.