CISA Shares Lessons After Contractor Leaked AWS GovCloud Credentials on GitHub

CISA has published an after-action review of a security incident involving agency credentials and internal code exposed through a contractor’s personal GitHub account.

The public repository contained AWS GovCloud keys, administrative and build credentials, Infrastructure-as-Code files, and details about CISA’s software deployment environment.

CISA said forensic evidence showed that the exposed credentials were not used outside its own environments. The agency also found no evidence that customer or mission data was exposed.

How the CISA GitHub incident began

CISA started its incident response on Friday, May 15, 2026, after an investigative reporter contacted the agency about internal AWS GovCloud credentials visible in a public repository.

The reporter had received information from a security researcher whose company continuously scans public repositories for exposed secrets. The researcher continued providing information during CISA’s investigation.

In its Lessons from CISA’s Cyber Incident report, the agency said its Office of the Chief Information Officer immediately focused on eliminating the public exposure and preventing further harm.

Incident detail	Finding
Initial notification	An investigative reporter contacted CISA on May 15, 2026
Repository owner	A contractor using a personal GitHub account
Exposed resources	AWS GovCloud keys, credentials, infrastructure code, and deployment files
Confirmed misuse	CISA found no external use of the exposed credentials
Data impact	No customer or mission data was found exposed

A contractor copied CISA code to a personal account

The exposed repository did not belong to CISA’s official GitHub organization.

CISA determined that a contracted employee copied build and deployment repositories into a personal GitHub account. The contractor reportedly wanted to automate the creation of cloud infrastructure.

The repository also contained administrative and build credentials connected to the development environment. This combination created greater risk because the credentials appeared alongside technical information explaining how the environment worked.

The public repository contained 844MB of data

GitGuardian’s account of the discovery says the repository contained approximately 844MB across its working tree and Git history.

The material included CI/CD logs, Terraform code, Kubernetes manifests, ArgoCD files, GitHub Actions workflows, internal documents, scripts, and credential-related configuration files.

Researchers also identified AWS tokens, plaintext passwords, and Microsoft Entra ID SAML certificates. Some credentials reportedly remained valid when researchers examined the repository.

• AWS GovCloud administrative credentials
• Plaintext usernames and passwords
• Microsoft Entra ID SAML certificates
• Terraform Infrastructure-as-Code files
• Kubernetes manifests and configuration files
• ArgoCD application files
• GitHub Actions workflows
• Build and deployment documentation
• Internal scripts and documentation backups

CISA used a “stop the bleeding” response

CISA described its first response phase as “stop the bleeding.” The agency moved to remove the public exposure before completing its full investigation.

The response team preserved a forensic copy of the repository and took the public version offline. It also shut down the affected development environment and revoked the contractor’s system access.

CISA reset the credentials associated with the exposed environment and began examining logs for signs that anyone outside the agency had used them.

1. Preserve a forensic copy of the public repository.
2. Remove the repository from public access.
3. Shut down the affected development environment.
4. Reset the exposed credentials.
5. Revoke the contractor’s access.
6. Review logs for unauthorized activity.
7. Identify every environment the contractor could administer.
8. Rotate additional credentials as a precaution.

CISA found no evidence of external credential use

CISA reviewed available logs to determine whether an outside party had used the leaked credentials.

The agency said the analysis showed no use of those credentials outside CISA-controlled environments. Investigators also found no evidence that customer information or mission data had been exposed.

These findings do not make the repository harmless. Publicly exposed credentials and deployment information create an opportunity for abuse even when investigators find no successful intrusion.

Researchers had warned about the repository

The repository was discovered through GitGuardian’s automated monitoring of public code-hosting platforms.

According to GitGuardian researcher Guillaume Valadon, automated alerts sent to the account owner did not receive a response.

The researcher then tried other reporting channels before contacting journalist Brian Krebs, who notified CISA and reported the incident publicly.

The repository had reportedly existed since November 2025

The public repository was named “Private-CISA,” despite being accessible to anyone on GitHub.

KrebsOnSecurity’s original investigation reported that the repository was created on November 13, 2025.

