[Feedback] Latest version is impossible to audit its changes

[kuisathaverat]

The latest change contains the following PR without any description or any link to an issue that explains the massive changes in several JavaScript files. With a change like that, I cannot trust the latest version; I'm sure many people think as I do.

Updates anchore/sbom-action from 0.20.5 to 0.20.6

#536
c2c9a6d#diff-6b7a3c68cb4757330158ca54e180e8d26d818a568136bda75c88d29f57501f41

[kzantow]

Hi @kuisathaverat -- this is a dependency update. I've updated the PR description to reflect this. Dependencies are bundled using ncc and the resulting bundle is committed in the dist directory. This is typical for GitHub actions. The commit you've linked to is a minor version bump of the GitHub actions toolkit, which included a number of other dependencies, it seems. In fact the built bundle has been made smaller by almost 4,000 lines and you can fairly quickly scan through the changes to see them. I did this just now, and see nothing out of the ordinary, though I will admit reviewing multiple thousands of line PRs could easily be error prone. The dist bundle is also verified that a clean build produces the same contents so, barring unexpected code in a dependency, what is present in the dist files is what we expect to be there. Is there a particular concern you have?

[kuisathaverat]

I verified the dist results are the same, so it is fine. What scares me about the actions that use JavaScript and dist bundles is that there is no way to verify that the dist is the result of the bundle, other than launching the same command and confirming there is no diff, there is no checksum, signature, or any other thing that certifies that the unauditable dist is what should be. Anyway, it seems more of an issue with how GitHub designs these actions; it is really easy to inject code in those dist.

[kzantow]

@kuisathaverat I agree, having bundles is not ideal, but it's either this or committing the entire node_modules directory tree, which has its own set of problems. And, as I noted, our workflows do validate the bundle is not unexpectedly modified for every PR, so I think we are reasonably protected against arbitrary modification of these dist bundles. I'm not sure having a checksum helps a lot, since the entire contents are not obfuscated and are validated directly against incoming changes, but I'm definitely happy to do anything we can to improve transparency or trust of the action! Since there's no immediate action that I can see, I'm going to close this issue but again, happy for any suggestions you have. And thanks for using our actions! ❤️

[kuisathaverat]

Ideally, having a third-party checksum or signature generated by the CI when the bundle is created and stored in an immutable location, which the user can use to verify the bundle, significantly enhances trust.