🛡 DATA BREACHES 🛡

Lecciones Aprendidas del Reciente Filtración de GitHub de CISA

⏰14 de julio de 2026🛡CyberObservatorio

Idioma

◢ DATA BREACHES ◣

Lecciones Aprendidas del Reciente Filtración de GitHub de CISA

⟫ 13/07/2026 ⟫ BrianKrebs

Fuente: Krebs on Security

La Agencia de Ciberseguridad e Infraestructura de Estados Unidos (CISA, por sus siglas en inglés) ha publicado un informe póstumo sobre una reciente filtración de datos en la que un contratista expuso decenas de credenciales internas de CISA, incluidas claves de AWS GovCloud, en un repositorio público de GitHub durante casi seis meses. Esta situación fue revelada por KrebsOnSecurity, lo que subraya la importancia de la vigilancia y la respuesta ante incidentes de seguridad. Expertos en la materia señalan que las deficiencias identificadas en la respuesta inicial de la agencia ofrecen lecciones valiosas que todos los equipos de seguridad deberían considerar.

El 15 de mayo de 2026, la firma de seguridad GitGuardian solicitó ayuda para notificar a CISA sobre la existencia de un repositorio público de GitHub denominado “Private CISA”, que contenía 844 MB de datos sensibles relacionados con la agencia. Uno de los archivos expuestos, titulado “importantAWStokens”, contenía credenciales administrativas para tres servidores de Amazon AWS GovCloud. Otro archivo, “AWS-Workspace-Firefox-Passwords.csv”, listaba nombres de usuario y contraseñas en texto plano para decenas de sistemas internos de CISA.

CISA reconoció rápidamente la alerta inicial, pero tardó más de 48 horas en invalidar las claves de AWS y muchos otros secretos críticos que habían sido filtrados en el repositorio de GitHub. En su informe sobre la filtración de datos, la agencia explicó que las complejidades de sus sistemas y las interconexiones con socios federales e industriales provocaron que la rotación de claves tardara más de lo previsto.

“Basándonos en esta experiencia, CISA anima a otros a mantener capacidades de gestión de claves maduras y bien probadas”, señala el informe.

Además, CISA admitió que puede mejorar en su respuesta a las notificaciones de incidentes de seguridad provenientes de partes externas. El informe subraya que contar con canales de comunicación claros y definidos es esencial para asegurar que los incidentes que afectan a la organización se manejen de manera diferente a aquellos que involucran sus productos o clientes.

“En el caso de CISA, estos canales no estaban bien definidos, lo que llevó al investigador de seguridad a intentar múltiples vías de contacto, incluyendo el envío de correos electrónicos al contratista, la presentación a través de la plataforma de divulgación de vulnerabilidades de CISA (que está destinada a vulnerabilidades que impactan a la comunidad de ciberseguridad en general), y, finalmente, involucrar a un reportero”, se lee en el análisis redactado por Preston Werntz y Brad Libbey, respectivamente, el director de información en funciones y el director de seguridad de la información en funciones de CISA.

CISA indicó que está refinando sus canales de comunicación para que sean más accesibles y rápidos para los investigadores. “Además, aunque muchos investigadores confían en el archivo security.txt, las organizaciones pueden garantizar claridad publicando instrucciones de reporte en múltiples ubicaciones destacadas”, escribieron los autores del informe.

Guillaume Valadon, el investigador de GitGuardian que primero contactó a KrebsOnSecurity sobre las credenciales expuestas de CISA, afirmó que la agencia ignoró nueve alertas automáticas sobre las credenciales expuestas antes de nuestra notificación del 15 de mayo. La empresa de Valadon escanea constantemente repositorios de código públicos en GitHub y otras plataformas en busca de secretos expuestos, alertando automáticamente a las cuentas infractoras sobre cualquier exposición de datos sensibles aparente.

“Dejar sin respuesta nueve correos de notificación es cómo un incidente de un día se convierte en una exposición de seis meses”, escribió Valadon en un análisis del informe de CISA. “Faciliten la denuncia de una filtración sobre ustedes, no solo sobre sus productos. La persona que reporta una filtración no es la amenaza. Publíquense un security.txt, pero no se detengan ahí. Pongan instrucciones de reporte en varios lugares destacados y asegúrense de que un informe sobre su propia infraestructura no termine en una cola de errores de producto”.

Los autores del informe también enfatizaron la importancia de escanear continuamente repositorios de código públicos como GitHub en busca de secretos expuestos, y mencionaron que CISA ha rotado desde entonces todos sus secretos y ha creado un plan de acción para mejorar la gestión de secretos de desarrolladores y para monitorear mejor estos aspectos en el futuro.

El informe indica que, aunque CISA había desarrollado un manual para responder a incidentes de ciberseguridad, ese manual no incluía qué hacer en situaciones que involucraran GitHub u otros servicios en la nube. Valadon afirmó que el informe valida la necesidad de escanear de manera continua — no solo trimestral — en busca de secretos expuestos.

“El repositorio Private-CISA estuvo público durante seis meses”, escribió Valadon. “El monitoreo continuo de GitHub lo sacó a la luz. Un escaneo interno exhaustivo podría haber detectado las contraseñas en texto plano y las copias de seguridad comprometidas mucho antes de que abandonaran la organización”.

