GCP public images show how curation can reduce secret exposure

At a glance

What this is: Truffle Security’s analysis of public GCP images found zero exposed secrets across 8,437 processed images, suggesting that curated publishing rules can sharply reduce secret leakage.

Why it matters: IAM and NHI teams should treat image publication policy as a control boundary, because secret exposure in cloud images creates credential risk that spans workloads, pipelines, and service accounts.

By the numbers:

• That’s probably why we found 3 million public AMIs on AWS, and only 8,437 on GCP.
• In total, we gathered over 100 GB of files from 8,437 images.

👉 Read TruffleHog's analysis of secrets in public GCP images

Context

Public cloud images can carry inherited risk because they package configuration, authentication material, and application files that may be copied into new environments without review. In identity terms, that means a single exposed secret in an image can become an access path into workloads, APIs, and service accounts.

This research asks a narrower question than many secret-sprawl studies: whether a curated cloud image marketplace materially reduces the chance of secret exposure. For IAM and NHI governance, the relevance is not just image hygiene but the upstream controls that stop credentials from entering distributable artifacts in the first place.

Key questions

Q: What breaks when secrets are embedded in public cloud images?

A: When secrets are embedded in public images, the image itself becomes a credential distribution channel. Attackers can extract tokens, API keys, or certificates from the artefact and reuse them against cloud services, SaaS platforms, or CI/CD systems. The main failure is that publication multiplies exposure before any normal secret review or rotation process can intervene.

Q: Why do public image controls matter for NHI governance?

A: Public image controls matter because the exposed items are often non-human identities, not just incidental files. Service accounts, tokens, and certificates can be copied into artefacts and reused outside their intended lifecycle. If publication rules are weak, NHI governance loses visibility into where those credentials are distributed and who can obtain them.

Q: How do teams know whether image scanning is working?

A: Teams should measure whether scanning happens before publication, whether high-risk file types are consistently covered, and whether findings trigger immediate revocation and rotation. A healthy programme also tracks time to containment after discovery and the percentage of images blocked before release. If scanning only finds issues after distribution, it is too late to reduce exposure.

Q: Who is accountable when a public image leaks secrets?

A: Accountability should sit with the teams that own image build, approval, and publishing controls, not only with security operations after the fact. If an image contains secrets, the failure usually occurred earlier in the delivery chain. Frameworks such as NIST SP 800-53 and OWASP NHI both support shared responsibility for protecting credentials in artefacts.

Technical breakdown

Why public cloud images leak secrets in the first place

Public images are snapshots of configured systems, so they can contain .env files, SSH material, cloud credentials, database configs, and source fragments. Secret scanners find these exposures when the files are still present in mounted disks or extracted archives. The real issue is not the scanner, but the lifecycle gap that lets secrets survive build, packaging, and publication. When images are broadly publishable, the chance of a single overlooked file becoming a reusable credential increases sharply.

Practical implication: treat image publishing as a credential-control checkpoint, not just a delivery step.

Why curated marketplaces can reduce secret exposure

A curated marketplace narrows who can publish public images and can impose validation before distribution. That changes the threat model from open self-publication to approval-based release, which reduces the probability that a secret-laden image reaches consumers. It does not guarantee safety, because validation depth and publisher discipline vary, but it does create a stronger gate than open publishing models. This is a governance control, not a detection control.

Practical implication: align image approval policy with secret-scanning and publisher vetting before any image becomes public.

What zero findings really mean for secrets management

Zero secrets in a sample of public images does not prove the platform is inherently secure everywhere. It means the publication path in this dataset appears to have blocked obvious leakage. That still leaves private images, build pipelines, third-party templates, and downstream cloning workflows as potential exposure points. For identity teams, the lesson is that secret management must extend beyond repositories into artefacts that can be redistributed at scale.

Practical implication: extend secret-scanning to image pipelines, artifact stores, and release gates rather than relying on post-publication discovery.

Threat narrative

Attacker objective: The attacker wants reusable credentials that convert a published image into a foothold across the surrounding SaaS or cloud stack.

1. Entry occurs when a secret is embedded in a public image during build or packaging and later published for reuse.
2. Credential access follows when an attacker extracts the secret from the image and attempts reuse against cloud, SaaS, or CI/CD services.
3. Impact occurs when the reused credential grants access to workloads, APIs, or data stores beyond the original image boundary.

NHI Mgmt Group analysis

Curated publication is a control boundary, not just a distribution choice: This research suggests that restricting who can publish public images can materially reduce exposed credential risk. That matters because secret leakage is often introduced before the platform sees the image, not after. The governance lesson is that publication policy, validation, and approval workflow are part of secrets management, not just cloud hygiene.

