All Articles

The agency that writes incident response guidance for everyone else just published a postmortem of its own credential leak. That alone makes it worth 10 minutes of your time.

Here is what the written record actually says, and what is worth changing in your own program based on it.

What Happened

A contractor copied a CISA build-and-deployment repository to a personal GitHub account to build cloud infrastructure autonomously, according to CISA's report, written by acting CIO Preston Werntz and acting CISO Brad Libbey. Along with the code went admin and build credentials plus infrastructure-as-code data containing private access keys.

Per KrebsOnSecurity, the exposed files included "importantAWStokens" (admin credentials for three AWS GovCloud servers) and "AWS-Workspace-Firefox-Passwords.csv" (plaintext usernames and passwords for dozens of internal systems).

The impact assessment: log analysis showed no use of the leaked credentials outside CISA environments and no customer or mission data exposure (Cybersecurity Dive). CISA rotated passwords across every development environment the contractor could access, not just the leaked ones.

Root Cause: Three Specific Control Failures

1. Push protection was disabled. A CISA administrator had turned off GitHub's default setting that blocks secrets from being pushed to public repos. One org-level toggle undid a working control.

2. Secrets lived in repos at all. CISA's report states plainly that no repository should contain secrets, yet secrets were present even in its private repositories. Private visibility is an access control, not a secrets-management strategy.

3. No playbook for this scenario. CISA had IR playbooks, but none covering a GitHub or cloud-service leak. The team wrote one mid-incident, which is the slowest possible time to write one.

What This Means for Your Team

Contractor workflows are your exposure. This was not an APT. A person with legitimate access copied a repo to personal infrastructure to work faster. Ask yourself: could a contractor at your org do the same today, and which of your controls would catch it?

External reports need a route to a human. The researcher tried the contractor directly, then CISA's vulnerability disclosure platform (built for product vulnerabilities, not incidents about CISA itself), then a journalist. Nine automated alerts died in an unmonitored queue. GitGuardian's Guillaume Valadon summarized it as "how a one-day incident becomes a six-month exposure."

Logging is what turns "we hope" into "we verified." The strongest part of CISA's response: comprehensive logs and zero-trust segmentation in production and development let it demonstrate non-use of the credentials rather than assert it.

7 Changes Worth Making Now

1. Scan continuously, not quarterly. Monitor public GitHub and your own repos for exposed secrets around the clock. This repo was found by continuous external scanning, six months too late for CISA to act first.
2. Get secrets out of repos entirely. Vault them; enforce with pre-commit hooks and CI checks. Assume private repos will eventually be cloned somewhere you do not control.
3. Audit push protection and alert on changes. Check your GitHub org settings today. Treat disabling secret-blocking as a security event, not a preference.
4. Time your key rotation before an incident does. CISA needed 48+ hours under pressure. If you have never measured a full rotation of crown-jewel credentials end to end, you have an untested assumption, not a capability.
5. Write the GitHub/cloud-leak playbook. Scope it to: repo takedown, credential inventory, rotation order, log review, researcher comms. An afternoon of work now versus improvising mid-incident.
6. Make it trivial to report a leak about you. Publish security.txt, put reporting instructions in several prominent places, and route infrastructure reports somewhere a human reads, separate from your product-bug queue.
7. Fund logging and zero trust as scoping tools. They will not prevent the leak. They are the difference between proving impact in days and guessing at it in front of your board.

If you do one thing today: check whether push protection and secret scanning are enforced across your GitHub org, and who can change that setting.

30-Day Checklist

• Week 1: Audit GitHub org settings (push protection, public-repo upload controls). Inventory contractor access to code repos.
• Week 2: Run a secrets scan across all repos, public and private. Rotate anything found.
• Week 3: Draft or update the cloud-and-repo leak playbook. Stand up the researcher reporting channel and publish security.txt.
• Week 4: Tabletop the scenario: "our AWS keys are on public GitHub." Time the key rotation end to end.

The Part Worth Copying

Plenty of organizations have leaked worse and said less. CISA graded its own response in public, named the failed controls, and published the fix list. When your incident comes, a report this specific is what keeps customer and board trust. Silence does the opposite.

Related on CISOPlatform

• Fireside chat: Revolutionizing Incident Response and Building True Cyber Resilience, with Dr. Erdal Ozkaya
• CISO fireside chat: Managing a Dynamic Attack Surface, with Rick Doten (VP Information Security, Centene)
• Fireside chat: The Dark Path of Stolen Data, with Matthew Maynard (BJC Healthcare)

Join the Discussion

Three questions for practitioners. Answer in the comments:

• Has your team ever timed a full rotation of cloud admin credentials? What broke, and how long did it actually take?
• Who at your org reads inbound reports about your own infrastructure, and how fast would nine external alerts get to them?
• Do your IR playbooks cover a secrets leak in a public repo, or would you be writing one mid-incident like CISA did?

Sources: CISA, "Lessons from CISA's Cyber Incident"; KrebsOnSecurity, July 13, 2026; Cybersecurity Dive, July 10, 2026; GitGuardian analysis.