Registry Scanning: Top 5 Risks and 3 Steps to a Secure Registry

What Is a Container Registry?

A container registry is a resource that allows you to store and catalog container images, which serve as ‘templates’ for container workloads that get deployed in cloud environments. Container images can be ‘pushed’ and ‘pulled’ to and from registries as part of DevOps workflows or continuous integration/continuous deployment (CI/CD) pipelines. 

Container registries are a key component of DevOps pipelines, useful resources for container orchestration engines such as Kubernetes, and a vital endpoint for container-based development. They help to centralize the management of container images and establish a single source of truth for container workloads. 

There are two main types of container registries:

• Public registries—a public registry is a hosted resource that allows for image storage and sharing. Some public registries, such as Docker Hub, include ‘official images’ that are vetted and verified by the registry vendor, and open source images created by third parties. Public registries often provide free and paid subscription options.
• Private registries—a private registry can be an on-prem resource, or a hosted resource that is managed by a vendor that grants you restricted access, controlled sharing, and exclusive use of container images. Often, private registries provide extended security features.

This is part of our series of articles about Docker containers.

In this article:

• Why Is Container Registry Scanning Important? Top 5 Risks
• Ensuring Safety of Public Images
• Securing the Development Lifecycle
• Discovering Outdated Packages and Libraries
• Avoiding Exposed Secrets
• Protecting Against Malware and Software Supply Chain Risks
• 3 Steps to Container Registry Security
• Unique Checksum Referencing
• Registry Security Auditing
• Limit User Privileges
• Registry Scanning with Aqua Security

Why Is Container Registry Scanning Important? Top 5 Risks

While container images should be scanned for vulnerabilities early, and consistently, throughout the development process, this approach does not address all potential security risks that may arise after an image is checked into the registry. 

An important best practice is to regularly scan the images in a container registry, to identify newly published vulnerabilities affecting previously scanned images, or to detect malicious artifacts that may have entered the registry via the software supply chain. 

Many public registries offer basic vulnerability scanning features, while private registries often allow organizations to use integrated third-party scanning services. Such services may include integrated features for blocking promotion or deployment of untrusted images, identifying possible policy non-compliance, and generating alerts to new vulnerabilities or changes in security status. 

Related content: Read our guides about:

• Container image repository
• Docker registry – Docker’s open source private repository tool

Here are a few reasons why container registry scanning is critical to the security of your containerized applications.

1. Ensuring Safety of Public Images

Images stored in public registries are often not assessed for malicious packages that may compromise systems when deployed. It is possible to mitigate this threat by using only trusted sources or ‘official’ images from registry vendors (such as Docker official images). It is important to note that even trusted and official images may still contain vulnerabilities that could be exploited as an attack vector. 

To address this risk, a container registry may integrate with vulnerability management tools to analyze your images, helping to identify known vulnerabilities in scanned images, including those from public registries, official images, and trusted sources. Proper integration can enable automated scanning to ensure continuous risk visibility.

2. Securing the Development Lifecycle

Automation in DevOps workflows and CI/CD pipelines can accelerate software development, but can also propagate attacks. Insecure registry configurations or over-provisioned access rights can make it possible for malicious or unvetted images to enter registries and be deployed into production. Similarly, previously secure or benign images could become vulnerable or malicious at any point after being checked into the registry.

Many security tools can monitor registries to ensure that no unauthorized or insecure images are added to the registry and that there are no unauthorized version updates to existing images.

3. Discovering Outdated Packages and Libraries

A container image is immutable—you cannot change it once it is built without creating a new image version. As a result, some packages, libraries, and dependencies become obsolete or unsupported over time. Because new vulnerabilities may be discovered affecting these outdated packages and libraries, you may accrue technical debt and become responsible for their maintenance and patching. 

Integrating an image scanner into your CI/CD pipeline can help you identify outdated and at-risk packages and fix these issues before images are deployed, even if images enter the registry outside of standard workflows. 