CISA se otorgó calificaciones aprobatorias en varias áreas de preparación de seguridad que, según la agencia, le ayudaron a evaluar el alcance y el impacto de los secretos expuestos, incluyendo capacidades de registro mejoradas y la adopción de principios de cero confianza tanto en sus sistemas de producción como de desarrollo. CISA afirmó que esos registros detallados le permitieron demostrar que no se expuso ningún dato de clientes o de misión y que las credenciales filtradas no se utilizaron fuera de los entornos de CISA. La agencia también indicó que el contratista que expuso los secretos tuvo revocado su acceso al sistema.

Valadon considera que la mayor lección es el propio informe póstumo de CISA, y elogió a la agencia por ser transparente sobre lo que funcionó y lo que no.

“Hasta donde sé, también es la primera vez que una agencia nacional de ciberseguridad aboga públicamente por el escaneo de secretos y por simplificar las relaciones con investigadores de seguridad”, escribió Valadon. “Esa es exactamente la comunicación de incidentes que deberíamos esperar de cada organización”.

◢ DATA BREACHES ◣

Lessons Learned from CISA’s Recent GitHub Leak

⟫ 13/07/2026 ⟫ BrianKrebs

Source: Krebs on Security

TheCybersecurity and Infrastructure Security Agency(CISA) has issued a postmortem on a recent data leak in which a contractor published dozens of internal CISA credentials — including AWS Govcloud keys — in a public GitHub repository for almost six months before being notified by KrebsOnSecurity. Experts say the gaps identified in the agency’s initial response provide important lessons that all security teams should absorb. On May 15, 2026, the security firmGitGuardianasked for help in notifying CISA about the existence of a public GitHub repository called “Private CISA” that included 844 MB of sensitive CISA-related data. One of the exposed files, titled “importantAWStokens,” included the administrative credentials to three Amazon AWS GovCloud servers. Another file — “AWS-Workspace-Firefox-Passwords.csv” — listed plaintext usernames and passwords for dozens of internal CISA systems. CISA quickly acknowledged our initial alert, but took more than 48 hours to invalidate the AWS keys and many other important secrets leaked in the GitHub repo. Inits report on the data leak, CISA said the complexities of the agency’s systems and interconnections with federal and industry partners caused its key rotation to take longer than anticipated. “Drawing on this experience, CISA encourages others to maintain mature and well-tested key management capabilities,” the report notes. CISA also admitted it can do better when it comes to responding to security incident notifications from external parties. The postmortem stresses that clear and distinct reporting channels are essential to ensure that incidents affecting the organization itself are handled differently from those involving its products or customers. “In CISA’s case, these channels were not well defined, leading the security researcher to try multiple avenues – including emailing the contractor, submitting through CISA’s vulnerability disclosure platform (which is intended for vulnerabilities impacting the broader cybersecurity community), and ultimately involving a reporter,” reads the analysis written byPreston WerntzandBrad Libbey, the acting chief information officer and acting chief information security officer at CISA, respectively. CISA said it is refining its reporting channels to make them easier and faster for researchers. “Additionally, while many researchers rely on the security.txt file, organizations can ensure clarity by publishing reporting instructions in multiple prominent locations,” the CISA authors wrote. Guillaume Valadon, the GitGuardian researcher who first contacted KrebsOnSecurity about the exposed CISA credentials, said CISA ignored nine automated alerts about the exposed credentials prior to our notification on May 15. Valadon’s company constantly scans public code repositories at GitHub and elsewhere for exposed secrets, automatically alerting the offending accounts of any apparent sensitive data exposures. “Letting nine notification emails go unanswered is how a one-day incident becomes a six-month exposure,” Valadonwrotein an analysis of CISA’s report. “Make it trivial to report a leak about you, not just about your products. The person reporting a leak to you is not the threat. Publish asecurity.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.” The report’s authors also emphasized the importance of continuously scanning public code repositories like GitHub for exposed secrets, and said CISA has since rotated all secrets and created an action plan to improve management of developer secrets and to better monitor for them going forward. The report notes that while CISA had developed a playbook for responding to cybersecurity incidents, that playbook somehow didn’t include what to do in situations involving GitHub or other cloud services. Valadon said the report validates the need to scan continuously — not just quarterly — for exposed secrets. “The Private-CISA repository sat public for six months,” Valadon wrote. “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.” CISA gave itself passing grades on several areas of security preparedness that it said helped the agency gauge the scope and impact of the exposed secrets, including enhanced logging capabilities, and the adoption of zero-trust principles in both its production and development systems. CISA said those detailed logs allowed it to show that no customer or mission data was exposed, and that the leaked credentials were not used outside of CISA’s environments. The agency said the contractor who exposed the secrets had their system access revoked. Valadon reckons the biggest takeaway is the CISA postmortem itself, and praised the agency for being transparent about what worked and what didn’t. “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,” Valadon wrote. “That is exactly the incident communication we should expect from every organization.”

𝐗 Twitter f Facebook ☎ WhatsApp ✈ Telegram

← VOLVER A CIBERSEGURIDAD