build(deps): bump github/codeql-action from 3.26.5 to 3.26.6 #435
Conversation
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 3.26.5 to 3.26.6. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@2c779ab...4dd1613) --- updated-dependencies: - dependency-name: github/codeql-action dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]>
| @@ -25,11 +25,11 @@ jobs: | |||
| check-latest: true | |||
|
|
|||
| - name: Initialize CodeQL | |||
| uses: github/codeql-action/init@2c779ab0d087cd7fe7b826087247c2c81f27bfa6 # v3 | |||
| uses: github/codeql-action/init@4dd16135b69a43b6c8efb853346f8437d92d3c93 # v3 | |||
There was a problem hiding this comment.
@mythi I'd welcome the v3 here as well to avoid changing it all the time, what do you think?
There was a problem hiding this comment.
I'm proposing we move away from tags to sha:s for added security. "all the time" is tunable in Dependabot settings: it's no weekly but it can be monthly of course as well.
There was a problem hiding this comment.
The question is whether we are checking the changes in those GH actions before updating them. TBH I have not reviewed the history between 2c77 and 4dd1 as I do trust codeql-action organization.
We can either be paranoiac but then we need strict guidelines to update the dependencies (basically audit or at least review all the to-be-updated actions) but without such guidelines I don't see much sense in the additional overhead.
In the real-life I'd go with something in the middle meaning we can identify organizations we trust and use tags there (like action/checkout) and start using hashes for those we don't trust and add a comment reminding us to review that action code (or at least history) before updating and mention it's for security reasons. Would that work for you?
There was a problem hiding this comment.
Do you see problems using it like this? The frequency of the PRs is a separate topic. Dependabot prepares easy to review Changelog and Commits lists in the PR cover letter so checking the changes is easy. The automation takes care of the updates so I don't see a huge difference between a tag vs a sha.
There was a problem hiding this comment.
If we accommodate the shas with simple comment reminding reviewers to check the GH action log then I'm fine with using shas. Although I'd only do that where needed as every change needs to be reviewed by 2 people, CI needs to be performed (even though it won't test the change as we run on pull_request_target) so yes, it takes time.
Anyway I'm only speaking from my point of view and I'm not maintaining any self-provisioned runners so I think this question should be raised among those who take care of them.
There was a problem hiding this comment.
Yeah I am not really convinced by the benefits of using hashes.
I've moved to use them in a few places. Not because of being paranoid but mainly because it's considered a good security practice. That practice is also checked by tools like OpenSSF Scorecard so if our repos are benchmarked using that common tooling, it shows we are "compliant".
After all, the automation takes care of the updates and we get them on a regular basis (like this PR). If the weekly cadence is too high, we can make it monthly.
There was a problem hiding this comment.
One thing I haven't found in docs (maybe I'm blind) is whether by choosing hashes dependabot will offer the latest main, latest tagged or latest tagged of the version that was previously tagged sha? Or if it uses the comment next to it as "stream" guidance?
Als I'd really like to know what is expected of us during the review. Should it be just yeah, dependabot, merge this or let's check the changelog or review the commit log or look at the git diff of that action and look for potential threats. If we decide we have different needs for different actions then I'd like the "non-default" review policy to be stated in comment, something like:
# Use `git diff` to check changes on this GH action to prevent security issues
uses: github/codeql-action/init@4dd16135b69a43b6c8efb853346f8437d92d3c93 # v3
There was a problem hiding this comment.
latest tagged or latest tagged of the version that was previously tagged sha?
I don't know what the latter means. My experience is it picks up the sha corresponding to the latest tag. The Actions tab has logs, maybe that helps.
I'd really like to know what is expected of us during the review
this is separate from the sha conversation. I'm usually reading the changelog added in the cover letter.
There was a problem hiding this comment.
Thanks, I got the same impression (latest tagged sha).
It's actually important to know what is expected of us to be reviewed. Without that discussion there is no guideline to merge this PR (I know we merged the other PRs already but here we already have some people to discuss it with, which is why I'd like to finish this discussion first).
There was a problem hiding this comment.
Yes, that's ok. I don't have any other review guideline suggestions to add. Most of coco repos have had dependabot enabled and it's been working well. Here we probably want to enable it for Go dependencies too.
|
Superseded by #443. |
dependabot
bot
deleted the
dependabot/github_actions/github/codeql-action-3.26.6
branch
Bumps github/codeql-action from 3.26.5 to 3.26.6.
Changelog
Sourced from github/codeql-action's changelog.
... (truncated)
Commits
4dd1613Merge pull request #2452 from github/update-v3.26.6-7233ec5e6dd9dd2dUpdate changelog for v3.26.67233ec5Merge pull request #2449 from github/update-bundle/codeql-bundle-v2.18.3a32c44dAdd changelog note2966897Update default bundle to codeql-bundle-v2.18.3b8efe4dMerge pull request #2435 from github/update-supported-enterprise-server-versionsab408a8Merge branch 'main' into update-supported-enterprise-server-versions864b979Merge pull request #2443 from github/dbartol/config-file-telemetryd36c7aaMerge pull request #2448 from github/dependabot/npm_and_yarn/npm-09b7c43f6bb3bf514Update checked-in dependenciesDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)