Límites del registro de auditoría de GitHub: retención
Lo que no guarda el registro de auditoría de GitHub: retención de 180 y 7 días, límites de plan, IP ocultas, sin contenido de archivos ni lecturas de secretos.
En resumen. El registro de auditoría es la mejor evidencia de GitHub que tienes, y tiene límites claros. Retención: 180 días para los eventos de auditoría, 7 días para los eventos Git. Plan: la API, los eventos Git y el streaming requieren Enterprise Cloud. IP: ocultas salvo que un propietario active su visualización. Contenido: sin contenido de archivos, sin diffs, sin rastro de que un workflow lea un secreto, sin registro por usuario de la lectura de código en la interfaz web. Alcance: los logs de seguridad de las cuentas personales van aparte. Antes de escribir «ningún indicio de compromiso», contrasta cada uno de estos puntos con la exportación que analizaste de verdad.
Todo informe de investigación debería decir qué podían mostrar las evidencias y qué no. En GitHub esa lista es corta pero importante, y varios de sus puntos dependen de tu plan y de tu configuración, no del atacante.
Retención
| Datos | Retención | Fuente |
|---|---|---|
| Eventos de auditoría de organización / empresa | 180 días | About the audit log for your enterprise |
Eventos Git (git.clone, git.fetch, git.push) | 7 días | la misma página y la página del registro de auditoría de la organización |
| Ventana por defecto de la API | últimos 3 meses, salvo que se indique created | Referencia REST |
| Registro de auditoría por GraphQL | de 90 a 120 días de datos | Reviewing the audit log (Enterprise Cloud) |
| Logs y artefactos de Actions | 90 días por defecto (configurable) | Ajustes de retención |
| Registro de auditoría enviado por streaming | lo que lo conserve tu almacenamiento | tu bucket / SIEM |
Qué significa esto en la práctica: una intrusión descubierta con tres semanas de retraso no tendrá ningún registro de clonado, salvo que hagas streaming. Una intrusión descubierta con siete meses de retraso casi no tendrá evidencias en el lado de GitHub. El streaming del registro de auditoría es la única forma de superar ambos límites.
Requisitos de plan
| Funcionalidad | Free / Team | Enterprise Cloud |
|---|---|---|
| Ver y exportar el registro de auditoría de la organización (interfaz, JSON / CSV) | sí | sí |
| API REST y GraphQL del registro de auditoría | no | sí |
| Eventos Git | no | sí (API, exportación, streaming) |
| Streaming del registro de auditoría | no | sí (empresa) |
| Lista de IP permitidas, SSO SAML | no | sí |
GitHub indica que la API del registro de auditoría requiere Enterprise Cloud, y lo mismo ocurre con las listas de IP permitidas. En Free y Team, la exportación desde la interfaz es tu fuente principal, y el clonado masivo solo puede deducirse de forma indirecta (consulta exfiltración de repositorios).
Ajustes que cambian lo que obtienes
- Direcciones IP. GitHub no muestra las IP de origen por defecto. Cuando un propietario activa su visualización, se aplica a los eventos nuevos y a los existentes. Aun así, las IP solo se muestran en ciertos casos: miembros de la organización que actúan sobre recursos privados o internos de la organización, y peticiones a la API con contexto de repositorio. Cuenta con que habrá huecos.
- Metadatos de token.
hashed_token,programmatic_access_typeytoken_scopesse registran en los eventos autenticados con token. Los datos de los eventos Git y de las claves SSH y de despliegue figuran como public preview en la documentación de GitHub, y las búsquedas porhashed_tokenen la interfaz y en la API excluyen los eventos Git.
Lo que no se registra
- Contenido de archivos y diffs. El registro de auditoría te dice que hubo un push y que se ejecutó un workflow. No te dice qué contenía el archivo del workflow. Un workflow modificado hay que deducirlo de sus ejecuciones (rama nueva, secretos impresos) y confirmarlo en el historial del repositorio.
- Lecturas de secretos. Crear, actualizar y eliminar secretos de Actions son eventos. Que un workflow use un secreto durante una ejecución, no. El archivo de logs de la ejecución es el único registro de lo que un paso hizo con él (consulta fuga de secretos de Actions).
- Operaciones Git hechas desde la web o la API. Los eventos Git las excluyen. Una pull request fusionada desde el navegador hace push a la rama base sin ningún evento
git.push. - Navegar por el código en la interfaz web. Ver archivos en el navegador no genera eventos de auditoría por archivo. Las descargas de archivos comprimidos (
repo.download_zip), sí. - Lo que ocurre en los runners. El registro de auditoría ve el registro y el estado de los runners, no los comandos que un trabajo ejecutó en un host autoalojado. Eso está en los logs
_diagdel runner (consulta seguridad de runners autoalojados). - La actividad de las cuentas personales. El log de seguridad de cada usuario (inicios de sesión, cambios de 2FA, sus claves SSH y tokens) es independiente del registro de auditoría de la organización y no forma parte de su exportación. Lo revisa el propio usuario, y el analizador no lo lee.
- Todo lo que ocurre cuando el atacante sale de GitHub. Las claves cloud usadas en AWS, Google Cloud o Azure aparecen en esos logs (consulta el salto a la nube).
Limitaciones del propio analizador
La herramienta hereda todos los huecos anteriores y añade los suyos:
- Heurísticas y umbrales. El clonado masivo salta a partir de 10 repositorios distintos por actor e IP en aproximadamente una hora. IP nueva y país nuevo necesitan 24 horas de historial por token o actor. Un atacante paciente, o una exportación que empieza el mismo día de la intrusión, puede quedarse por debajo.
- Reglas de gravedad baja ruidosas.
workflow-new-branch,token-new-ipyactions-secret-createdsaltan con el trabajo normal, por diseño. Léelas en contexto. - Sin enriquecimiento. Ni consulta de ASN o de proveedor de alojamiento, ni threat intelligence. Así todo sigue funcionando sin conexión, pero las IP las valoras tú.
- Límite de la tabla. La tabla de eventos muestra los primeros 100.000 eventos. Se analizan todos, y las notas de cobertura indican cuándo la tabla está truncada.
- El veredicto «Ningún indicio de compromiso» significa «ninguna regla ha saltado con estos logs», no «no hay compromiso». Las notas de cobertura te dicen qué reglas estaban ciegas.
Facilita la próxima investigación
- Haz streaming del registro de auditoría a un almacenamiento que controles, con una retención superior a 180 días.
- Activa la visualización de las direcciones IP.
- Ajusta la retención de los logs de Actions para que cubra tu retraso de detección, y reenvía los logs de los runners autoalojados.
- Exporta y archiva los eventos Git ante cualquier sospecha. Siete días pasan volando.
- Guarda una exportación mensual de referencia para que «país nuevo» tenga un historial con el que comparar.
Preguntas frecuentes
¿Cuánto tiempo conserva GitHub el registro de auditoría?
Los eventos de auditoría de organización y de empresa se muestran para los últimos 180 días. Los eventos Git se conservan siete días. La API devuelve por defecto los últimos tres meses, salvo que añadas un calificador created. Hacer streaming a tu propio almacenamiento es la forma de conservar más.
¿El registro de auditoría de GitHub está disponible en los planes Free y Team?
Los propietarios de organizaciones de cualquier plan pueden ver y exportar el registro de auditoría de la organización desde la interfaz web. Las API REST y GraphQL del registro de auditoría, los eventos Git, el streaming del registro de auditoría, las listas de IP permitidas y el SSO SAML requieren GitHub Enterprise Cloud.