Take control of your supply chain with Artifact Registry remote and virtual repositories

Dev: "I need that library's functionality for the new feature!"

    Sec: "I can't approve it if I don't know that it's safe to deploy!"

Dev: "And when will we know?"

    Sec: "My queue is 11 weeks long…."

The most contentious conversations between security and development teams often involve the topic of open source. Developers just want to get the job done and that often means downloading and using open source packages or containers from public repositories. But security professionals despair over the lack of visibility into what third-party material is being used in their enterprise and the provenance of that material. 

Security programs don’t have the staff to manually validate everything, but the organization needs governance over this process. How can developers be empowered to work at velocity while preventing harm? A breach costs money, can hurt customers and bring reputational damage to the organization.

Enter two features from Google Cloud Artifact Registry: remote repositories and virtual repositories

A component of Software Delivery Shield, the remote repository feature allows organizations to cache external artifacts from public sources such as Maven, Python, npm, and Docker. This capability offers two major benefits. 

First, by caching external packages in Artifact Registry, access is faster and more reliable, thereby reducing application delivery time and the risk of an unavailable public repository. More importantly, when combined with the virtual repository feature, it can act as a single point of reference for multiple upstream repositories, reducing the complexity in build configurations and preventing typosquatting, dependency confusion, and other similar open source attacks. 

As remote repositories have the advantage of being scanned for vulnerabilities along with local repositories when using Software Delivery Shield, you now have comprehensive insight over your third party artifacts. You can view this vulnerability data in the Cloud Console or access it via pub/sub subscription.

Reduce developers’ cognitive load to improve performance

According to cognitive load theory, we all have a limited capacity of working memory.  By leveraging these new Artifact Registry features, repository administrators can help ensure developers focus on what they really care about: building quality software. Developers no longer need to figure out how to find their packages or decide on the resolution order of public repositories because this information is already configured for them. 

Security professionals can find comfort in knowing that they have some control over the third party artifacts being used in their enterprise. Used with other features of Software Delivery Shield, such as vulnerability scanning, conforming to the standard for supply chain levels for software artifacts (SLSA) and build provenance, organizations are one step closer to achieving assurance over their software development lifecycle. 

How can you get started? 

Currently, remote and virtual repositories are supported in Public Preview with Maven, Python, npm, and Docker, with Linux and Go targeted for the future. 

Google Cloud Artifact Registry’s remote and virtual repositories are powerful tools that can help your organization take back control of the software supply chain. By caching external artifacts, reducing complexity, and providing visibility into third-party dependencies, organizations can accelerate software delivery while minimizing risk. Go ahead and add some assurance to your software development lifecycle with remote and virtual repositories.

You can take advantage of remote and virtual repositories by following these steps:

1. Enable and configure Artifact Registry. 

2. Configure automatic container and package scanning.

3. Create one or more upstream repositories. 

4. Create a remote repository, indicating the following options:

• The  format of the artifacts that you want to store

• The mode (remote)

• The location of the remote repository

5. If desired, create a virtual repository, specifying the following options: 

• The format of the artifacts that you want to store in the virtual repository

• The mode (virtual)

• The location of the virtual repository

• The permissions that you want to apply to the virtual repository