-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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 #15474
Comments
cc @davidhadas |
Welcome @harshitasao As for Fuzzing - see https://knative.dev/blog/events/fuzzing-audit-2023/ |
Hm, regarding #15475 I'm not sure I fully agree with:
Currently, we get every patch of lets say v4 of an action. Sure we have do work to get to v5, but with having fixed hashes without a mechanism to patch those automatically, we would miss 4.1, 4.2 (just an example) and so on. |
Hey @ReToCode. I see Knative Serving already uses Dependabot to bump Actions. Dependabot also works with hash-pinned Actions, so it will simply send you PRs whenever an Action releases a new version. It'll even update the "version comment" next to each hash. If you are concerned about receiving more such PRs (updating from minor versions you get "for free" by using - package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "monthly"
groups:
github-actions:
patterns:
- "*" |
@pnacht I see. I still don't really follow the initial argumentation. Hashes are not more secure nor more up to date than versions (assuming dependabot is used to bump both). Furthermore, preventing supply chain attacks would require us to review the actual changes between versions of actions, otherwise how can we make sure a new version/hash is ok? @cardil WDYT about the grouped updates? I think that could help to prevent even more automated, noisy PRs to all repos. |
Hey @ReToCode. Indeed, the security of hash-pinning + Dependabot PRs comes from the "lag" between the new version being released and the PR being sent. This is actually why I suggest using monthly updates, not weekly: this will mean that a new version will exist in the wild for ~2 weeks (on average) before you receive the PR itself. During this period, the Actions' maintainers and other users might discover problems with the new version and release other fixes, such that Knative Service won't ever be exposed to the problematic release. I also suggest that you enable Dependabot Security Updates if you haven't already. With this enabled, Dependabot will send "out of season" PRs to immediately update dependencies with known vulnerabilities. Therefore, hash-pinning + monthly updates you get some "bake time" before being exposed to new (and untested) versions of dependencies, and "out of season" security updates help you quickly get updated to new versions in case one is eventually found to be dangerous. |
Describe the feature
Is this a bug report or feature request?
What should the feature do:
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.
After the opening of the scorecard action addition PR, 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.3
Scorecard report: https://scorecard.dev/viewer/?uri=github.com/knative/serving
Here's a few checks we can work on to improve the project's security posture [ in order of its criticality ]:
Token-Permissions: Score = 0
Vulnerabilities: Score = 7
osv-scanner.toml
to mark some of these as not impacting/ignored.Signed-Releases: Score = 8
Fuzzing: Score = 0
Pinned-Dependencies: Score = 3
/cc @joycebrum @diogoteles08 @pnacht @nate-double-u
The text was updated successfully, but these errors were encountered: