Skip to content
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

CI: hash-pin sensitive workflows and use a Dependency-Update-Tool to update them #328

Closed
diogoteles08 opened this issue Dec 29, 2023 · 0 comments

Comments

@diogoteles08
Copy link
Contributor

Hi, I'm Diogo and I'm back (see #247 and #269). At the issue #247 I suggested you to set minimal permissions to your workflows. Now I'm coming back to suggest a modification that would provide extra safety for the workflows that yet require dangerous permissions (e.g., contents: write).

Problem

Your workflow bzlmod-archive.yml is using dangerous permissions and secrets while running external dependencies pinned only by tag. Those patterns could be dangerous because if any of those actions get hijacked (and at the end they're all repositories and are susceptible to attacks like any other), an attacker could change the code that your tags point to, gaining access to your secrets and/or write permissions to your repository.

Proposed Solution

A simple solution for this problem would be to hash-pin those sensitive actions, pointing the actions to the very specific commit of that release. It follows an example of the change:

- uses: r-lib/actions/pr-fetch@v1 
would become
- uses: r-lib/actions/pr-fetch@11a22a908006c25fe054c4ef0ac0436b1de3edbe # v1.3.1

And this would enforce that your action is always running at the expected code.

The only downsize of this solution is that it gets trickier to manually update the version of the actions as they get out-of-date, but that can be solved by using a Dependency-Update-Tool (like dependabot or renovatebot). That tool would also be useful to update the dependencies that don't need to be hashed. We can configure it to update all workflow dependencies in a single monthly PR, for example -- for security updates, the tool would immediately create the PRs regardless of the frequency set. For the case of the hash-pinning, the PRs would still keep a comment with the human-readable version used =).

Conclusion

I'll take the liberty of raising a PR implementing my suggestions, so that it becomes easier for you to evaluate. Let me know if you have any questions or concerns.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants