How a Government Contractor Left Sensitive AWS Keys Exposed on Public GitHub

A contractor working for the Cybersecurity and Infrastructure Security Agency (CISA) left a public GitHub repository open that contained cloud credentials, passwords, and other sensitive information for months, according to KrebsOnSecurity.

The exposed repository, named "Private-CISA," held what amounts to digital keys to federal systems: authentication tokens, plaintext passwords, and credentials for AWS GovCloud — Amazon's isolated cloud service built specifically for U.S. government agencies handling classified or sensitive work. The contractor had deliberately turned off GitHub's built-in security feature that normally catches and blocks secrets before they go public.

What Was Actually Exposed

Files in the repository included AWS-Workspace-Bookmarks-April-6-2026.html, AWS-Workspace-Firefox-Passwords.csv, Important AWS Tokens.txt, and kube-config.txt. Think of that last one as a master keyring for Kubernetes clusters — the software systems that run containerized applications. The file contains access information and authentication certificates that would let someone log in and manage the whole system.

The repository also held plaintext credentials for CISA's internal artifactory — essentially a library where developers store the pre-built software pieces and tools used to assemble new applications. Access to that would let an attacker see how CISA builds and deploys software across its operations.

AWS GovCloud credentials are especially sensitive because they protect the cloud environment where federal agencies and contractors work with government data. This environment has stricter security rules and compliance requirements than regular Amazon cloud services, which is precisely why credential exposure matters so much for national security.

Why This Happened: Multiple Security Failures

For this leak to occur, several security safeguards had to fail. GitHub offers a feature called secret scanning that automatically detects common credential patterns — API keys, authentication tokens, SSH keys — and prevents them from being pushed to public repositories. It is on by default. The contractor turned it off.

The repository name itself, "Private-CISA," suggests the person who created it understood the material was sensitive. Yet it sat public on GitHub. Standard secure development practice calls for storing credentials in environment variables, special secret-management tools, or encrypted configuration files — never committed directly to a code repository.

Most enterprise organizations put multiple layers of protection in place: rules about which branches code can be pushed to, requirements that someone review all changes before they go live, and automated scans that catch security problems. The failures here suggest gaps in both the technical systems and the training that would have prevented this.

The Broader Pattern

Looking at government credential leaks over my three decades covering cybersecurity, the most serious breaches often come not from sophisticated hacking but from basic operational security failures. The kind of preventable mistakes that repeat.

The 2020 SolarWinds breach, while more elaborate, followed a similar outline: attackers exploited trusted infrastructure and stolen credentials to gain access to government systems. In both cases, the entry point was not high-tech espionage but access that should never have been exposed in the first place.

Access to the artifactory repository creates what security professionals call a supply-chain risk. If an attacker could see how CISA builds and deploys software, they could identify weak points or insert malicious code into the process.

Why This Matters Beyond CISA

Federal agencies increasingly rely on commercial cloud services like AWS GovCloud and Azure Government for both unclassified and sensitive workloads. These cloud platforms are authorized under a federal compliance program called FedRAMP and form the backbone of how government operates. Credential exposure at this level could potentially affect multiple agencies and programs that depend on shared infrastructure.

The exposure lasted from the repository's creation through May 2026 — spanning multiple fiscal years. That duration raises questions about how contractor work is monitored and whether someone should have caught this earlier.

Looking Forward

The immediate steps for CISA would be straightforward in principle: rotate all exposed credentials so they no longer work, investigate access logs to see who may have downloaded the files, review what systems might have been compromised, and identify what controls failed so they can prevent this in the future.

The harder problem is this: GitHub's public repository access logs can show who accessed the files, but determining whether any of those people were attackers — and if so, what damage they may have done — requires deeper investigation that we cannot do from the outside.

For organizations relying on similar cloud services and development workflows, the lesson here is familiar but worth repeating. Automated secret scanning works. Regular security training works. Clear policies about handling credentials work. The persistent challenge is not discovering these solutions; it is making sure they are actually used and enforced every day.

The government-contractor ecosystem adds a layer of complexity. Federal agencies enforce strict security requirements for their own employees, but contractors often operate under different processes and systems that may not provide the same level of oversight. As more critical infrastructure moves to cloud platforms and development workflows, that gap becomes harder to ignore.