Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvement of OpenSSF Scorecard Score #2688

Open
4 tasks
harshitasao opened this issue Aug 16, 2024 · 3 comments
Open
4 tasks

Improvement of OpenSSF Scorecard Score #2688

harshitasao opened this issue Aug 16, 2024 · 3 comments

Comments

@harshitasao
Copy link
Contributor

harshitasao commented Aug 16, 2024

Description of issue or feature request:
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: 7.9

Scorecard report: https://scorecard.dev/viewer/?uri=github.com/theupdateframework/python-tuf

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

  • Token-Permissions: Score = 0

    • The issue here is that many workflows doesn’t have a top-level read-only permissions block like present in the other workflows. Scorecard is quite severe in this check: a single workflow without top-level permissions gets a 0/10 for the check.
    • PR: fix: fixed the pinned-dependencies #2689
  • Signed-Releases: Score = 4

    • The releases need to be signed; we can use cosign using github actions for that, and it will increase the score to 8. Additionally, SLSA provenance also needs to be added, which can be done using this, increasing the overall score to 10.
  • Fuzzing: Score = 0

    • Integrating the project with OSS-Fuzz by following the instructions here. The most difficult one on the list, maintainers help, is highly appreciated. For example, helping in identifying the components where fuzz testing will be added.
  • Pinned-Dependencies: Score = 4

    • pip command and many github actions are not pinned by hash, which results in a low score.
    • Pinning dependencies to a specific hash rather than allowing mutable versions or ranges of versions improves supply chain security.
    • PR: fix: fixed the pinned-dependencies #2689

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

@jku
Copy link
Member

jku commented Aug 19, 2024

pip command and many github actions are not pinned by hash

python pinning

I believe no python installs are unpinned, I'd be happy to get an issue/PR for anything that is unpinned.

github-actions pinning

Everything security relevant is pinned to hash. Non-critical actions are not pinned in order to lower the maintenance burden (as an example actions/dependency-review-action is not pinned since it is used in a workflow where it can do no harm): if you find anything that seems like a potential security issue, please file a bug.

Fuzzing

If you have good ideas how to effectively fuzz python code we will definitely take them.

Signing release

Considering the subject matter of this project we'd be really interested in signing and provenance -- but since python is predominantly distributed through pypi it is hard to argue that signing and provenance for only some other distribution methods (that almost no-one uses) is worth it... This is something we might be willing to discuss (there is already a related and ancient #2000 about it)

token permissions

setting a default token permission seems like a decent idea (even if it doesn't really change the default). I closed the PR since it contained the unwanted pinning in it: feel free to open a new one for just the token change

@jku
Copy link
Member

jku commented Sep 12, 2024

Hey @harshitasao, this is only slightly related ... but can you explain why we would get zero points for
Code-Review: We do require review for every single PR.

EDIT: oh it's not a zero, it's a "?" probably because a lot of dependabot commits

@jku
Copy link
Member

jku commented Sep 12, 2024

setting a default token permission seems like a decent idea (even if it doesn't really change the default).

This is in #2684 now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants