[bug] Improve Scorecard score

[melba-lopez]

Describe the bug Improve repository's OpenSSF Scorecard score (currently at 7.1)

To Reproduce docker run -e GITHUB_AUTH_TOKEN gcr.io/openssf/scorecard:stable --show-details --repo=https://github.com/slsa-framework/slsa-github-generator --format=json > scorecard_slsa-framework_slsa-github-generator.json

Expected behavior

• Branch Protections could be improved
• CII-Best-Practices Badge could be obtained
• Project should be Fuzzed
• Security Policy should be created
• Token Permissions should follow principle of least priveledge

Screenshots

Additional context Attempted to upload the JSON file, but github does not allow me to. Related to recommendation of securing our repos: https://github.com/slsa-framework/slsa/issues/424

[laurentsimon]

Thank you!

You know you can send us some PR and possibly get rewarded at sos.dev, right?

[melba-lopez]

I thought PRs were mostly meant for doc/code changes?? I know I am unable to make these changes myself since I don't have repo access. So not sure how that would work?

[laurentsimon]

The permission changes could be changes you propose via a PR. If you identify some critical projects and get them to accept your PR, you can use sos.dev to be rewarded

Some config settings like branch protection cannot be changed via PR, you are correct.

[jspeed-meyers]

Would adding permissions: read-all to the GitHub action YAML files be sufficient to address the "Token Permissions should follow principle of least privilege" bullet point?

That's what my reading of the Scorecards documentation on token permissions remediation suggests.

If that's a correct interpretation, I'm glad to help out with a PR that adds this line repeatedly.

[laurentsimon]

I thought we already set the permissions as read-only in all our workflows. If we don't for some, please feel free to send a PR

[jspeed-meyers]

Huh, scorecard says, as of 10/19/22 for this repo, 0/10 for Token-Permissions and that non read-only tokens detected. Let me do a little digging.

[jspeed-meyers]

Could it be this line? https://github.com/slsa-framework/slsa-github-generator/blob/61d71969e88ad66f920aa17d86d822f428aa49cf/.github/workflows/generator_container_slsa3.yml#L88-L91

Seems like the keyless signing requires non-read permissions, so I'm not sure there's any way to get around this 0/10 Token-Permissions scorecard score. If I am misunderstanding, please correct me and I'm glad to put in a PR.

[laurentsimon]

You're right. Scorecard scoring is going to change in the next release to address this. See https://github.com/ossf/scorecard/issues/2338

[ianlewis]

We have a score of 9 now but I think we can close once we've completed the following tasks that were written in the description.

• [x] Branch Protections could be improved: we have branch protections in place. scorecard can't detect it because it needs admin access. Using a PAT with scorecard is not recommended so this is what it is for now.
• [x] CII-Best-Practices Badge could be obtained: we have a badge and are working towards it. Tracked on #886
• [x] Project should be Fuzzed: I don't think fuzzing is in scope for this project but we use other dynamic analysis (unit tests and e2e tests). Coverage of unit tests is tracked in #898
• [x] Security Policy should be created: tracked by #541
• [x] Token Permissions should follow principle of least priveledge: we've made some changes and I think we are using least-privilege now.

[ianlewis]

It seems that scorecard also dings us hard for using packages: write. It's giving us a zero for the 'Token-Permissions' check.

[laurentsimon]

This should go away with one of the future releases of Scorecard

[ianlewis]

We finished the tasks I mentioned above and now have a overall scorecard score if 9+ so I think we have completed this.