✨ Treat GitHub Actions pinned to immutable releases as pinned dependencies (#5248)
- Treat GitHub Actions pinned to immutable releases as pinned dependencies
Adds clients.RepoClient.IsReleaseImmutable(owner, repo, tag), implemented via GitHub’s GraphQL API (query { repository { release(tagName:) { immutable } } }).
The Pinned-Dependencies raw check now treats a workflow ‘uses: owner/repo@tag’ reference as pinned when that tag corresponds to a published GitHub release with immutable: true, per GitHub’s immutable release strategy (https://docs.github.com/en/actions/how-tos/create-and-publish-actions/using-immutable-releases-and-tags-to-manage-your-actions-releases). This complements the existing full-commit-SHA and Docker digest pin checks.
Non-GitHub RepoClient implementations (GitLab, Azure DevOps, local dir, git, ossfuzz) return ErrUnsupportedFeature, matching the pattern used for other GitHub-only features.
Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com
Signed-off-by: Jesse Houwing jesse.houwing@gmail.com
Signed-off-by: Jesse Houwing jesse.houwing@gmail.com
- Address review: enterprise repo check before dotcom fallback, anonymous dotcom client, skip unsupported debug log
Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com
Signed-off-by: Jesse Houwing jesse.houwing@gmail.com
- Allow optional GITHUB_DOTCOM_TOKEN for github.com fallback
Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com
Signed-off-by: Jesse Houwing jesse.houwing@gmail.com
- Revert optional GITHUB_DOTCOM_TOKEN for github.com fallback
Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com
Signed-off-by: Jesse Houwing jesse.houwing@gmail.com
- Pin test fixtures to LF line endings
Prevents core.autocrlf checkouts from breaking byte-exact patch tests.
Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com Signed-off-by: Jesse Houwing jesse.houwing@gmail.com
- Add coverage for immutable release lookups and caching
Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com Signed-off-by: Jesse Houwing jesse.houwing@gmail.com
- Inject the github.com fallback transport and test it stays anonymous
Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com Signed-off-by: Jesse Houwing jesse.houwing@gmail.com
- Fix lint issues in immutable release pinning
Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com Signed-off-by: Jesse Houwing jesse.houwing@gmail.com
Signed-off-by: Jesse Houwing jesse.houwing@gmail.com Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com Co-authored-by: Jamie Magee jamie.magee@gmail.com
版权所有:中国计算机学会技术支持:开源发展技术委员会
京ICP备13000930号-9
京公网安备 11010802047560号
OpenSSF Scorecard
Overview
Using Scorecard
Checks
Other Important Recommendations
Scoring
Contribute
FAQ
Overview
What is Scorecard?
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 (“checks”) 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.
The inspiration for Scorecard’s logo: “You passed! All D’s … and an A!”
Project Goals
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.
Act as a measurement tool for existing policies
If OSS consumers require certain behaviors from their dependencies, Scorecard can be used to measure those. With the V5 release, we see Structured Results as a way of doing this if there is a supported analysis. Instead of relying on an aggregate score of X/10, or a Maintained score of Y/10, an OSS consumer may want to ensure the repo they’re depending on isn’t archived (which is covered by the
archivedprobe). The OpenSSF takes this approach with its own Security Baseline for projects.Project Non-Goals
To be a definitive report or requirement that all projects should follow.
Scorecard is not intended to be a one-size-fits-all solution. Every step of making our results is opinionated: what checks get included or excluded, the importance of each check, and how scores are calculated. The checks themselves are heuristics; there are false positives and false negatives.
Whether it’s due to applicability, or feasibility, or a matter of opinion, what’s included or excluded from Scorecard results leads to a lot of discussion. It’s impossible to create a Scorecard that satisfies everyone because different audiences will care about different subsets of behavior.
Aggregate scores in particular tells you nothing about what individual behaviors a repository is or is not doing. Many check scores are aggregated into a single score, and there’s multiple ways of arriving at the same score. These scores change as we add new heuristics or refine the existing ones.
Prominent Scorecard Users
Scorecard has been run on thousands of projects to monitor and track security metrics. Prominent projects that use Scorecard include:
View a Project’s Score
To see scores for projects regularly scanned by Scorecard, navigate to the webviewer. You can also replace the placeholder text (platform, user/org, and repository name) in the following template link to generate a custom Scorecard link for a repo:
https://scorecard.dev/viewer/?uri=<github_or_gitlab>.com/<user_name_or_org>/<repository_name>For example:
To view scores for projects not included in the webviewer, use the Scorecard CLI.
Public Data
Scorecard scans more than 1.3 million repositories every week, from
ossf/scorecard-infra. Results are available through the REST API. The BigQuery public dataset is no longer available; see Scorecard Infrastructure Changes for details.To add a project to the weekly scan, follow the instructions in
ossf/scorecard-infra‘s contributing guide.Using Scorecard
Scorecard GitHub Action
The easiest way to use Scorecard on GitHub projects you own is with the Scorecard GitHub Action. The Action runs on any repository change and issues alerts that maintainers can view in the repository’s Security tab. For more information, see the Scorecard GitHub Action installation instructions.
Scorecard REST API
To query pre-calculated scores of OSS projects, use the REST API. Scores calculated from our weekly scan omit the
CI-Tests,Contributors, andDependency-Update-Toolchecks due to the API costs associated with running them at scale.API results are cached with a CDN (thanks to Fastly and their Fast Forward program). Results are purged from the CDN when new results are available, but if you notice issues with stale data, please open an issue.
To enable your project to be available on the REST API, set
publish_results: truein the Scorecard GitHub Action setting.Data provided by the REST API is licensed under the CDLA Permissive 2.0.
Scorecard Badges
Enabling
publish_results: truein Scorecard GitHub Actions also allows maintainers to display a Scorecard badge on their repository to show off their hard work. This badge also auto-updates for every change made to the repository. See more details on this OSSF blogpost.To include a badge on your project’s repository, simply add the following markdown to your README:
Scorecard Command Line Interface
To run a Scorecard scan on projects you do not own, use the command line interface installation option.
Prerequisites
Platforms: Currently, Scorecard supports OSX and Linux platforms. If you are using a Windows OS you may experience issues. Contributions towards supporting Windows are welcome.
Language: You must have GoLang installed to run Scorecard (https://golang.org/doc/install)
Installation
Docker
scorecardis available as a Docker container:To use a specific scorecard version (e.g., v3.2.1), run:
Standalone
To install Scorecard as a standalone:
Visit our latest release page and download the correct zip file for your operating system.
Add the binary to your
GOPATH/bindirectory (usego env GOPATHto identify your directory if necessary).Verifying SLSA provenance for downloaded releases
We generate SLSA3 signatures using the OpenSSF’s slsa-framework/slsa-github-generator during the release process. To verify a release binary:
multiple.intoto.jsonlfrom the same GitHub release as your archive.Using package managers
nix-shell -p nixpkgs.scorecardscorecardbrew install scorecardAuthentication
GitHub imposes api rate limits on unauthenticated requests. To avoid these limits, you must authenticate your requests before running Scorecard. There are two ways to authenticate your requests: either create a GitHub personal access token, or create a GitHub App Installation.
public_reposcope. Set the token in an environment variable calledGITHUB_AUTH_TOKEN,GITHUB_TOKEN,GH_AUTH_TOKENorGH_TOKENusing the commands below according to your platform.OR
setorexport) shown above for your platform.These variables can be obtained from the GitHub developer settings page.
Basic Usage
Using repository URL
Scorecard can run using just one argument, the URL of the target repo:
Docker
The
GITHUB_AUTH_TOKENhas to be set to a valid tokenTo use a specific scorecard version (e.g., v3.2.1), run:
Showing Detailed Results
For more details about why a check fails, use the
--show-detailsoption:Showing Maintainers Annotations
Maintainer Annotations let maintainers add context to display alongside Scorecard check results. Annotations can provide users additional information when Scorecard has an incomplete assessment of a project’s security practices. To see the maintainers annotations for each check, use the
--show-annotationsoption.For more information on available annotations or how to make annotations, see the configuration doc.
Using a GitLab Repository
To run Scorecard on a GitLab repository, you must create a GitLab Access Token with the following permissions:
read_apiread_userread_repositoryYou can run Scorecard on a GitLab repository by setting the
GITLAB_AUTH_TOKENenvironment variable:For an example of using Scorecard in GitLab CI/CD, see here.
Self Hosted Editions
While we focus on GitLab.com support, Scorecard also works with self-hosted GitLab installations. If your platform is hosted at a subdomain (e.g.
gitlab.foo.com), Scorecard should work out of the box. If your platform is hosted at some slug (e.g.foo.com/bar/), you will need to set theGL_HOSTenvironment variable.Using GitHub Enterprise Server (GHES) based Repository
To use a GitHub Enterprise host
github.corp.com, use theGH_HOSTenvironment variable.Using a Package manager
For projects in the
--npm,--pypi,--rubygems, or--nugetecosystems, you have the option to run Scorecard using a package manager. Provide the package name to run the checks on the corresponding GitHub source code.For example,
--npm=angular.Note: The package ecosystem flags are to find a GitHub repo only. These flags do not change the final evaluation for the checks.
Additionally, the flags cannot be used with
--repo.Running specific checks
To run only specific check(s), add the
--checksargument with a list of check names.For example,
--checks=CI-Tests,Code-Review.Formatting Results
The currently supported formats are
default(text) andjson.These may be specified with the
--formatflag. For example,--format=json.Checks
Scorecard Checks
The following checks are all run against the target project by default:
repoorrepo> public_repo), GITHUB_TOKENadmin: repo_hookoradmin> read:repo_hookdocDetailed Checks Documentation
To see detailed information about each check, its scoring criteria, and remediation steps, check out the checks documentation page.
Beginner’s Guide to Scorecard Checks
For a guide to the checks you should use when getting started, see the beginner’s guide to scorecard checks.
Other Important Recommendations
Two-factor Authentication (2FA)
Two-factor Authentication (2FA) adds an extra layer of security when logging into websites or apps. 2FA protects your account if your password is compromised by requiring a second form of authentication, such as codes sent via SMS or authentication app, or touching a physical security key.
We strongly recommend that you enable 2FA on any important accounts where it is available. 2FA is not a Scorecard check because GitHub and GitLab do not make that data about user accounts public. Arguably, this data should always remain private, since accounts without 2FA are so vulnerable to attack.
Though it is not an official check, we urge all project maintainers to enable 2FA to protect their projects from compromise.
Enabling 2FA
For users
Follow the steps described at Configuring two-factor authentication
If possible, use either:
As a last option, use SMS. Beware: 2FA using SMS is vulnerable to SIM swap attack.
For an organization
Scoring
Aggregate Score
Each individual check returns a score of 0 to 10, with 10 representing the best possible score. Scorecard also produces an aggregate score, which is a weight-based average of the individual checks weighted by risk.
See the list of current Scorecard checks for each check’s risk level.
Contribute
Report Problems
If you have what looks like a bug, please use the GitHub issue tracking system. Before you file an issue, please search existing issues to see if your issue is already covered.
Contribute to Scorecard
Before contributing, please follow our Code of Conduct.
See the Contributing documentation for guidance on how to contribute to the project.
Adding a Scorecard Check
If you’d like to add a check, please see guidance here.
Connect with the Scorecard Community
If you want to get involved in the Scorecard community or have ideas you’d like to chat about, we discuss this project in the OSSF Best Practices Working Group meetings.
Video Call: LFX Zoom
EMEA-friendly Every 4 Mondays at 7:00-8:00 AM Pacific (OSSF Public Calendar)
Video Call: LFX Zoom
Maintainers are listed in the CODEOWNERS file.
Report a Security Issue
To report a security issue, please follow instructions here.
Join the Scorecard Project Meeting
Zoom
APAC-friendly Biweekly on Thursdays at 1:00-2:00 PM Pacific (OSSF Public Calendar)
Video Call: LFX z o o m
EMEA-friendly Every 4 Mondays at 7:00-8:00 AM Pacific (OSSF Public Calendar)
Video Call: LFX z o o m
Agenda
You can see the agenda and meeting notes here.
Stargazers over time
FAQ
FAQ
See the FAQ for answers to Frequently Asked Questions about Scorecard.