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
Recommend pinning to commit SHA or release tag #265
Comments
Hi @joebowbeer, thanks for the issue report! Could you expand on what value you'd like to gain with a GitHub Action over the existing bash approach? The workflow to run I could also use some clarification on how you'd like to update the documentation. Notably, in the docs, I do recommend using On the other hand, itmake sense is to strictly pin our dependencies. While I've personally vetted every line of code of the distributed JS of our dependencies for the versions that we depend on, they aren't pinned (they use |
I think GitHub Actions provides a better onboarding experience. In the future, GitHub may differentiate code scanning actions from others, providing further benefits, but this may be wishful thinking. In addition, npx is susceptible to typosquatting. I do see an instance or two of a tag in the README, now that you mention it, but I didn't see any security-related justification, and there are many instances without, including the one I was interested in: https://github.com/IBM/audit-ci#github-actions I used to trust repos, especially ones that were created to tighten security, but now I prefer trusting as little as possible (zero trust). Pinning all dependencies would be great. This is an advantage of installing audit as a dev dependency, because in that case its deps are locked and it can check its own deps for recently-reported threats. But that has other issues as you point out. |
You are absolutely right about missing pinning. I've updated all documented references for
Fair! Open to improvements in this area.
Yeah, I can appreciate that as well. Typosquatting can only really be prevented with the usage of an SHA, as you mentioned. Reasonable to consider documenting that tbh, have to think about that a bit more and find a convenient way to provide that SHA as documentation. Open to ideas!
Agreed 👍🏻
I've already pinned the "less common" dependencies, but definitely am considering pinning all dependencies. I'd also consider finding a way to pin transitive dependencies. They were originally not pinned to support deduplication when performing |
To protect against latest version incompatibility and potential supply chain attack (e.g. codecov), please recommend pinning to a commit SHA, or at least a release tag.
Also, consider packaging this in a GitHub Action.
https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions
The text was updated successfully, but these errors were encountered: