You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.
As a security engineer, I want to ensure that the containers I deploy into my environment include high-quality software. That software includes dependencies of the app destined to run within a container. I'd also like to implement signature verification into my container import workflow so that I can attest to the provenance of my container ecosystem. Without assurance that the containers that I run are the same ones which were imported from upstream, I may find myself at risk in the future.
Describe the solution you'd like
I would like to implement the following:
New container release workflow which signs Atlantis images when they are built and provides the signatures to downstream users for verification.
SBOM generation workflow which produces a CycloneDX formatted bill of materials for each new image version.
Describe the drawbacks of your solution
Image attestation is hard. One needs to maintain a private key, which increases the level of trust placed in project maintainers. Project maintenance cost may be slightly increased given that the signature workflow will require additional Actions minutes.
Describe alternatives you've considered
We considered signing our own copy of Atlantis but signing containers without doing anything else is pointless. Part of the supply chain security manifesto, if you can call it that, involves attesting to the quality and safety of the software within an image - not just the provenance of the image. That doesn't just mean the software that the image is intended to run. It means that software, its dependencies, and those dependencies’ transient dependencies. Since we don't fork Atlantis we don't gain anything by signing a copy of it.
The text was updated successfully, but these errors were encountered:
Community Note
Describe the user story
As a security engineer, I want to ensure that the containers I deploy into my environment include high-quality software. That software includes dependencies of the app destined to run within a container. I'd also like to implement signature verification into my container import workflow so that I can attest to the provenance of my container ecosystem. Without assurance that the containers that I run are the same ones which were imported from upstream, I may find myself at risk in the future.
Describe the solution you'd like
I would like to implement the following:
Describe the drawbacks of your solution
Image attestation is hard. One needs to maintain a private key, which increases the level of trust placed in project maintainers. Project maintenance cost may be slightly increased given that the signature workflow will require additional Actions minutes.
Describe alternatives you've considered
We considered signing our own copy of Atlantis but signing containers without doing anything else is pointless. Part of the supply chain security manifesto, if you can call it that, involves attesting to the quality and safety of the software within an image - not just the provenance of the image. That doesn't just mean the software that the image is intended to run. It means that software, its dependencies, and those dependencies’ transient dependencies. Since we don't fork Atlantis we don't gain anything by signing a copy of it.
The text was updated successfully, but these errors were encountered: