On May 14, 2026, we found 844 MB of sensitive CISA-related data in a public GitHub repository and got it taken down in 26 hours. I told the story in How We Got a CISA GitHub Leak Taken Down in Under a Day.
Two months later, CISA published Lessons from CISA’s Cyber Incident. Most organizations bury this kind of incident. CISA wrote it up, explained what worked, what did not, and invited the industry to learn from it. As a practitioner, I think the document is really good. As the researcher who reported the leak, I want to translate its lessons into practical steps for security teams.
To my knowledge, it is also the first time a national cybersecurity agency has publicly advocated for secrets scanning and for simplifying relations with security researchers. These are topics my team has been pushing for years, and I am proud to see them recognized at this level.
CISA’s response offers six lessons for security teams: take external reports seriously, continuously scan repositories for secrets, build dedicated leak-response playbooks, simplify reporting channels, strengthen development guardrails, and test credential rotation before an incident.
1. Take external vulnerability reports seriously
CISA ultimately acted on a report that reached it through an unnecessarily complicated path, including CERT/CC, personal contacts, and a journalist. They engaged, kept the channel open, and thanked us for the collaboration.
What to copy: Treat every external report as signal until proven otherwise. The person reporting a leak to you is not the threat. Letting nine notification emails go unanswered is how a one-day incident becomes a six-month exposure.
2. Monitor repositories continuously for exposed secrets
CISA’s action plan includes stricter control over public repositories and enhanced monitoring for exposed developer secrets. The lesson is broader than public repositories: no plaintext secret should be committed to source control, including private repositories.
What to copy: Scan continuously, not quarterly. The Private-CISA repository sat public for six months. Continuous monitoring of public GitHub surfaced it. Comprehensive internal scanning could have caught the plaintext passwords and committed backups long before they left the building.
3. Build a dedicated secrets-leak response playbook
CISA acknowledged it lost time early on because it had no GitHub and cloud incident-response playbook and had to build one during the incident.
What to copy: Write a secrets-leak playbook before you need it. Who revokes the keys? Who talks to GitHub? Who checks the Git history, not just the working tree? A leaked credential is not a generic incident; it needs its own runbook.
4. Simplify security incident reporting channels
Before reaching CISA, I emailed the contractor, filed through the vulnerability disclosure platform, and finally involved a reporter. CISA recognized the ambiguity and is refining its channels.
What to copy: Make it trivial to report a leak about you, not just about your products. Publish a security.txt, but do not stop there. Put reporting instructions in several prominent places, and make sure a report about your own infrastructure does not land in a product-bug queue.
5. Strengthen development environment guardrails
CISA was already consolidating its developer environments when the incident hit, and the leak confirmed the direction: consistent controls, fewer unmanaged tools.
What to copy: Unmanaged tooling creates exactly the kind of blind spot where secrets can leak. Personal GitHub accounts, contractor laptops, and ad hoc backup scripts all sit outside your controls. Consolidate them, and the guardrails follow.
6. Test cryptographic key rotation readiness
CISA admitted key rotation took longer than expected because of the complexity of its systems and interconnections.
What to copy: Test your rotation before an incident forces you to. If you cannot rotate a credential quickly, you do not have operational control over it. Key agility is the most overlooked item on this list, and the one that determines how long an attacker’s window stays open.
Transparency is what makes these lessons valuable
CISA also credits Zero Trust principles and strong logging for containing the incident, and both points are worth reading in full. But the biggest takeaway is the postmortem itself. “It is not a matter of if, but when.” CISA lived it, wrote it down, and shared it. That is exactly the incident communication we should expect from every organization.
Want to know what your public GitHub exposure looks like before someone else finds out? Run a GitHub Security Audit or check a specific credential with HasMySecretLeaked.