4. Avoiding Exposed Secrets

Secrets contain sensitive information, such as tokens, passwords, private key files, and access keys. Attackers often target secrets because the information can help them perform other malicious acts. For example, attackers can use malicious scripts to leverage stolen credentials or device resources for advanced multi-layer attacks. Images may contain such secrets and sensitive data and increase an organization’s risk exposure. 

Scanning registries for secrets ensures that corrective measures can be made to remove the information from a new image version, protecting it from proliferation outside secured environments.

5. Protecting Against Malware and Software Supply Chain Risks

A container image can hide malicious scripts or malware that enables threat actors to launch sophisticated attacks using previously trusted third-party artifacts as an attack vector. This type of attack only manifests at runtime and can evade static, pattern-based, or signature-based scanners. 

Some security solutions can address this risk by running images in a secure hosted sandbox environment and analyzing the attack kill chain. These tools are often integrated into CI/CD pipelines to analyze images in a running state before and after the image is checked into a registry. Malicious activity and failed policy conditions can flag the image for removal from the registry or block check-in altogether.

3 Steps to Container Registry Security

Here are two major security risks related to container registries and the images they store: 

• Container images can include vulnerabilities—developers frequently upload new containers or new versions of containers to the registry. If one container image has a vulnerability, then all the containers generated from that image will have that vulnerability. This can be particularly difficult to manage when images are checked into the registry manually or outside of traditional processes with established security gates.
• Container registries can become attack vectors—automated workflows allow faster operations for developers and DevOps teams pushing images through pipelines frequently. Unless security is consistently enforced throughout these workflows, registries can become attack vectors. For example, images can be automatically replaced with potentially vulnerable new versions, and a build or runtime process can call for the latest version of an image that has hidden malware or that has been spoofed to trick developers.

Related content: Read our guide to container images ›

Here are a few ways to improve the security of your container registries.

1. Unique Checksum Referencing

Each container image has a manifest. A manifest is a description of the image in JSON format, which contains details about the image. These details are, for example, tags and instructions on configuring the container for different host platforms. 

A container image’s digest is a SHA-256 hash of its manifest. This digest ensures that each image has a unique reference. This way, if a cybercriminal tampers with your image, the digest changes and tampering can be detected.

Pulling images by digest, guarantees an identical version of the image, avoiding potential security problems. 

2. Registry Security Auditing

If technology doesn’t evolve in software development, it is likely to age poorly. This happens with container images and any other development resource. Because images are immutable, an outdated container image might continue producing outdated container instances. 

This process can cause older vulnerabilities, for which patches already exist, to persist in your application until you update the container images that contain them.  

A registry should have a way to audit container images for known vulnerabilities and outdated code that may require updates or patching. 

3. Limit User Privileges

It is important to maintain granular permissions for users who contribute to, or require access to, a container registry. Follow the least privilege principle and ensure that developers only have access to the container images and the operations they need for their projects. 

For example, a developer or team who consumes certain container images within their pipeline, but never writes updates to those images, should not have write access to that part of the registry. Similarly, DevOps tools and pipelines should have controlled permissions and automated checks to verify the integrity of change requests to ensure that a compromised asset with permissions does not proliferate an attack.

Organizations should prefer registries with a strong, granular access structure, define roles carefully, and ensure they review access regularly to revoke access from teams, tools, or contributors who are no longer associated with a project. 

Pay special attention to third-party access to container registries, because third parties can represent a major risk to image integrity, security, and the CI/CD pipeline in general.

Registry Scanning with Aqua Security

Aqua Security provides enterprise-class container image security capabilities for organizations making the shift to cloud native application development. Automate image scanning across CI/CD pipelines to establish policy-based security gates, including analysis before images are checked into registries. Integrate Aqua image scanning with container image registries to support immutability and ensure that container registries do not become tools of a supply chain attack.

For more information on how organizations secure container registries with Aqua, check out the case study about how Thoughtworks manages cloud security and container vulnerabilities ›