Zero findings in public images should not be mistaken for zero risk in the image lifecycle: Public-image curation may suppress one exposure path, but private images, internal golden images, and build artefacts still inherit the same credential leakage problem. The failure mode is secret persistence across artefact reuse, where one leaked file becomes many deployed copies. Practitioners should treat image pipelines as an identity-adjacent control surface.

Secret exposure in images is fundamentally an NHI governance problem: The credentials at risk are often service accounts, API keys, tokens, or certificates that operate outside human login workflows. Once embedded in images, these non-human identities escape normal lifecycle controls such as review, rotation, and offboarding. That makes image scanning useful, but lifecycle prevention is the real control objective.

Image curation may lower prevalence, but it does not eliminate blast radius when controls fail: A platform can still publish a compromised artefact if validation misses an embedded secret or if a later change reintroduces one. The important concept here is artefact credential persistence, where credentials survive into distributable system images and outlive the review point. Practitioners should map that persistence to their release governance.

The broader market signal is that preventive control at publish time is becoming more valuable than reactive secret discovery alone: Organisations that rely only on scanning after artefacts are created will continue to chase leakage across repositories, registries, and image libraries. The stronger posture is to combine build-time prevention, publication approval, and downstream secret rotation. That should reshape how teams design cloud supply-chain governance.

What this signals

Artefact credential persistence: public image governance is now part of the secrets-management perimeter, because credentials that survive build and packaging can be redistributed faster than they can be reviewed. Teams should expect greater pressure to prove that release gates, not just scanners, are stopping exposure before publication.

The operational signal for practitioners is simple: if images are treated as software artefacts but secrets are managed as isolated files, the control model will stay fragmented. The stronger path is to bind release approval, scanning, and rotation into the same workflow, then map that workflow to NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 where credential exposure is concerned.

The broader governance implication is that curated publishing platforms can reduce exposure density, but they cannot replace lifecycle controls for service accounts and API keys. Organisations that want durable risk reduction need image policy, secret rotation, and downstream detection to move together, especially where workload identity is reused across environments.

For practitioners

• Gate public image publication on secret validation Block release of any public image until automated scanning confirms no credentials, tokens, or certificates exist in mounted files, archives, or inherited config paths. Make approval a required step in the image promotion workflow.
• Extend secret scanning into the image lifecycle Scan golden images, marketplace images, and internal templates at build time and again before distribution. Include hidden paths such as .env, .ssh, web.config, and backup files that are often missed by repository-only checks.
• Rotate any credential ever found in an image If a secret is discovered in a public or internal image, revoke and rotate it immediately, then search for the same value across logs, backups, and artifact stores to confirm it was not copied elsewhere.
• Treat image publishing as a secrets-management control Assign ownership for image publication policy to the same governance process that manages service-account secrets and API keys. That prevents platform teams from treating public distribution as a purely operational decision.

Key takeaways

• Public cloud images can become credential carriers when build and packaging controls fail, which makes publication policy part of secrets governance.
• Truffle Security’s scan of 8,437 public GCP images found zero exposed secrets, showing that curated publishing can materially change exposure outcomes.
• Teams should combine pre-publication scanning, approval gates, and rapid rotation so that artefact-level controls reduce blast radius before exposure spreads.

Key terms

• Public Cloud Image: A public cloud image is a reusable system snapshot published for others to deploy. It can contain operating system files, application settings, and embedded credentials, which means the image itself becomes a potential security boundary if release controls are weak.
• Artefact Credential Persistence: Artefact credential persistence is the condition where secrets survive inside build outputs, images, or packages after they should have been removed. It matters because a leaked secret can be copied many times through distribution channels, multiplying the reach of a single mistake.
• Secrets Management System: A secrets management system is the control layer used to store, distribute, rotate, and revoke credentials such as tokens, API keys, and certificates. In practice it reduces reliance on manual handling and helps prevent secrets from being embedded in code, images, or shared files.

What's in the full report

TruffleHog's full post covers the operational detail this post intentionally leaves for the source:

• The exact file discovery and mounting workflow used to extract candidate secret-bearing files from public images.
• The per-image processing methodology for handling filesystem types, cleanup, and scan execution at scale.
• The full technology and file-extension breakdown observed across the 8,437 processed images.
• The research limitations around paid marketplace images and why that matters for future secret discovery work.

👉 TruffleHog's full post covers the scan method, file types, and limitations behind the zero-secret result.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners who need to operationalise lifecycle controls. It helps security teams connect identity risk to the controls that govern service accounts, tokens, and certificates.