Improvement of OpenSSF Scorecard Score

[harshitasao]

Title: Improvement of OpenSSF Scorecard Score

Description:
Hi, I'm Harshita. I’m working with CNCF and the Google Open Source Security Team for the GSoC 2024 term. We are collaborating to enhance security practices across various CNCF projects. The goal is to improve security for all CNCF projects by both using OpenSSF Scorecards and implementing its security improvements.

As this project already has scorecard action, I'm here to increase the final score by going over each check. I've listed all of the checks where work needs to be done, in order of its criticality. I plan to submit each PR for each fix. Please let me know what you think and for which ones a PR is welcome that I will submit it ASAP.

Current Score: 8.4

Scorecard report: https://scorecard.dev/viewer/?uri=github.com/envoyproxy/envoy

Here's a few checks we can work on to improve the project's security posture:

• Branch-Protection: Score = 4

  • In my opinion, adding the following checks would be useful:
    1. Require at least 2 reviewers for approval before merging.
    2. Require review from code owners.

  • Or using GH rulesets as these are public and Scorecard will check for these as well.

  • NOTE: This can only be done by the maintainers.

• Binary-Artifacts: Score = 8

  • The project contains two binaries:
    https://github.com/envoyproxy/envoy/blob/main/test/common/json/json_sanitizer_corpus/binary_file
    https://github.com/envoyproxy/envoy/blob/main/tools/gsutil/crcmod/_crcfunext.cpython-312-x86_64-linux-gnu.so
  • Problems with generated executable (binary) artifacts
  • Binaries allowed by Scorecard
  • To solve this we can either remove the generated executable artifacts from the repository or build from source.

• Signed-Releases: Score = 8

  • SLSA provenance needs to be added, which can be done using this, increasing the overall score to 10.

• Pinned-Dependencies: Score = 1

  • Some github actions and container images of Dockerfile are not pinned by hash, which results in a low score. But pinning container images would introduce the risk of outdated images.
  • Pinning dependencies to a specific hash rather than allowing mutable versions or ranges of versions improves supply chain security.

/cc @joycebrum @diogoteles08 @pnacht @nate-double-u

[adisuissa]

cc @envoyproxy/senior-maintainers @envoyproxy/security-team

[phlax]

cc @mmorel-35

[phlax]

re branch protection - i think we probably dont want to enforce 2 reviewers, or to enforce codeowner review if a maintainer has reviewed

re binaries - none of these are trivial to remove (afaiaa) or they would have been removed already

re signed releases - we do sign our releases using pgp, perhaps we can add the provenance stuff also

re pinned deps - all are pinned (afaiaa) other than the CI actions we develop ourselves - the reason these are not is that it has historically caused issues with dependabot

[ggreenway]

I think @phlax has covered this pretty well. I'm not sure there's anything we actually want to change here, except possibly the signed release provenance.

I think in particular the score you arrived at on pinned deps is incorrect, as all code dependencies are pinned already.

[phlax]

the OSSF score is checked on every push - there is a badge on the repo README showing it

@mmorel-35 added the necessary to make this work some time ago and we got the score above 9 at that time

since then i reverted the pins for the toolshed github actions as it was causing some issues - this dropped our score significantly

you can check the found issues here https://github.com/envoyproxy/envoy/security/code-scanning

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.