The report said it contained credentials for several highly privileged AWS GovCloud accounts and numerous internal CISA systems. The repository was removed shortly after researchers and the reporter contacted the agency.

CISA rotated more than the known exposed keys

CISA did not limit its response to the credentials found in the public repository.

As a precaution, the agency rotated credentials across every environment where the contractor had administrative access. This wider response accounted for the possibility that other secrets had been copied or viewed.

The agency said interconnected systems made the rotation process more complicated. Changes to one credential could affect applications, scripts, services, or automated deployment pipelines that depended on it.

Credential rotation proved slower than expected

CISA identified credential rotation as one of the most important operational lessons from the incident.

Organizations may have policies requiring rapid key replacement, but complex dependencies can make emergency rotation difficult. An expired or replaced secret can interrupt production systems when teams do not understand every dependency.

CISA recommends building mature key-management processes and regularly testing emergency rotation procedures before an incident occurs.

Area	Problem identified	CISA’s response
Public repositories	A developer could upload sensitive code to a personal public account	Added stronger endpoint-based upload controls
Secrets management	Credentials remained inside code repositories	Rotated secrets and created an improvement plan
Incident playbooks	No dedicated GitHub and cloud exposure playbook existed	Created a playbook during the response
Reporting channels	The researcher struggled to find the correct contact	Started consolidating and clarifying reporting paths
Development environments	Different environments had inconsistent controls	Accelerated environment consolidation
Key rotation	System dependencies slowed replacement	Recommended tested rotation capabilities

CISA changed how it controls public repository uploads

CISA found that its previous repository controls did not provide the flexibility needed by developers.

Some users needed to download open-source code from public services while the agency also needed to prevent uploads of sensitive material.

CISA moved toward endpoint detection and response controls that allow approved downloads while restricting unauthorized uploads to public repositories.

Repository allow and deny lists were tightened

The agency updated its repository governance during the response.

CISA tightened allow and deny lists and reduced users’ ability to push agency material to public repositories. These controls aim to prevent a repeat of the contractor’s personal-account workflow.

Organizations can apply similar rules through managed developer environments, endpoint controls, network policies, and Git hosting restrictions.

Secrets should not remain inside code repositories

CISA acknowledged that secrets existed inside repositories despite policies against the practice.

Private repositories reduce public visibility, but they do not provide a secure secrets-management system. Developers, compromised accounts, integrations, and automated tools may still gain access.

Organizations should store secrets in managed vaults and provide applications with short-lived credentials when possible.

• Remove static credentials from source code.
• Use a managed secrets vault.
• Prefer short-lived credentials over permanent keys.
• Scan the full Git history, not only the latest files.
• Enable secret detection before every push.
• Block commits containing confirmed credentials.
• Rotate exposed secrets immediately.
• Record which systems depend on each credential.

CISA lacked a dedicated GitHub incident playbook

CISA’s response team found that it did not have a dedicated playbook for a public GitHub and cloud credential exposure.

The agency created one while handling the incident. It is now refining that process using evidence and problems identified during the response.

The new playbook can help responders coordinate repository removal, forensic preservation, credential rotation, access revocation, cloud investigation, and public communication.

Organizations should prepare repository leak playbooks

A public code exposure requires different actions from a conventional malware infection or network intrusion.

Removing the repository alone does not eliminate the risk. Copies may remain in forks, clones, caches, search indexes, downloaded archives, and Git history.

A complete playbook should cover both immediate containment and long-term cleanup.

1. Confirm the repository and affected owner.
2. Preserve a forensic copy before removal.
3. Contact the hosting provider.
4. Revoke exposed keys, passwords, and certificates.
5. Review cloud and identity logs.
6. Search for forks, mirrors, and cached copies.
7. Identify additional secrets in the Git history.
8. Notify affected system owners.
9. Document the incident and corrective actions.

Unclear reporting paths delayed escalation

The researcher tried several ways to report the exposed information before CISA received the warning through a journalist.

CISA said clear and separate reporting channels matter because an incident affecting the agency itself may require a different route from a vulnerability affecting a product or external organization.

The agency plans to consolidate and publicize its reporting options, including information provided through a security.txt file.

