Overview of the Acquire stage

Acquisition of external container images to use as base or utility images is the first stage of the supply chain for containers. Enterprises may lack the expertise or resources to build every piece of software from source and need to rely on external sources for container images. Examples of such images are operating system or framework images, service proxies like NGINX and Envoy, or logging and metrics images like Fluentd and Kafka. It is important to establish certain quality checks before use and ensure that such images comply with the enterprise policies.

Microsoft’s Containers Secure Supply Chain (CSSC) framework identifies the need for acquisition of external images. The CSSC framework recommends a set of standard practices and tools to help you securely acquire the external container images for internal use. In this article, you’ll learn about the objectives, standard practices, and tools that you can use in the Acquire stage of the CSSC framework.

Background

Currently, enterprises don’t have an established process for the acquisition of external container images. Approaches vary widely depending on the enterprise’s size and expertise.

Security-focused enterprises bring pre-approved images from external sources, such as Docker Hub, into an internal quarantine registry. These images are inspected for vulnerabilities and malware before they are released for internal use. However, this process is not uniform or completely automated. Enterprises also lack a method to guarantee the authenticity and integrity of these images throughout the supply chain. Finally, they don’t have a consistent way to enrich the images with extra metadata for subsequent stages of the supply chain.

Enterprises starting their security journey use container images from external registries directly in their build and deployment scripts. This approach can introduce vulnerabilities, malware, and noncompliant software compromising the availability of image builds and containerized services.

The Acquire stage of the CSSC framework recommends a set of steps and security controls that should be implemented to ensure that the external images are validated and compliant with the enterprise policies before they are used internally.

Recommended practices

Microsoft recommends building software from source whenever possible. In case enterprises are not able to do that, we recommend the following practices for acquisition of external container images and cloud native artifacts.

• Import external images into an internal registry that is under the enterprise's control to remove the dependency on third parties and reduce the impact on availability. You should import images only from reputable sources.
• When available, verify signatures of the external images to ensure publisher's authenticity and image integrity during the import process.
• Before allowing for internal use, scan container images for vulnerabilities and malware to reduce the risk of introducing security flaws.
• Enrich container images with additional metadata like SBOMs, provenance and lifecycle to enable policies in subsequent stages of the software supply chain.
• Sign container images and relevant metadata with enterprise keys to ensure integrity and provide trusted stamp of approval for internal use.

Microsoft's CSSC framework guidance also matches the guidance to secure materials in CNCF Software Supply Chain Best Practices.

Workflow for acquisition of external images

Despite the trust enterprises put into vendors or open-source projects, they should always validate the software they acquire from external sources. Container images and cloud-native artifacts are no exception. The CSSC framework recommends the following workflow for acquisition of external images.

1. Import container images and cloud-native artifacts into an internal registry under enterprise control.
2. Quarantine the images in the internal registry to prevent them from being used internally until they are validated.
3. Validate any signatures associated with the image to ensure the authenticity and integrity of the image, if signatures are present in the external registry.
4. Validate any other metadata associated with the image including SBOMs and provenance to prevent violation of enterprise policies like non-compliant licenses, if additional metadata is present in the external registry.
5. Scan the images for known vulnerabilities and malware to prevent introduction of security flaws.
6. Attach the vulnerability and malware reports as image attestations to use in subsequent stages of the supply chain.
7. If not available, generate SBOM and provenance for the image and attach them as image attestations to use in subsequent stages of the supply chain.
8. Enrich the images with additional metadata like lifecycle metadata to use in subsequent stages of the supply chain.
9. Sign the image and relevant metadata with enterprise keys to ensure integrity and provide trusted stamp of approval for internal use.
10. If the image meets the internal policies, publish the image to the golden registry for internal use.

Security goals in the Acquire stage

Having a well-defined workflow for the acquisition of external images helps enterprises increase their security and reduce the attack surface on their supply chain for containers. The Acquire stage of the CSSC framework is intended to satisfy the following security goals.

Reduce attack surface due to external dependencies

Public registries are susceptible to various types of attacks due to their open nature and the lack of stringent security measures. Allowing users within the enterprise to directly pull images from external registries exposes them to attacks like dependency confusion and typosquatting.

