-
Notifications
You must be signed in to change notification settings - Fork 489
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
Using Scorecard GitHub Action reduces the Token-Permissions score #2152
Comments
@spencerschrock fyi |
@sethmlarson slightly off-topic, but I am curious why you got a remediation link for |
@varunsh-coder Great question! I copied this output from this page: https://deps.dev/pypi/urllib3 to save me a second in running scorecard to get the output. |
Thats interesting. @azeemshaikh38, @laurentsimon any idea how deps.dev gets the remediation URLs? There seems to be a bug there. |
They are just taking the information from the scorecard result using the BQtable. Let's verify what in the BQTable for this project. |
Great find! So running the check locally seems to work fine, but our cron job table spits out the wrong result (which then propagates to deps.dev). Looks like this might be an interesting memory corruption bug - i.e we are persisting memory across runs of Scorecard which we shouldn't be doing. @spencerschrock could you look into debugging this? |
I highly suspect this line of code here: https://github.com/ossf/scorecard/blob/main/remediation/remediations.go#L47 |
Wrapping up tests for the commit for the original issue. can take a look at the cron job after |
I think there is a bigger problem here we need to address (maybe in a separate issue) - if we can so easily break the results shown on deps.dev, it'll be hard to build any kind of trust on Scorecard results. We need to tighten how these results get published. @brianrussell2 fyi |
Re-opening. Can use this issue to track the cron job bug too. |
👍 The problem is removing the If we want to support concurrency (especially for something large like the cron jobs), I think the answer is dependency injection. That would just require changes to function signatures / raw data structs to accommodate it and I haven't found the cleanest way of doing it. |
Just a thought: remediation should belong in If every check generates its own remediation, it makes sense that it should just get generated on a per check basis inside |
no strong opinion from me here. I think the long-term plan was to take evaluation/ out of the checks/ in the future, which is why the remediation was out. But either works for me.
Maybe a simple fix is to remove the |
I was still thinking there would need to be some sort of change here to bridge the gap between the
I believe this leads to the data race problems I was talking about above. All checks are spun up as separate goroutines as part of
|
Making this change is not urgent, IFAICT. It's re-factoring, does not need to be in this PR.
I meant remove the global as well if the info can be retrieved via repo client directly. |
Not sure why this is needed? We can simply move all the |
It's the end of the day, so I might just be missing something obvious, but my thought is: Inside |
You're correct, the If some information is missing, maybe it should be added in the raw results. I think we have hijacked the original intent of this issue, though :-) |
I see, that makes sense. Like @laurentsimon mentioned, I think the right way to solve this is to have info like URL, branch_name etc. in RawData. But I know it's not an easy change and might take time. So, let's remove the Once the fix is in, let's reconsider how to solve it the right way using RawData. Wdyt? |
I'm fine with that. |
The remediation data made its way into raw data in #3632 |
Describe the bug
urllib3 recently added the Scorecard GitHub Action to its repository. After adding this we observed our "Token-Permissions" score being 9/10 instead of the previous value of 10/10. This was due to:
This is because the action wants the permission
security-events: write
which is a permission that is docked points if given to any GitHub Action.Reproduction steps
Steps to reproduce the behavior:
security-events: write
Expected behavior
A clear and concise description of what you expected to happen.
Using the Scorecard GitHub Action shouldn't reduce the project's scorecard score.
The text was updated successfully, but these errors were encountered: