I Didn't Register for This: What's Really in Google's Artifact Registry?

I Didn't Register for This: What's Really in Google's Artifact Registry?

Speakers: Moshe Bernstein

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=hHe9cKfSfqI

Overview

Moshe Bernstein, a cloud vulnerability researcher at Tenable Cloud Security, presented the results of a large-scale security audit of container images hosted on Google's Artifact Registry. The central question was deceptively simple: are container images uploaded by Google to their own platform -- a platform with built-in security features -- actually secure? The answer, backed by scanning over 3,000 images across 32 repositories, was a resounding no. Bernstein's research uncovered approximately 1.7 million vulnerabilities and nearly 3,000 embedded secrets, raising hard questions about the shared responsibility model, supply chain trust, and the gap between platform security features and their actual adoption.

This was Bernstein's first speaking engagement at a security conference, but the depth and methodical nature of the research belied that fact. The findings are directly relevant to anyone operating on GCP, consuming images from Google Cloud Marketplace, or relying on Google-managed services that deploy containers into customer environments.

Background

▶ Watch: How scanning Google Composer 3 led to the Artifact Registry research (1:30)

Artifact Registry is Google Cloud's successor to Container Registry, designed as a comprehensive package and container image management solution with built-in CI/CD integration and security scanning capabilities. The research originated during an unrelated investigation into Google Composer 3, a managed Apache Airflow service that runs in Google's own tenant projects. While examining Kubernetes configuration files in Composer 3, Bernstein discovered an image hosted on Artifact Registry that bore organizational tags traceable to Google's own organizational ID (starting with 433), confirming it was a production image deployed by Google into their own cloud environments.

This initial discovery triggered a broader investigation. Bernstein attempted to enumerate additional images within the same project but was blocked by missing artifactregistry.repositories.list permissions. However, he identified a permission discrepancy between Artifact Registry's native domain (docker.pkg.dev) and the legacy gcr.io domain. Google had created gcr.io repositories within Artifact Registry as a migration convenience, and these repositories had more permissive listing capabilities than their native counterparts. This discrepancy allowed Bernstein to discover significantly more images than the access controls intended to expose.

Key Findings

▶ Watch: Permission discrepancy between gcr.io and docker.pkg.dev domains (5:30)

Bernstein classified the discovered images into three categories based on their relationship to Google and users. Vetted images (approximately 70% of the total) are third-party images curated by Google and hosted on Google Cloud Marketplace. Offered images are base or utility images created by Google for user convenience, such as operating system images or AI training containers. Used images are containers created by Google for deployment in their own production environments, such as those powering Cloud Composer.

Across the 3,000+ scanned images from 32 repositories, the research found approximately 1.7 million total vulnerabilities, with 350,000 unique CVEs. Filtering to just high and critical severity, there were still 380,000 total and 70,000 unique vulnerabilities. These were not obscure edge cases -- the scan identified images containing Log4Shell, ZeroLogon, and Spring4Shell, some of the most infamous and easily exploitable vulnerabilities in recent memory.

On the secrets front, nearly 3,000 secrets were extracted, predominantly from the vetted (Marketplace) category. These included cloud credentials for all three major providers (AWS, Azure, GCP), OpenAI API keys, Docker configurations, Git private access tokens, Jira tokens, and in one particularly egregious case, hard-coded administrator credentials (username and password) alongside API keys for OpenAI, AWS, Azure, and Jira -- all in a single configuration file.

In a delicious piece of irony, one Cloud Marketplace image that contained 24 critical vulnerabilities, nine of which could lead to remote code execution, was created by a company whose product scans container images for vulnerabilities.

Technical Deep Dive

▶ Watch: 1.7 million vulnerabilities found across 3,000 images including Log4Shell (10:00)

The image discovery pipeline consisted of four stages. First, potential images were discovered through scanning personal cloud environments, Google searches, or open-source code repositories. Second, each image was verified as Google-owned by checking organizational tags -- specifically the GCP environment and GCP product labels that traced back to Google's organizational ID. Third, additional images within the same project were discovered using the gcr.io permission discrepancy bypass, which allowed listing images through the legacy domain even when the artifact registry domain blocked repository enumeration. Fourth, all discovered images were systematically scanned for vulnerabilities and secrets.

The vulnerability scanning focused on the latest available tag for each image, meaning the findings represent the current state of these images rather than historical debt. The secrets analysis leveraged standard container image layer inspection techniques to extract embedded credentials from configuration files, environment variables, and application code baked into the images.

The permission discrepancy itself is notable: Artifact Registry stores non-gcr.io images in individual repositories (requiring repository-level list permissions to discover), while gcr.io images are consolidated into a single gcr.io repository within the project. Having access to list images within one repository (the gcr.io one) effectively exposed all images migrated from the legacy Container Registry, bypassing the intended per-repository access controls.

Demo / Proof of Concept

▶ Watch: Secrets discovery: API keys, cloud creds, and hard-coded admin passwords (12:00)

No live exploit demo was performed. The presentation focused on the scanning results and specific examples of vulnerable and secret-laden images, including detailed screenshots of configuration files containing multiple credential types and vulnerability scan outputs showing critical CVE counts.

Defensive Implications

▶ Watch: Defensive recommendations and final takeaways (16:00)

The findings have direct implications for multiple audiences. For Cloud Marketplace partners and third-party developers, the message is unambiguous: scan images for vulnerabilities and secrets before uploading, implement continuous scanning as part of the software development lifecycle, and never embed credentials in container images. For GCP users consuming Marketplace images, the takeaway is that Google's curation process does not guarantee security -- organizations must run their own vulnerability scans on any images they deploy, including those from trusted sources.

Google's own Artifact Analysis vulnerability scanning tool is built into the platform, making the absence of its use on Google's own hosted images particularly ironic. Organizations should enable and enforce this scanning for all images in their registries.

The shared responsibility model is exposed as having a significant gray area: Google's documentation simultaneously states that partner products "must not include known vulnerabilities" and that Google reviews submitted VM images for vulnerabilities. When two parties share responsibility for the same security control without clear accountability, the result, as demonstrated here, is that neither party effectively executes it.

Bernstein expressed hope that Google would implement a deadline-based remediation model similar to Google Play's approach for Android applications, where apps with unpatched security issues are removed from the store.

Key Takeaways

• Over 3,000 Google-hosted container images on Artifact Registry contained 1.7 million vulnerabilities and nearly 3,000 secrets, including credentials for AWS, Azure, GCP, and hard-coded admin passwords
• A permission discrepancy between gcr.io and docker.pkg.dev domains allowed enumeration of images that should have been hidden by access controls
• Log4Shell, ZeroLogon, and Spring4Shell were found on multiple images uploaded by Google to their own platform, demonstrating that even trivially patchable vulnerabilities persist in trusted registries
• The shared responsibility model fails when both platform provider and third-party developer assume the other is handling security -- the gap between Google's documentation and reality was significant
• Never assume trust based on provenance alone -- images hosted by Google on Google's platform are not inherently secure
• Cloud Marketplace partners should treat image security as a continuous process, not a one-time upload-and-forget task

About the Speaker(s)

Moshe Bernstein is a cloud vulnerability researcher at Tenable Cloud Security with close to a decade of experience in cybersecurity across web vulnerability research, cloud security, and networking. This was his first speaking engagement at a security conference. Outside of work, he is an enthusiast of table tennis and Super Smash Bros.