AWS S3 Bucket Security: Find the Secrets Hiding Outside Git

S3 buckets have quietly become a credential blind spot: years of logs, backups, and pipeline output that nobody ever scans for secrets. In one 2025 incident (Sysdig), attackers reached admin access in eight minutes using IAM keys found in a public bucket.

TL;DR

• The Blind Spot: S3 buckets accumulate years of logs, backups, and pipeline output that never get scanned for secrets, and 28% of incidents now originate entirely outside code repositories.
• The Attack Speed: Attackers used IAM credentials found in a public S3 bucket to reach admin access in just eight minutes, with AI accelerating the reconnaissance.
• The New Coverage: GitGuardian now scans AWS S3 buckets, including supported ZIP and tar.gz archives, for exposed credentials and routes findings into existing incident workflows.

AWS S3 bucket security usually starts with the infrastructure around the bucket. Teams spend enormous effort blocking public access, encrypting data, and monitoring cloud activity. Good cloud security is essential, as S3 buckets end up holding a lot of valuable stuff.

Organizations, as they have shifted to become more cloud native, have spent years piling logs, backups, and pipeline output into Amazon S3. Snapshots and infrastructure artifacts accumulate there too. Much of that data never passed through any kind of secret scanning. It is anyone's guess which credentials live there.

For the teams accountable for cloud or application security, that is a serious visibility problem. They need to find and remediate any exposed secrets quietly surviving in some overlooked corner of their real environment.

Attackers know this, and AI is making discovery faster and easier.

For example, in late 2025 Sysdig observed an attacker gain initial access to an AWS environment using valid IAM credentials discovered in public S3 buckets containing RAG data for AI models. Sysdig found multiple indicators that the attacker used LLMs throughout the operation to automate reconnaissance, generate malicious code, and make decisions as the attack unfolded. The attacker reached administrative privileges within eight minutes.

GitGuardian researchers have documented the same broader pattern in cloud attacks involving groups such as Crimson Collective. Exposed AWS credentials provided initial access. Attackers then authenticated, enumerated infrastructure, collected available data, and used AWS cloud infrastructure and storage during collection or exfiltration. Their focus on high-privilege credentials shows how quickly a leaked secret can become a bridge into a much larger cloud environment.

This is exactly why GitGuardian now scans AWS S3 buckets for exposed secrets and brings those findings into the same discovery and incident workflows security teams already use across their monitored perimeter.

What is Amazon S3 bucket security?

AWS recommends a layered approach to securing S3 buckets. That includes blocking unintended public access, enforcing least-privilege IAM permissions, and disabling ACLs where possible in favor of policy-based access controls.

They also recommend teams encrypt data at rest, require encrypted connections, enable logging, and continuously audit bucket configurations and external access. Services such as GuardDuty and Macie add monitoring for suspicious activity and sensitive data exposure.

These controls strengthen the security posture around the bucket. Secret scanning extends that coverage into the objects themselves by identifying credentials that could provide access to other systems.

Credential discovery addresses another layer of security

A private bucket can contain an active API key. A correctly scoped read-only role can still retrieve an archive holding a database password. A compromised workload identity inherits access to every object its legitimate permissions allow it to read.

Cloud posture tells you whether an identity should be able to retrieve an object. Secret scanning tells you whether retrieving that object gives the identity another credential.

For organizations trying to achieve complete credential visibility, both questions belong in the AWS S3 bucket security conversation.

S3 became a credential blind spot as cloud environments grew

Source code is an obvious place to begin secrets detection. Developers accidentally commit API keys, passwords, and tokens. Git history preserves those mistakes. Security teams responded by adding secret scanning to repositories and developer workflows.

As organizations create more applications, their cloud footprints expand too. For AWS users, that often means adding new buckets while continuing to fill old ones.

Applications write increasing amounts of operational data to S3. CI/CD systems produce artifacts and logs. Infrastructure teams store state files and backups. Many organizations accumulate years of this data without applying credential-specific scanning to the contents.

A CI process can write a credential into a log. A backup job can preserve an .env file. Terraform state can contain sensitive values that never appeared in a repository. S3 then gives those files longevity.

AI adds scale to the discovery side of that equation. Agents and AI-assisted tooling can increasingly inspect large amounts of unstructured data, determine which objects appear relevant to a goal, and continue acting on what they find. For an attacker using AI assistance, that same general capability can accelerate reconnaissance for credentials and paths to additional access.

The GitGuardian State of Secrets Sprawl 2026 found that 28% of secret incidents originate entirely outside source code repositories. Those incidents were also 13% more likely to be critical than code-only incidents.

"We scan all our repositories" describes one part of credential coverage. Teams and security leaders increasingly need to answer a broader question: Where else can a usable credential exist in our environment, and can we prove we are looking there?

