Registry Risks

Registry Risks

Gaining Visibility into NIST SP 800-190, Part Four


In my previous post (Part Three: Image Risks) I described how native AWS tools and third-party solutions can address image risks identified in section 3.1 of NIST SP 800-190 Application Container Security Guide. This post will dive into section 3.2 (Registry Risks) and 4.2 (Registry Countermeasures).


Optiv CI Pipeline Lab Image


3.2.1 Insecure connections to registries: The image registry is the location of image builds used in container deployments. Similar to communication with other sensitive data, connections to image registries should be maintained in a secure manner. These registries can contain sensitive information and should be treated as connecting to sensitive data. NIST provides the following guidance on risks and countermeasures:


3.2.1 Example Risks

  • HTTP access to private registries
  • Man-in-the-middle
  • Credential theft

4.2.1 Countermeasures

  • Connection to registries over encrypted channels




As described in the preceding blog post on Kubernetes Test Lab, these registries are located within each project of the GitLab server, which is an EC2 instance. The use of HTTPS access to project registries was defined on the GitLab server. However, security group inbound/outbound access restrictions to include only secure connections could be placed on the EC2 instance of the GitLab server as a way of mitigating some risk.


In terms of what AWS offers for connection logging to our registry, VPC flow logs provide some connection visibility but it isn’t perfect and takes some work to find. Below is the output of a CloudWatch search from VPC flow that was filtered based on the GitLab server and the port 4567, used for the registry. Unfortunately, it is difficult to discern if the connection was encrypted. The number 6 in the protocol only tells us that it was a TCP connection.




Prisma Cloud/Third-Party Tools


Prisma Cloud (formerly Twistlock) doesn’t have the ability to enforce registries to enable HTTPS communication. However, policies can be created within the product to prevent the pull of images from unknown registries.


3.2.2 Stale images in registries: Stale images are those that are old and potentially running out-of-date software. The hosting of stale images does not present immediate risk unless that image is used by a container. NIST provides the following guidance on risks and countermeasures:


3.2.2 Example Risks

  • Running out-of-date and potentially vulnerable software
  • Older images are at risk of newly discovered vulnerabilities

4.2.2 Countermeasures

  • Prune registries of unsafe or vulnerable images
  • Use of immutable names for version specification




AWS did not have visibility into the image registries for this project. Amazon Elastic Container Registry (ECR) was not used for this project.


Prisma Cloud


Prisma Cloud doesn’t report on stale images but would have the ability to prune images using the API integration.




Stale images can be found using the docker images command:


docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.ID}}\t{{.CreatedAt}}\t{{.Size}}"


Stale Images Docker Images Command


Use filters to prune images within Docker. As an example, the image below shows how to delete all images before 10-13-2019, about 30 days from when this image was taken.


docker image prune -a –force –filter “until=2019-10-13T00:00:00"


Prune Images within Docker


3.2.3 Insufficient authentication and authorization restrictions: Images within a registry may contain sensitive data. The lack of authentication or authorization restrictions to private registries could pose multiple risks to an organization. NIST provides the following guidance on risks and countermeasures:


3.2.3 Example Risks

  • Intellectual property loss due to unauthorized access
  • Images can be removed or replaced by malicious users leading to a wider compromise

4.2.3 Countermeasures

  • Connection to registries over encrypted channels



Our registries were located within each project on the GitLab server. Access to the registries are defined on the GitLab server, and authentication lockdown can be performed there. Above and beyond that, security group inbound/outbound access restrictions could be placed on the EC2 instance of the GitLab server as a way of mitigating some risk and only allowing needed groups.


Prisma Cloud


Prisma Cloud can integrate with an organization’s directory service, like Active Directory, to define policy around who can push to and pull from defined registries. The example policy below prevents all members in the PRS group from pushing images to the registry.


Create New Docker Rule


Hopefully this analysis proves helpful to security practitioners and others that are looking for methods to obtain visibility into registry risks. Stay tuned for the next blog post in this series, which will cover orchestrator risks and countermeasures.

Dan Kiraly
Senior Research Scientist | Optiv
Dan Kiraly is senior research scientist on Optiv’s R&D team. In this role he's responsible for use case development and the vetting of security products for Optiv.