Security.txt can help researchers find the right contact

A security.txt file gives researchers a standard location for disclosure instructions and security contact details.

CISA has long encouraged federal agencies to publish clear vulnerability disclosure policies. Its Vulnerability Disclosure Policy Template explains how organizations can define covered systems, reporting methods, and expected response timelines.

However, organizations should also provide a clear path for reporting exposed credentials, data leaks, and incidents that may fall outside a traditional vulnerability disclosure program.

Development environment sprawl created inconsistent controls

CISA found that work to consolidate developer environments had not finished before the incident.

Multiple environments can create different security policies, access methods, logging systems, and repository permissions. These differences make enforcement and incident response harder.

The agency accelerated its consolidation work to provide more consistent controls across its development infrastructure.

Zero Trust visibility supported the investigation

CISA credited its Zero Trust architecture and centralized visibility with helping responders investigate the exposure.

Detailed identity, endpoint, network, and cloud logs allowed the team to trace credential use and determine whether activity occurred outside approved environments.

Without reliable logs, the agency might have needed to assume that every exposed credential had been abused.

External reporting played a critical role

CISA did not discover the public repository through its own internal controls.

An external security researcher found it, a journalist contacted the agency, and other specialists helped evaluate the exposed material.

KrebsOnSecurity reported that the repository owner had disabled GitHub protections designed to detect or block some secrets before publication.

The incident involved human error, not a sophisticated intrusion

CISA described the event as an accidental exposure caused by a contractor’s attempt to perform work more efficiently.

The contractor copied code and credentials into a personal account to automate cloud deployment. That decision bypassed CISA’s approved development environment and repository controls.

The incident shows why security programs must account for ordinary work behavior, convenience-driven shortcuts, and third-party access.

Contractors need the same controls as employees

Contract workers may receive powerful access to cloud platforms, repositories, deployment systems, and administrative tools.

Organizations should apply the same repository restrictions, credential policies, monitoring, security training, and offboarding requirements to contractors and permanent employees.

They should also limit access to the minimum resources required for each role and remove privileges as soon as they are no longer needed.

• Use managed devices for contractor access.
• Block personal code-hosting accounts.
• Apply least-privilege cloud permissions.
• Require approved secrets-management tools.
• Monitor repository uploads from endpoints.
• Review administrator access regularly.
• Revoke access immediately at contract completion.
• Audit contractor activity after high-risk changes.

CISA says transparency can improve security

CISA chose to publish its findings even though the incident exposed weaknesses inside the federal cybersecurity agency.

The agency said organizations should prepare for incidents under a “when, not if” approach. Fast containment, useful logs, tested playbooks, and clear reporting channels can reduce the impact when preventive controls fail.

The CISA after-action review presents the disclosure as an opportunity for other organizations to improve repository governance, credential management, and incident response.

What organizations can learn from the CISA incident

The incident shows that a repository marked private in name can still expose sensitive information when its actual visibility setting remains public.

Security teams should monitor both official company repositories and public platforms for data connected to their domains, employees, contractors, cloud accounts, and internal systems.

They should also assume that exposed credentials may have been copied immediately, even when logs show no confirmed misuse.

Lesson	Recommended action
Public monitoring matters	Continuously scan public repositories for company secrets
Repository names prove nothing	Verify visibility settings and access controls
Private repositories can still leak secrets	Keep credentials in dedicated secret stores
Rotation can disrupt systems	Map dependencies and test emergency replacement
Researchers need a clear contact	Publish security.txt and incident-reporting instructions
Contractors create third-party risk	Apply the same controls used for employees
Logs determine incident scope	Centralize cloud, identity, endpoint, and repository telemetry

Why the CISA disclosure matters

CISA regularly advises government agencies and private organizations on incident response and cloud security. Publishing details about its own failure gives other teams a practical example of how repository and credential controls can break down.

The agency’s response also shows that rapid repository removal represents only the first step. Credential rotation, forensic analysis, access review, control improvements, and reporting reform may continue long after the public exposure ends.

The incident ultimately highlights a basic security principle: organizations must treat source code, infrastructure files, credentials, and deployment documentation as interconnected assets.

FAQ