Skip to content

Improvement of OpenSSF Scorecard Score #2688

Closed

Description

@harshitasao

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

Activity

  1. jku commented on Aug 19, 2024

    @jku
    Member

    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

  2. jku commented on Sep 12, 2024

    @jku
    Member

    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

  3. jku commented on Sep 12, 2024

    @jku
    Member

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

    This is in #2684 now.

  4. jku commented on Mar 7, 2025

    @jku
    Member

    I think we've done what we want to fix here:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions