2021-04-16 21:15:56 +03:00
|
|
|
# Copyright 2021 Security Scorecard Authors
|
|
|
|
#
|
|
|
|
# Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
# you may not use this file except in compliance with the License.
|
|
|
|
# You may obtain a copy of the License at
|
|
|
|
#
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
#
|
|
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
|
|
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
# See the License for the specific language governing permissions and
|
|
|
|
# limitations under the License.
|
|
|
|
|
|
|
|
# This is the source of truth for all check descriptions and remediation steps.
|
|
|
|
# Run `python3 generate_checks.py` to generate `checks.json` and `checks.md`.
|
|
|
|
checks:
|
|
|
|
Security-Policy:
|
|
|
|
description: >-
|
|
|
|
This check tries to determine if a project has published a security
|
|
|
|
policy. It works by looking for a file named `SECURITY.md`
|
|
|
|
(case-insensitive) in a few well-known directories.
|
|
|
|
remediation:
|
|
|
|
- >-
|
|
|
|
Place a security policy file `SECURITY.md` in the root directory of
|
|
|
|
your repository. This makes it easily discoverable by a vulnerability
|
|
|
|
reporter.
|
|
|
|
- >-
|
|
|
|
The file should contain information on what constitutes a vulnerability
|
|
|
|
and a way to report it securely (e.g. issue tracker with private issue
|
|
|
|
support, encrypted email with a published public key).
|
|
|
|
Contributors:
|
|
|
|
description: >-
|
|
|
|
This check tries to determine if a project has a set of contributors from
|
|
|
|
multiple companies. It works by looking at the authors of recent commits
|
|
|
|
and checking the `Organization` field on the GitHub user profile.
|
|
|
|
remediation:
|
|
|
|
- >-
|
|
|
|
There is *NO* remediation work needed here. This is just to provide some
|
|
|
|
insights on which organization(s) have contributed to the project and
|
|
|
|
making trust decision based on that.
|
|
|
|
Frozen-Deps:
|
|
|
|
description: >-
|
|
|
|
This check tries to determine if a project has declared and pinned its
|
|
|
|
dependencies. It works by looking for a set of well-known package
|
|
|
|
management lock files.
|
|
|
|
remediation:
|
|
|
|
- >-
|
|
|
|
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.
|
|
|
|
Signed-Tags:
|
|
|
|
description: >-
|
|
|
|
This check looks for cryptographically signed tags in the git history.
|
|
|
|
remediation:
|
|
|
|
- Generate a new signing key.
|
|
|
|
- Add your key to your source hosting provider.
|
|
|
|
- Configure your key and email in git.
|
|
|
|
- Publish the tag and then sign it with this key.
|
|
|
|
- >-
|
|
|
|
For GitHub, check out the steps
|
|
|
|
[here](https://docs.github.com/en/github/authenticating-to-github/signing-tags#further-reading).
|
|
|
|
Signed-Releases:
|
|
|
|
description: >-
|
|
|
|
This check tries to determine if a project cryptographically signs
|
|
|
|
release artifacts. It works by looking for well-known filenames within
|
|
|
|
recently published GitHub releases.
|
|
|
|
remediation:
|
|
|
|
- Publish the release.
|
|
|
|
- Generate a signing key.
|
|
|
|
- Download the release as an archive locally.
|
|
|
|
- Sign the release archive with this key (should output a signature file).
|
|
|
|
- Attach the signature file next to the release archive.
|
|
|
|
- >-
|
|
|
|
For GitHub, check out the steps
|
|
|
|
[here](https://wiki.debian.org/Creating%20signed%20GitHub%20releases).
|
|
|
|
CI-Tests:
|
|
|
|
description: >-
|
|
|
|
This check tries to determine if the project run tests before pull
|
|
|
|
requests are merged. It works by looking for a set of well-known
|
|
|
|
CI-system names in GitHub `CheckRuns` and `Statuses`.
|
|
|
|
remediation:
|
|
|
|
- Check-in scripts that run all the tests in your repository.
|
|
|
|
- >-
|
|
|
|
Integrate those scripts with a CI/CD platform that runs it on every pull
|
|
|
|
request (e.g.
|
|
|
|
[GitHub Actions](https://docs.github.com/en/actions/learn-github-actions/introduction-to-github-actions),
|
|
|
|
[Prow](https://github.com/kubernetes/test-infra/tree/master/prow),
|
|
|
|
etc).
|
|
|
|
Code-Review:
|
|
|
|
description: >-
|
|
|
|
This check tries to determine if a project requires code review before
|
|
|
|
pull requests are merged. It works by looking for a set of well-known
|
|
|
|
code review system results in GitHub Pull Requests.
|
|
|
|
remediation:
|
|
|
|
- >-
|
|
|
|
Follow security best practices by performing strict code reviews for
|
|
|
|
every new pull request.
|
|
|
|
- >-
|
|
|
|
Make "code reviews" mandatory in your repository configuration.
|
|
|
|
E.g. [GitHub](https://docs.github.com/en/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging).
|
|
|
|
- >-
|
|
|
|
Enforce the rule for administrators / code owners as well.
|
|
|
|
E.g. [GitHub](https://docs.github.com/en/github/administering-a-repository/about-protected-branches#include-administrators)
|
|
|
|
CII-Best-Practices:
|
|
|
|
description: >-
|
|
|
|
This check tries to determine if the project has a
|
|
|
|
[CII Best Practices Badge](https://bestpractices.coreinfrastructure.org/en).
|
|
|
|
It uses the URL for the Git repo and the CII API.
|
|
|
|
remediation:
|
|
|
|
- Sign up for the [CII Best Practices program](https://bestpractices.coreinfrastructure.org/en).
|
|
|
|
Pull-Requests:
|
|
|
|
description: >-
|
|
|
|
This check tries to determine if the project requires pull requests for
|
|
|
|
all changes to the default branch. It works by looking at recent commits
|
|
|
|
and using the GitHub API to search for associated pull requests.
|
|
|
|
remediation:
|
|
|
|
- Always open a pull request for any change you intend to make, big or small.
|
|
|
|
- >-
|
|
|
|
Make "pull requests" mandatory in your repository configuration.
|
|
|
|
E.g. [GitHub](https://docs.github.com/en/github/administering-a-repository/about-protected-branches#require-pull-request-reviews-before-merging)
|
|
|
|
- >-
|
|
|
|
Enforce the rule for administrators / code owners as well.
|
|
|
|
E.g. [GitHub](https://docs.github.com/en/github/administering-a-repository/about-protected-branches#include-administrators)
|
|
|
|
Fuzzing:
|
|
|
|
description: >-
|
|
|
|
This check tries to determine if the project uses a fuzzing system. It
|
|
|
|
currently works by checking if the repo name is in the
|
|
|
|
[OSS-Fuzz](https://github.com/google/oss-fuzz) project list.
|
|
|
|
remediation:
|
|
|
|
- >-
|
|
|
|
Integrate the project with OSS-Fuzz by following the instructions
|
|
|
|
[here](https://google.github.io/oss-fuzz/).
|
|
|
|
SAST:
|
|
|
|
description: >-
|
|
|
|
This check tries to determine if the project uses static code analysis
|
|
|
|
systems. It currently works by looking for well-known results
|
|
|
|
([CodeQL](https://securitylab.github.com/tools/codeql), etc.) in GitHub
|
|
|
|
pull requests.
|
|
|
|
remediation:
|
|
|
|
- >-
|
|
|
|
Run CodeQL checks in your CI/CD by following the instructions
|
|
|
|
[here](https://github.com/github/codeql-action#usage).
|
|
|
|
Active:
|
|
|
|
description: >-
|
|
|
|
This check tries to determine if the project is still "actively
|
|
|
|
maintained". It currently works by looking for commits within the last
|
|
|
|
90 days.
|
|
|
|
remediation:
|
|
|
|
- >-
|
|
|
|
There is *NO* remediation work needed here. This is just to indicate
|
|
|
|
your project activity and maintenance commitment.
|
|
|
|
Branch-Protection:
|
|
|
|
description: >-
|
2021-05-03 17:16:01 +03:00
|
|
|
This check tries to determine if the project has branch protection enabled. This check would
|
|
|
|
work only when the token has [Admin access](https://github.community/t/enable-branch-protection-get-api-without-admin/14197) to the repository.
|
2021-04-16 21:15:56 +03:00
|
|
|
remediation:
|
|
|
|
- >-
|
|
|
|
Enable branch protection settings in your source hosting provider to avoid
|
|
|
|
force pushes or deletion of your important branches.
|
|
|
|
- >-
|
|
|
|
For GitHub, check out the steps
|
|
|
|
[here](https://docs.github.com/en/github/administering-a-repository/managing-a-branch-protection-rule).
|