Notifications
Clear all
Topic starter
11/07/2026 8:24 pm
TL;DR: Scanning 8,437 public GCP images, Truffle Security’s research found zero exposed secrets, a sharp contrast with the hundreds of live secrets previously identified in AWS AMIs and the fewer but still material findings in Azure public images. Curated publication controls can materially reduce secret exposure, but they do not replace secrets governance across the rest of the cloud estate.
NHIMG editorial — based on content published by TruffleHog: Guest Post, GCP CloudQuarry: Searching for Secrets in Public GCP Images
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Extend secret scanning into the image lifecycle Scan golden images, marketplace images, and internal templates at build time and again before distribution.
- 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.
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.
👉 Read TruffleHog's analysis of secrets in public GCP images →
GCP public images and secret exposure: what IAM teams should note?
Explore further
11/07/2026 8:54 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: GCP public images show how curation can reduce secret exposure
