Security Health Metrics For Open Source
A short motivational video clip to inspire us: https://youtu.be/rDMMYT3vkTk "You passed! All D's ... and an A!"
Automate analysis and trust decisions on the security posture of open source projects.
Use this data to proactively improve the security posture of the critical projects the world depends on.
The following checks are all run against the target project by default:
|Active||Did the project get any commits in the last 90 days?|
|Automatic-Dependency-Update||Does the project use tools to automatically update its dependencies?|
|Binary-Artifacts||Is the project free of checked-in binaries?|
|Branch-Protection||Does the project use Branch Protection ?|
|CI-Tests||Does the project run tests in CI, e.g. GitHub Actions, Prow?|
|CII-Best-Practices||Does the project have a CII Best Practices Badge?|
|Code-Review||Does the project require code review before code is merged?|
|Contributors||Does the project have contributors from at least two different organizations?|
|Fuzzing||Does the project use fuzzing tools, e.g. OSS-Fuzz?|
|Frozen-Deps||Does the project declare and freeze dependencies?|
|Packaging||Does the project build and publish official packages from CI/CD, e.g. GitHub Publishing ?|
|Pull-Requests||Does the project use Pull Requests for all code changes?|
|SAST||Does the project use static code analysis tools, e.g. CodeQL, SonarCloud?|
|Security-Policy||Does the project contain a security policy?|
|Signed-Releases||Does the project cryptographically sign releases?|
|Signed-Tags||Does the project cryptographically sign release tags?|
|Token-Permissions||Does the project declare GitHub workflow tokens as read only?|
|Vulnerabilities||Does the project have unfixed vulnerabilities? Uses the OSV service.|
To see detailed information about each check and remediation steps, check out the checks documentation page.
Using repository URL
The program can run using just one argument, the URL of the repo:
$ go build$ ./scorecard --repo=github.com/kubernetes/kubernetesStarting [Signed-Tags]Starting [Automatic-Dependency-Update]Starting [Frozen-Deps]Starting [Fuzzing]Starting [Pull-Requests]Starting [Branch-Protection]Starting [Code-Review]Starting [SAST]Starting [Contributors]Starting [Signed-Releases]Starting [Packaging]Starting [Token-Permissions]Starting [Security-Policy]Starting [Active]Starting [Binary-Artifacts]Starting [CI-Tests]Starting [CII-Best-Practices]Finished [Contributors]Finished [Signed-Releases]Finished [Active]Finished [Binary-Artifacts]Finished [CI-Tests]Finished [CII-Best-Practices]Finished [Packaging]Finished [Token-Permissions]Finished [Security-Policy]Finished [Automatic-Dependency-Update]Finished [Frozen-Deps]Finished [Fuzzing]Finished [Pull-Requests]Finished [Signed-Tags]Finished [Branch-Protection]Finished [Code-Review]Finished [SAST]RESULTS-------Repo: github.com/kubernetes/kubernetesActive: Pass 10Automatic-Dependency-Update: Fail 3Binary-Artifacts: Pass 10Branch-Protection: Fail 0CI-Tests: Pass 10CII-Best-Practices: Pass 10Code-Review: Pass 10Contributors: Pass 10Frozen-Deps: Fail 10Fuzzing: Pass 10Packaging: Fail 0Pull-Requests: Pass 10SAST: Fail 10Security-Policy: Fail 5Signed-Releases: Fail 10Signed-Tags: Fail 10Token-Permissions: Pass 10
For more details why a check fails, use the
./scorecard --repo=github.com/kubernetes/kubernetes --checks Frozen-Deps --show-detailsStarting [Frozen-Deps]Finished [Frozen-Deps]RESULTS-------Repo: github.com/kubernetes/kubernetesFrozen-Deps: Fail 10...!! frozen-deps/docker - cluster/addons/fluentd-elasticsearch/es-image/Dockerfile has non-pinned dependency 'golang:1.16.5'...!! frozen-deps/fetch-execute - cluster/gce/util.sh is fetching and executing non-pinned program 'curl https://sdk.cloud.google.com | bash'...!! frozen-deps/fetch-execute - hack/jenkins/benchmark-dockerized.sh is fetching an non-pinned dependency 'GO111MODULE=on go install github.com/cespare/prettybench'...
Using a Package manager
scorecard has an option to provide either
--rubygems package name and it would run the checks on the corresponding GitHub source code.
./scorecard --npm=angularStarting [Active]Starting [Branch-Protection]Starting [CI-Tests]Starting [CII-Best-Practices]Starting [Code-Review]Starting [Contributors]Starting [Frozen-Deps]Starting [Fuzzing]Starting [Packaging]Starting [Pull-Requests]Starting [SAST]Starting [Security-Policy]Starting [Signed-Releases]Starting [Signed-Tags]Finished [Signed-Releases]Finished [Fuzzing]Finished [CII-Best-Practices]Finished [Security-Policy]Finished [CI-Tests]Finished [Packaging]Finished [SAST]Finished [Code-Review]Finished [Branch-Protection]Finished [Frozen-Deps]Finished [Signed-Tags]Finished [Active]Finished [Pull-Requests]Finished [Contributors]RESULTS-------Active: Fail 10Branch-Protection: Fail 0CI-Tests: Pass 10CII-Best-Practices: Fail 10Code-Review: Pass 10Contributors: Pass 10Frozen-De ps: Fail 0Fuzzing: Fail 10Packaging: Fail 0Pull-Requests: Fail 9SAST: Fail 10Security-Policy: Pass 10Signed-Releases: Fail 0Signed-Tags: Fail 10
Running specific checks
To use a particular check(s), add the
--checks argument with a list of check names.
Before running Scorecard, you need to, either:
- create a GitHub access token and set it in environment variable
GITHUB_AUTH_TOKEN. This helps to avoid the GitHub's api rate limits with unauthenticated requests.
# For posix platforms, e.g. linux, mac:export GITHUB_AUTH_TOKEN=<your access token># For windows:set GITHUB_AUTH_TOKEN=<your access token>
GITHUB_AUTH_TOKEN can be provided separated by comma to be utilized in a round robin fashion.
- create a GitHub App Installations for higher rate-limit quotas. If you have an installed GitHub App and key file, you can use these three environment variables, following the commands shown above for your platform.
GITHUB_APP_KEY_PATH=<path to the key file on disk>GITHUB_APP_INSTALLATION_ID=<installation id>GITHUB_APP_ID=<app id>
These can be obtained from the GitHub developer settings page.
Understanding Scorecard results
Each check returns a Pass / Fail decision, as well as a confidence score between 0 and 10. A confidence of 0 should indicate the check was unable to achieve any real signal, and the result should be ignored. A confidence of 10 indicates the check is completely sure of the result.
There are three formats currently:
csv. Others may be added in the future.
These may be specified with the
If you're only interested in seeing a list of projects with their Scorecard check results, we publish these results in a BigQuery public dataset.
This data is available in the public BigQuery dataset
openssf:scorecardcron.scorecard. The latest results are available in the BigQuery view
You can extract the latest results to Google Cloud storage in JSON format using the
# Get the latest PARTITION_IDbq query --nouse_legacy_sql 'SELECT partition_id FROMopenssf.scorecardcron.INFORMATION_SCHEMA.PARTITIONS ORDER BY partition_id DESCLIMIT 1'# Extract to GCSbq extract --destination_format=NEWLINE_DELIMITED_JSON'openssf:scorecardcron.scorecard$<partition_id>' gs://bucket-name/filename.json
The list of projects that are checked is available in the
cron/data/projects.csv file in this repository. If you would like us to track more, please feel free to send a Pull Request with others.
NOTE: Currently, these lists are derived from projects hosted on GitHub ONLY. We do plan to expand them in near future to account for projects hosted on other source control systems.
Adding a Scorecard Check
If you'd like to add a check, make sure it is something that meets the following criteria and then create a new GitHub Issue:
- The scorecard must only be composed of automate-able, objective data. For example, a project having 10 contributors doesn’t necessarily mean it’s more secure than a project with say 50 contributors. But, having two maintainers might be preferable to only having one - the larger bus factor and ability to provide code reviews is objectively better.
- The scorecard criteria can be as specific as possible and not limited general recommendations. For example, for Go, we can recommend/require specific linters and analyzers to be run on the codebase.
- The scorecard can be populated for any open source project without any work or interaction from maintainers.
- Maintainers must be provided with a mechanism to correct any automated scorecard findings they feel were made in error, provide "hints" for anything we can't detect automatically, and even dispute the applicability of a given scorecard finding for that repository.
- Any criteria in the scorecard must be actionable. It should be possible, with help, for any project to "check all the boxes".
- Any solution to compile a scorecard should be usable by the greater open source community to monitor upstream security.
Bugs and Feature Requests:
If you have what looks like a bug, or you would like to make a feature request, please use the Github issue tracking system. Before you file an issue, please search existing issues to see if your issue is already covered.
For realtime discussion, you can join the #security_scorecards slack channel. Slack requires registration, but the openssf team is open invitation to anyone to register here. Feel free to come and ask any questions.
Currently, scorecard officially supports OSX and Linux platforms. So, if you are using a Windows OS you may find issues. Contributions towards supporting Windows are welcome.
If you want to get involved or have ideas you'd like to chat about, we discuss this project in the OSSF Best Practices Working Group meetings.
See the Community Calendar for the schedule and meeting invitations. The meetings happen biweekly https://calendar.google.com/calendar/embed?src=s63voefhp5i9pfltb5q67ngpes%40group.calendar.google.com&ctz=America%2FLos_Angeles
See the Contributing documentation for guidance on how to contribute.