jizusun
commented
9 months ago I want to warn you. Publishing a Docker image and using it from a user repository is not acceptable from a security perspective. Imagine that I use this action in a closed company repository. Running an opaque container can be used to access closed source code and compromise it.
Community tools should be as transparent as possible from a security point of view. In this case, an opaque chain with the Docker image is added, which can fall under the control of an attacker.
Yes, I understand there is a risk in the software supply chain. But I'm wondering what's the other solution to solve the problem I mentioned in this issue https://github.com/reviewdog/action-detect-secrets/issues/54, that is the actions is slow to start.
This is why I didn't update the README in this PR.
If somebody want to skip the action build step ( 50s -> 9s), he can check the GHCR to use the prebuilt image after inspecting whole the built process (all available in open source, no hidden part) rather than build and push by himself, also just like here https://github.com/reviewdog/action-actionlint uses GHCR.
If somebody is still concerned about the integrity of the docker image, he just used the current way, that is, building the docker image when using the action.
Do you think it is okay for you to accept the PR , and I'll create a follow-up PR to resolve your concern?
My plan is
- Clarify the supply chain problem
- Warn the user the risk
- The current one as the recommend one, and the pre-built approach as an alternative one
- or just introduce image we built, like here https://github.com/philips-labs/slsa-provenance-action/tree/main?tab=readme-ov-file#docker-image
About the cosign
And with cosign I included after the image built, I did a Keyless signing of a container, and later can be verified, to improve the software supply chain security.
Sigstore is an open source project for improving software supply chain security. The Sigstore framework and tooling empowers software developers and consumers to securely sign and verify software artifacts such as release files, container images, binaries, software bills of materials (SBOMs), and more. Signatures are generated with ephemeral signing keys so there’s no need to manage keys. Signing events are recorded in a tamper-resistant public log so software developers can audit signing events.
Also I used the keyless signing since
keyless signing process, your username, organization name, repository name, and workflow name will be published to the Rekor public transparency log. This is the right choice for public repositories, but probably not for private repositories. And in fact GitHub has disabled this in private repositories by default to prevent potential leaks.
javierjulio
haya14busa
close #54