Attackers and AI agents can search the environment after they get access

The Sysdig story gives us a useful view of what happens when that visibility gap works in the attacker's favor. The first credential became a discovery mechanism for the rest of the environment.

A goal-directed system with AWS credentials, command-line access, or cloud APIs can reason over the capabilities available to it. If S3 is accessible and the goal requires finding useful data, configurations, credentials, or another path forward, searching buckets is a logical action to take.

Modern cloud-focused threat actors already identify exposed credentials at scale and test which ones remain valid. AI reduces the amount of human effort required to connect those steps. Valid secrets can lead attackers, malware, and autonomous agents to more valid secrets.

Security teams need the ability to perform that discovery, fast and at scale.

AWS S3 secret scanning starts by finding what is already there

GitGuardian's AWS S3 integration is built around discovery.

Teams select the buckets they want included in their monitored perimeter and trigger a historical scan. GitGuardian analyzes the existing objects and uses its secrets detection engine to identify exposed credentials. Findings become regular incidents inside GitGuardian.

Historical scanning is especially important for object storage. An S3 bucket may contain years of accumulated data. An initial historical scan can therefore surface a significant backlog of credentials that require triage.

A useful first pass might prioritize:

• Backup buckets containing historical application data or configuration
• CI/CD and logging buckets holding build output or runtime logs
• Infrastructure buckets containing Terraform state or archived deployment artifacts

GitGuardian also scans supported archives, which extends discovery below the object visible in the S3 console. A credential stored inside a supported ZIP or tar.gz archive can still surface as an incident.

The goal is complete visibility into the credentials stored across the environment. Once discovered, teams can determine whether a secret remains valid, understand its context, establish ownership, and prioritize remediation through the same workflows used for secrets found elsewhere.

Discovery is the foundation of credential layer security

Credential layer security starts with knowing where credentials exist. Every subsequent security decision depends on that visibility.

You need discovery before you can remediate a rogue credential to your crown jewels, tucked away in that forgotten storage blob. You need to find it before you can determine ownership. You need context before you can understand its blast radius or decide how urgently it should be dealt with.

AWS is already building toward a world where agents can discover organizational knowledge across object stores and other enterprise systems while carrying out multi-step tasks. That makes complete credential discovery more urgent. Security teams need confidence that the data made accessible to automated systems does not quietly contain reusable credentials.

Credential layer security requires visibility across the places credentials actually live. Adding S3 to the monitored perimeter closes another major discovery gap and helps security teams prove that their credential coverage reflects their real infrastructure.

Add AWS S3 to your GitGuardian coverage today, or start with GitGuardian and begin closing credential blind spots across your credential layer.

FAQ

What is AWS S3 bucket security?

AWS S3 bucket security is the combination of access controls, data protection, monitoring, and security practices used to protect Amazon S3 resources and their contents. Common controls include S3 Block Public Access, least-privilege IAM policies, encryption, logging, and continuous configuration review. Secret scanning extends that visibility into the objects themselves by identifying exposed credentials that could provide access to other systems.

What is the right way to secure an S3 bucket?

Strong S3 security starts with blocking unintended public access and limiting each identity to the permissions its workload requires. Organizations should encrypt data, monitor activity, and regularly audit policies and external access. Securing S3 buckets also requires visibility into sensitive credentials stored inside their objects, since historical secret scanning can reveal exposure that configuration reviews cannot see.

What are the AWS S3 bucket security risks?

AWS S3 bucket security risks include public exposure, overly broad permissions, compromised AWS identities, and sensitive information stored within accessible objects. Exposed secrets can increase the impact of an initial compromise: attackers or AI-assisted tooling that retrieves a log, backup, or infrastructure file containing another valid credential may gain a path into additional systems.

How does AI change AWS S3 security risk?

AI systems increasingly use tools and retrieval mechanisms to find information across enterprise data sources, including object storage. An agent with excessive permissions, a compromised credential, or attacker-directed goals can use that access to inspect available cloud data. Secret scanning helps organizations discover reusable credentials before automated systems encounter them.

Can a private S3 bucket still contain exposed secrets?

Yes. A private bucket limits who can retrieve its contents, but credentials can still exist inside those objects. Any legitimate or compromised identity with sufficient read permissions may be able to retrieve those credentials. Secret scanning helps security teams discover that exposure before access to the bucket becomes part of an incident.

Why is secret scanning important for credential layer security?

Credential layer security depends on knowing where credentials exist across the real environment. Secret scanning provides the discovery required to identify exposed credentials, investigate their context, and prioritize remediation. Extending that visibility into AWS S3 helps cover cloud data that may never have entered source control.