feat: exclude missing workflow permissions #10
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
This repo contains a custom codeql config which is used by some repos in their workflows.
We note that there are many CodeQL alerts generated due to 'Workflow does not contain permission'.
This rule is generally a best practice, rather than a currently exploitable vulnerability, since it requires an attacker to get an access token from a workflow created before February 2023, two prerequisites that are quite hard to achieve.
To get this access token, the attacker needs to get access to the pipeline, but by then, there are far bigger concerns e.g. leaking GH secrets.
The only other scenario is where the access token is accidentally leaked to the attacker, which is possible by supply chain attacks or somehow accidentally bundling it into the build artifact.
The probability of such a scenario seems quite slim, especially now that we enforce Github Action pinning, so it would have to be through build scripts and deps.
FYI, there are 77/613 active repos with workflows that created before February 2023.
Approach
This PR adjusts the CodeQL config to exclude the rule
actions/missing-workflow-permissions
Risks
We risk the scenario where the access token is accidentally leaked to an attacker, where he will then be able to write to the repo, possibly including dumping the repo's secrets and org's secrets, or initiating a supply chain attack internally.