Source: searchsecurity.techtarget.com. Original reporting by SearchSecurity; additional analysis by UpGuard.
What Happened
In January 2020, cybersecurity vendor UpGuard discovered a public GitHub repository containing sensitive Amazon Web Services (AWS) data — including customer credentials, authentication tokens, private encryption keys, and API keys for third-party services. The repository, which was just under 1 GB in size, appeared to have been uploaded by an AWS engineer and contained log files and resource templates referencing what UpGuard described as “likely” AWS customers.
UpGuard’s automated data-leak detection engine identified the repository within 30 minutes of its creation, on January 13, 2020, at approximately 11:00 a.m. By 4:00 p.m. the same day, AWS had removed public access to the repository — a total response window of roughly five hours from upload to remediation.
What Was Exposed
According to UpGuard’s report, the repository contained several categories of sensitive material:
- Multiple AWS key pairs, including one file named
rootkey.csv— a name strongly suggesting it granted root-level access to an AWS account. - Authentication tokens and API keys for various third-party cloud services and providers.
- Keys for email and messaging providers, found within files attributed to an unnamed insurance company.
- Hostnames for what appeared to be AWS customer infrastructure.
UpGuard did not specify the total number of AWS customers potentially affected by the exposure.
Attribution and Intent
Several documents in the repository included the owner’s name, and UpGuard said it identified a LinkedIn profile for an AWS engineer that matched that name exactly. The engineer’s stated role also corresponded to the types of data found in the files, leading UpGuard to conclude with confidence that the uploader was an AWS employee.
UpGuard stated there was “no evidence that the user acted maliciously or that any personal data for end users was affected, in part because it was detected by UpGuard and remediated by AWS so quickly.” The most likely explanation is an accidental public upload — a mistake that is more common than many organizations acknowledge.
Timeline of Discovery and Response
- ~10:30 a.m., January 13, 2020: Repository created and made public on GitHub.
- ~11:00 a.m.: UpGuard’s data-leak detection engine flags the repository as potentially sensitive.
- ~1:18 p.m.: UpGuard analyst contacts AWS Security team to report the exposure.
- ~4:00 p.m.: AWS removes public access to the repository.
Why GitHub’s Built-In Token Scanning Wasn’t Enough
GitHub offers a token scanning feature that can detect certain types of exposed credentials and, in partnership with service providers, automatically revoke them. However, UpGuard highlighted two critical limitations that applied in this case:
- Token scanning is opt-in. Repository owners must explicitly enable it; it is not active by default for all repositories.
- Scope is limited. Even when active, GitHub’s token scanning cannot detect or revoke exposed passwords or raw private encryption keys — only structured tokens that partner services have registered with GitHub’s scanning program.
This gap underscores why organizations cannot rely solely on platform-level controls to prevent credential exposure on public source control systems.
Lessons for DevOps and Security Teams
This incident illustrates a persistent and well-documented risk in software development workflows: credentials ending up in source control, often by accident. Key takeaways for engineering and DevOps teams include:
- Never store credentials in repositories. Use secrets managers such as AWS Secrets Manager, HashiCorp Vault, or environment-level secrets in your CI/CD platform.
- Use pre-commit hooks. Tools like
git-secrets,truffleHog, ordetect-secretscan scan staged changes for secrets before they are committed. - Enable GitHub secret scanning. For GitHub repositories, enable secret scanning and push protection to block or alert on known credential formats at push time.
- Rotate credentials immediately upon exposure. If a secret is suspected to have been public — even briefly — treat it as compromised and rotate it without delay.
- Apply least privilege. Root account credentials should almost never appear in tooling or automation. Use IAM roles with scoped permissions instead.
- Audit repository visibility settings. Enforce organization-level policies that prevent accidental creation of public repositories containing internal tooling or configuration data.
AWS Response
According to SearchSecurity’s original reporting, AWS had not responded to a request for comment at the time of publication. AWS did act promptly to remove the repository once notified by UpGuard.