OpenSSF scorecard + openSSF best practice. #211
Comments
|
Seems a bit low priority, given what it provides us and we don't have a lot of dependencies. |
I think you misunderstood what is openSSF scorecard. It's not a dependency analyser, it's a project analyser like codeQL. It's take a look if someone push commit directly on main, if there a ci, if releases is signed ... |
|
Ok, I'll take a look at adding it then and see if we find it useful. |
|
@bjosv Is this what you did in some other projects? |
|
Yes, I'm currently looking into OpenSSFs suggestions and I see there are good suggestions that we easily can fix in valkeys CI workflows. I can fix those in a PR, but then there are other improvement like branch-protection that you maintainers need to config in the project settings. |
|
I ran OpenSSFs tool on the project and the current scorecard is not bad: |
there are a GitHub action to automatically get score. |
This sets the default permission for current CI workflows to only be able to read from the repository (scope: "contents"). When a used Github Action require additional permissions (like CodeQL) we grant that permission on job-level instead. This means that a compromised action will not be able to modify the repo or even steal secrets since all other permission-scopes are implicit set to "none", i.e. not permitted. This is recommended by [OpenSSF](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions). This PR includes a small fix for the possibility of missing server logs artifacts, found while verifying the permission. The `upload-artifact@v3` action will replace artifacts which already exists. Since both CI-jobs `test-external-standalone` and `test-external-nodebug` uses the same artifact name, when both jobs fail, we only get logs from the last finished job. This can be avoided by using unique artifact names. This PR is part of #211 More about permissions and scope can be found here: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions --------- Signed-off-by: Björn Svensson <bjorn.a.svensson@est.tech>
This sets the default permission for current CI workflows to only be able to read from the repository (scope: "contents"). When a used Github Action require additional permissions (like CodeQL) we grant that permission on job-level instead. This means that a compromised action will not be able to modify the repo or even steal secrets since all other permission-scopes are implicit set to "none", i.e. not permitted. This is recommended by [OpenSSF](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions). This PR includes a small fix for the possibility of missing server logs artifacts, found while verifying the permission. The `upload-artifact@v3` action will replace artifacts which already exists. Since both CI-jobs `test-external-standalone` and `test-external-nodebug` uses the same artifact name, when both jobs fail, we only get logs from the last finished job. This can be avoided by using unique artifact names. This PR is part of valkey-io#211 More about permissions and scope can be found here: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions --------- Signed-off-by: Björn Svensson <bjorn.a.svensson@est.tech>
This sets the default permission for current CI workflows to only be able to read from the repository (scope: "contents"). When a used Github Action require additional permissions (like CodeQL) we grant that permission on job-level instead. This means that a compromised action will not be able to modify the repo or even steal secrets since all other permission-scopes are implicit set to "none", i.e. not permitted. This is recommended by [OpenSSF](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions). This PR includes a small fix for the possibility of missing server logs artifacts, found while verifying the permission. The `upload-artifact@v3` action will replace artifacts which already exists. Since both CI-jobs `test-external-standalone` and `test-external-nodebug` uses the same artifact name, when both jobs fail, we only get logs from the last finished job. This can be avoided by using unique artifact names. This PR is part of valkey-io#211 More about permissions and scope can be found here: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions --------- Signed-off-by: Björn Svensson <bjorn.a.svensson@est.tech>
|
Here is a bunch of compiler warnings (and more) to use specifically for C: https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++ We can add the easy ones without any problem. Contributions are welcome. |
Pin the Github Action dependencies to the hash according to secure software development best practices recommended by the Open Source Security Foundation (OpenSSF). When developing a CI workflow, it's common to version-pin dependencies (i.e. actions/checkout@v4). However, version tags are mutable, so a malicious attacker could overwrite a version tag to point to a malicious or vulnerable commit instead. Pinning workflow dependencies by hash ensures the dependency is immutable and its behavior is guaranteed. See https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies The `dependabot` supports updating a hash and the version comment so its update will continue to work as before. Links to used actions and theit tag/hash for review/validation: https://github.com/actions/checkout/tags (v4.1.2 was rolled back) https://github.com/github/codeql-action/tags https://github.com/maxim-lobanov/setup-xcode/tags https://github.com/cross-platform-actions/action/releases/tag/v0.22.0 https://github.com/py-actions/py-dependency-install/tags https://github.com/actions/upload-artifact/tags https://github.com/actions/setup-node/tags https://github.com/taiki-e/install-action/releases/tag/v2.32.2 This PR is part of #211. Signed-off-by: Björn Svensson <bjorn.a.svensson@est.tech>
|
We should add CI + badge for openSSF scorecard in this repo and continue on other repo |
OpenSSF scorecard is a super tools done by the OpenSSF to give a security score of an repo.
Best practice is giving a tier for the accomplished good open source practice of the project.
The text was updated successfully, but these errors were encountered: