Introduction:
The adoption of containers grows, so does the need to ensure the integrity and authenticity of the software artifacts that make up these applications.
Beyond just the container images themselves, organizations are required to secure additional metadata files, such as Common Vulnerabilities and Exposure (CVE) scan results, Software Bill of Materials (SBOM), and Helm charts, that provide critical information about the components and dependencies of their containerized applications.
Ensuring the provenance and trustworthiness of these artifacts is essential for maintaining the overall security and compliance of the software supply chain.
In this blog post, we will explore how AWS Signer, a fully managed code-signing service, can be used to cryptographically sign and validate not only container images, but also the associated OCI (Open Container Initiative) artifacts that accompany them.
Open Container Initiative OCI:
The Open Container Initiative (OCI) is a lightweight, open governance structure (project), formed under the auspices of the Linux Foundation, for the express purpose of creating open industry standards around container formats and runtimes. The OCI was launched on June 22nd 2015 by Docker, CoreOS and other leaders in the container industry.
The OCI currently contains three specifications: the Runtime Specification (runtime-spec), the Image Specification (image-spec) and the Distribution Specification (distribution-spec). The Runtime Specification outlines how to run a “filesystem bundle” that is unpacked on disk.
AWS Signer:
AWS Signer is a fully managed signing service that simplifies the process of signing container images. It integrates seamlessly with ECR, allowing you to sign and verify images easily in your ECR repositories.
AWS Signer uses the Notary project, an open-source container image signing tool, to perform the signing and verification operations. Image signing involves creating a cryptographic signature using a private key and the image’s digest.
The signature is then attached to the image, and when the image is deployed, the signature is verified using the corresponding public key.
If the verification fails, it indicates that the image has been tampered with and should not be deployed.
Initially, developers fetch public images for initial testing and customization on their local machines.
Once prepared for building, they upload their build specification files to a shared code repository, such as AWS CodeCommit.
A modification in the shared repository triggers a pipeline via AWS CodeBuild. This pipeline utilizes the build specification files to construct and sign an image using** AWS Signer**.
Subsequently, the image is uploaded to an OCI-compliant image repository, such as Amazon Elastic Container Registry (Amazon ECR). Notably, AWS Signer, in conjunction with the underlying Notation CLI client, can be employed with any OCI 1.0 compatible registry.
Conclusion:
By integrating AWS Signer into your software development lifecycle, you can establish a robust and centralized solution for managing the signing and verification of your containerized applications and their supporting metadata, ensuring the trust and integrity of your software supply chain.
SOCIAL SHARE CARD GENERATOR