The Acquire stage in the CSSC framework addresses this risk by centralizing the acquisition and management of external artifacts and offering the internal users a single source of truth for all images and cloud-native artifacts.

Minimize the risk of introducing security flaws

The lack of strict verification and approval processes for images in the public registries means that anyone can push images without rigorous scrutiny. This increases the risk of inadvertently using compromised images that can introduce security vulnerabilities into enterprise applications.

The Acquire stage addresses this risk by adding a required step for vulnerability and malware scanning of the images before they are approved for internal use. Another added benefit of importing the images to an internal registry, these images can now be scanned and patched on a regular basis.

Increase availability of container builds and deployments

Due to the need to distribute container images on a global scale, public registries are susceptible to throttling. Public registries are also targets of DDoS attacks that can impact image distribution. Lastly, public registries are hosted on infrastructure that is not under enterprise control and can be impacted by outages. All this can cause delays or failures in enterprise builds and deployments.

By importing images from external registries into an internal registry, the Acquire stage addresses this risk by removing the dependency on external registries and allowing enterprises to control the rate at which they pull images from internal registries. Private registries can also be better protected from external attacks and comply with enterprise availability requirements.

Control the lifecycle of external images

Software publishers can update images in external registries without notice. This can cause unexpected changes in enterprise builds and deployments. Also, images can be removed from external registries without notice, which can cause enterprise builds and deployments to fail.

By introducing an intermediate registry to host the external images, the Acquire stage addresses this risk by offering cached versions of the images needed for internal use. This allows enterprises to control the lifecycle of the images and ensure that they are retired according to the enterprise policies.

Ensure a minimum image quality

While some publishers of external images start to include attestations like SBOMs and provenance as well as sign container images, many images in the public registries do not have such attestations. This is also because certain public registries do not support such capabilities. This makes it difficult for enterprises to ensure that the images they acquire are compliant with their policies.

In the Acquire stage of the CSSC framework, enterprises can enrich the images with additional metadata including SBOMs, provenance, lifecycle, and other internal metadata that meets their policies. They can also sign the artifacts with enterprise keys to ensure integrity and provide a trusted stamp of approval for internal use.

Recommended tools

Microsoft offers a set of tools and services that can help enterprises implement the recommended steps in the Acquire stage workflow and address the security goals listed above.

Tools and services for importing external images

Azure Container Registry (ACR) is a managed, OCI-compliant registry that supports the distribution of container images and other cloud-native artifacts. ACR is compliant with the latest OCI specifications and can be used to store supply chain artifacts.

ACR Import capability can be used to import images from external registries into ACR. The import preserves the image digest and tags and allows you to import images from any public and private registry that supports the Docker Registry V2 API.

ORAS is a CNCF project backed by Microsoft that offers an open-source CLI and libraries to interact with OCI registries. ORAS can also be used to copy images and other OCI artifacts from external registries into ACR.

Tools and services for validating external images

ACR Tasks is a suite of features in Azure Container Registry that allows enterprises to automate different tasks like vulnerability scanning or SBOM or signature validation. ACR Tasks can be used to validate external images once they are imported into Azure Container Registry. ACR Tasks can also be used to automate the import of images from external registries into Azure Container Registry.

Microsoft Defender for Cloud is the cloud-native solution to improve, monitor, and maintain the security of your containerized workloads. Microsoft Defender for Cloud offers vulnerability assessment and management tools for images stored in Azure Container Registry.

Tools for enriching external images with enterprise metadata

As a versatile tool to interact with OCI registries, ORAS can also be used to add annotations and attach metadata to a container image. ORAS can be used to add SBOMs, provenance, lifecycle and other metadata to enrich the images for subsequent stages in the supply chain.

Microsoft's SBOM Tool is an open-source, highly scalable, and enterprise-ready tool to create SPDX 2.2 compatible SBOMs for any variety of artifacts. SBOM Tool can be used to generate detailed SBOMs for container images.

Notary Project is a Microsoft-backed CNCF project that develops specifications and tooling for signing and verifying software artifacts. Notary Project's notation tool can be used to sign container images and other cloud-native artifacts with enterprise keys.

Next steps

See overview of the Catalog stage for securely hosting container images for internal use.