mirror of
https://github.com/ossf/scorecard.git
synced 2024-09-17 11:57:12 +03:00
add stepsec (#1438)
This commit is contained in:
laurentsimon
GitHub
parent
09a41a93b4
commit
48f10693e0
@ -59,9 +59,8 @@ Allowed by Scorecards:
|
||||
Risk: `High` (vulnerable to intentional malicious code injection)
|
||||
|
||||
This check determines whether a project's default and release branches are
|
||||
protected with GitHub's
|
||||
[branch protection](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)
|
||||
settings. Branch protection allows maintainers to define rules that enforce
|
||||
protected with GitHub's [branch protection](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches) settings.
|
||||
Branch protection allows maintainers to define rules that enforce
|
||||
certain workflows for branches, such as requiring review or passing certain
|
||||
status checks before acceptance into a main branch, or preventing rewriting of
|
||||
public history.
|
||||
@ -83,15 +82,13 @@ Different types of branch protection protect against different risks:
|
||||
branches, which overwrites code irrevocably. This protection prevents the
|
||||
rewriting of public history without external notice.
|
||||
|
||||
- Require
|
||||
[status checks](https://docs.github.com/en/github/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks):
|
||||
- Require [status checks](https://docs.github.com/en/github/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks):
|
||||
ensures that all required CI tests are met before a change is accepted.
|
||||
|
||||
Although requiring code review can greatly reduce the chance that
|
||||
unintentional or malicious code enters the "main" branch, it is not feasible for
|
||||
all projects, such as those that don't have many active participants. For more
|
||||
discussion, see
|
||||
[Code Reviews](https://github.com/ossf/scorecard/blob/main/docs/checks.md#code-reviews).
|
||||
discussion, see [Code Reviews](https://github.com/ossf/scorecard/blob/main/docs/checks.md#code-reviews).
|
||||
|
||||
Additionally, in some cases these rules will need to be suspended. For example,
|
||||
if a past commit includes illegal content such as child pornography, it may be
|
||||
@ -158,14 +155,12 @@ If a project's system was not detected and you think it should be, please
|
||||
|
||||
Risk: `Low` (possibly not following security best practices)
|
||||
|
||||
This check determines whether the project has earned a [CII Best Practices
|
||||
Badge](https://bestpractices.coreinfrastructure.org/), which indicates that the
|
||||
project uses a set of security-focused best development practices for open
|
||||
This check determines whether the project has earned a [CII Best Practices Badge](https://bestpractices.coreinfrastructure.org/),
|
||||
which indicates that the project uses a set of security-focused best development practices for open
|
||||
source software. The check uses the URL for the Git repo and the CII API.
|
||||
|
||||
The CII Best Practices badge has 3 tiers: passing, silver, and gold. We give
|
||||
full credit to projects that meet the [passing
|
||||
criteria](https://bestpractices.coreinfrastructure.org/criteria/0), which is a
|
||||
full credit to projects that meet the [passing criteria](https://bestpractices.coreinfrastructure.org/criteria/0), which is a
|
||||
significant achievement for many projects. Lower scores represent a project that
|
||||
is at least working to achieve a badge, with increasingly more points awarded as
|
||||
more criteria are met.
|
||||
@ -471,18 +466,18 @@ dependencies using the [GitHub dependency graph](https://docs.github.com/en/code
|
||||
- First determine if your project is producing a library or application. If it is a library, you generally don't want to pin dependencies of library users, and should not follow any remediation steps.
|
||||
- If your project is producing an application, declare all your dependencies with specific versions in your package format file (e.g. `package.json` for npm, `requirements.txt` for python). For C/C++, check in the code from a trusted source and add a `README` on the specific version used (and the archive SHA hashes).
|
||||
- If the package manager supports lock files (e.g. `package-lock.json` for npm), make sure to check these in the source code as well. These files maintain signatures for the entire dependency tree and saves from future exploitation in case the package is compromised.
|
||||
- For Dockerfiles and GitHub workflows, pin dependencies by hash. See [main.yaml](https://github.com/ossf/scorecard/blob/f55b86d6627cc3717e3a0395e03305e81b9a09be/.github/workflows/main.yml#L27) and [Dockerfile](https://github.com/ossf/scorecard/blob/main/cron/worker/Dockerfile) for examples.
|
||||
- For Dockerfiles, pin dependencies by hash. See [Dockerfile](https://github.com/ossf/scorecard/blob/main/cron/worker/Dockerfile) for example.
|
||||
- For GitHub workflows, pin dependencies by hash. See [main.yaml](https://github.com/ossf/scorecard/blob/f55b86d6627cc3717e3a0395e03305e81b9a09be/.github/workflows/main.yml#L27) for example. To determine the permissions needed for your workflows, you may use [StepSecurity's online tool](https://app.stepsecurity.io/) by ticking the "Pin actions to a full length commit SHA". You may also tick the "Restrict permissions for GITHUB_TOKEN" to fix issues found by the Token-Permissions check.
|
||||
- To help update your dependencies after pinning them, use tools such as
|
||||
Github's
|
||||
[dependabot](https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/) or [renovate bot](https://github.com/renovatebot/renovate).
|
||||
Github's [dependabot](https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/)
|
||||
or [renovate bot](https://github.com/renovatebot/renovate).
|
||||
|
||||
## SAST
|
||||
|
||||
Risk: `Medium` (possible unknown bugs)
|
||||
|
||||
This check tries to determine if the project uses Static Application Security
|
||||
Testing (SAST), also known as
|
||||
[static code analysis](https://owasp.org/www-community/controls/Static_Code_Analysis).
|
||||
Testing (SAST), also known as [static code analysis](https://owasp.org/www-community/controls/Static_Code_Analysis).
|
||||
It is currently limited to repositories hosted on GitHub, and does not support
|
||||
other source hosting repositories (i.e., Forges).
|
||||
|
||||
@ -534,7 +529,7 @@ not support other source hosting repositories (i.e., Forges).
|
||||
Signed releases attest to the provenance of the artifact.
|
||||
|
||||
This check looks for the following filenames in the project's last five
|
||||
releases: [*.minisig ](https://github.com/jedisct1/minisign), *.asc (pgp),
|
||||
releases: [*.minisig](https://github.com/jedisct1/minisign), *.asc (pgp),
|
||||
*.sig, *.sign.
|
||||
|
||||
Note: The check does not verify the signatures.
|
||||
@ -575,6 +570,7 @@ enabled, as there is no API available.
|
||||
|
||||
**Remediation steps**
|
||||
- Set permissions as `read-all` or `contents: read` as described in GitHub's [documentation](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#permissions).
|
||||
- To help determine the permissions needed for your workflows, you may use [StepSecurity's online tool](https://app.stepsecurity.io/) by ticking the "Restrict permissions for GITHUB_TOKEN". You may also tick the "Pin actions to a full length commit SHA" to fix issues found by the Pinned-dependencies check.
|
||||
|
||||
## Vulnerabilities
|
||||
|
||||
|
||||
@ -486,11 +486,12 @@ checks:
|
||||
maintain signatures for the entire dependency tree and saves from future
|
||||
exploitation in case the package is compromised.
|
||||
- >-
|
||||
For Dockerfiles and GitHub workflows, pin dependencies by hash. See
|
||||
[main.yaml](https://github.com/ossf/scorecard/blob/f55b86d6627cc3717e3a0395e03305e81b9a09be/.github/workflows/main.yml#L27)
|
||||
and
|
||||
[Dockerfile](https://github.com/ossf/scorecard/blob/main/cron/worker/Dockerfile)
|
||||
for examples.
|
||||
For Dockerfiles, pin dependencies by hash. See [Dockerfile](https://github.com/ossf/scorecard/blob/main/cron/worker/Dockerfile) for example.
|
||||
- >-
|
||||
For GitHub workflows, pin dependencies by hash. See [main.yaml](https://github.com/ossf/scorecard/blob/f55b86d6627cc3717e3a0395e03305e81b9a09be/.github/workflows/main.yml#L27) for example.
|
||||
To determine the permissions needed for your workflows, you may use [StepSecurity's online tool](https://app.stepsecurity.io/) by ticking
|
||||
the "Pin actions to a full length commit SHA". You may also tick the "Restrict permissions for GITHUB_TOKEN" to fix issues found
|
||||
by the Token-Permissions check.
|
||||
- >-
|
||||
To help update your dependencies after pinning them, use tools such as
|
||||
Github's [dependabot](https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/)
|
||||
@ -616,6 +617,10 @@ checks:
|
||||
- >-
|
||||
Set permissions as `read-all` or `contents: read` as described in
|
||||
GitHub's [documentation](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#permissions).
|
||||
- >-
|
||||
To help determine the permissions needed for your workflows, you may use [StepSecurity's online tool](https://app.stepsecurity.io/) by ticking
|
||||
the "Restrict permissions for GITHUB_TOKEN". You may also tick the "Pin actions to a full length commit SHA" to fix issues found
|
||||
by the Pinned-dependencies check.
|
||||
Vulnerabilities:
|
||||
risk: High
|
||||
tags: supply-chain, security, vulnerabilities
|
||||
|
||||
Loading…
Reference in New Issue
Block a user