Credenciales filtradas: qué comprobar antes de cerrar el informe

Un informe de credenciales filtradas se puede cerrar cuando puedes explicar qué detuvo la exposición, qué invalidó el secreto anterior, qué evita que se repita y qué has comprobado para detectar usos indebidos. Registra por separado las pruebas y el trabajo pendiente. Restringir el acceso a una página de descarga o completar un despliegue solo responde a una parte de esas preguntas.

No necesitas un gran departamento de respuesta a incidentes. Basta con una persona responsable del informe que distinga una acción terminada de un resultado verificado y una nota de cierre que cualquier compañero entienda sin releer cinco conversaciones.

¿Qué enseña el caso de Baseten sobre el cierre de informes?

Retirar el acceso público e invalidar una credencial son acciones distintas. Una conversación reciente en Hacker News ofrece un ejemplo concreto, aunque el incidente ocurrió antes.

En un artículo del 1 de septiembre, Strix describió cómo encontró en julio un token de GitHub operativo dentro de una imagen de contenedor de Baseten. Según su cronología, el informe llegó el 13 de julio. Baseten restringió el acceso al proyecto del registro a la mañana siguiente, pero Strix indicó que el token seguía funcionando. Esa misma tarde, el equipo de seguridad de Baseten confirmó la rotación. El artículo elogia la respuesta del equipo y sitúa el cierre de los hallazgos restantes el 17 de julio. No describe ninguna comprobación independiente del token posterior a la rotación. Lee el relato de Strix.

La conversación en HN volvió a dar visibilidad al artículo. La lección procede de un incidente de julio que se ha hecho público; no estamos afirmando que haya habido una nueva brecha.

Para coordinar la respuesta, conviene preguntar: ¿qué significa exactamente «resuelto» en tu informe? La persona responsable de infraestructura puede referirse a que la descarga está bloqueada. Quien gestiona las identidades puede querer decir que la credencial ya no funciona. Mientras tanto, quien coordina el incidente quizá siga analizando qué ocurrió antes de ambos cambios.

Asigna una persona responsable a cada comprobación de cierre

Comprueba por separado cuatro aspectos de un informe de credenciales filtradas. Es nuestra recomendación de trabajo, no una norma formal ni una promesa de que todos los incidentes sigan la misma secuencia.

La contención y la investigación pueden avanzar a la vez. No esperes a tener un informe impecable para actuar con urgencia. La tabla sirve para registrar el trabajo a medida que avanza, no para crear una cola en la que una persona tenga que esperar a otra.

En una startup pequeña, una misma persona puede desempeñar varias funciones. Aun así, anota su nombre junto a cada respuesta. Esto facilita el relevo si el incidente se alarga hasta un cambio de turno, unas vacaciones o el último día de un colaborador externo.

Acordad quién toma la decisión final de cierre. La persona responsable del informe debe reunir las respuestas, sin dar por hecho un cambio que el administrador de la credencial aún no haya confirmado.

Elimina la exposición sin confundir la limpieza con la revocación

Describe la retirada del material expuesto con un alcance concreto: un archivo, una imagen, un registro o un endpoint ya no está disponible para quienes antes podían obtenerlo. Anota qué vía has comprobado y qué contenido servía.

Para una imagen de contenedor, incluye un identificador estable además de la etiqueta legible. Para un registro publicado, identifica la ejecución y la vía de acceso. Esta es nuestra recomendación para documentar el trabajo: «el registro es privado» aporta menos a quien lo revise después que la identificación de la imagen y una descripción de la comprobación de acceso.

La guía de GitHub sobre datos sensibles antepone la revocación o rotación del secreto a la limpieza del historial del repositorio. También explica que reescribir el historial tiene costes y puede ser innecesario una vez eliminado el riesgo de acceso. Esa guía se refiere a repositorios Git; la distinción entre invalidar una credencial y eliminar sus copias también ayuda a analizar otros artefactos. Guía de GitHub para eliminar datos sensibles.

No impongas una condición de cierre imposible que exija demostrar que ha desaparecido cada copia de internet. Documenta, en cambio, la decisión sobre la limpieza. ¿Una copia restante puede revelar código fuente, información de clientes u otro secreto? Si es así, revocar esta credencial no resuelve esas otras exposiciones.

Conserva las pruebas necesarias para la investigación en un lugar de acceso restringido mientras eliminas las copias innecesarias. El informe público, la conversación con el investigador y el registro interno del incidente no necesitan contener lo mismo. Identifica la credencial mediante una referencia interna; no pegues su valor completo en cada actualización.

Las comprobaciones deben limitarse a lo que tienes autorizado. Un informe sobre tu servicio no te da permiso automáticamente para probar los sistemas de un proveedor. Nuestra guía sobre el alcance de los escaneos de seguridad explica cómo fijar ese límite antes de empezar.

Demuestra que la credencial anterior ya no es válida

Para cerrar el informe, pregunta por la credencial que se filtró. «Hemos creado un token nuevo» y «el token anterior ya no permite autenticarse» son afirmaciones distintas.

GitHub documenta que los tokens revocados o caducados ya no pueden autenticar solicitudes de Git ni de la API. También indica que puede aparecer un evento de eliminación de autorización en el registro de seguridad. El registro del proveedor es, por tanto, una prueba útil, pero la documentación no garantiza que todas las situaciones generen el mismo evento visible. Caducidad y revocación de tokens en GitHub.

Pide a la persona responsable de la credencial que anote el proveedor, el identificador, la hora de revocación y el método de confirmación. Cuando corresponda, un responsable autorizado puede hacer una comprobación acotada mediante un procedimiento aprobado. Lo esencial es distinguir entre la confirmación del proveedor, un resultado de autenticación observado y una suposición de un compañero.

No añadas la exigencia de una nueva prueba externa. Puede que el investigador no esté disponible o que no tenga permiso para enviar más solicitudes. Tu equipo sigue siendo responsable de obtener pruebas suficientes a través de sus propios administradores y sistemas.

La guía de gestión de secretos de OWASP trata la revocación, la sustitución y la eliminación como acciones diferentes dentro de la respuesta a incidentes. Recomienda contener el incidente con rapidez y poder determinar el estado de revocación. Usa esa distinción al planificar el cambio: restablecer un servicio dependiente es trabajo operativo; neutralizar la credencial filtrada es el resultado de seguridad. Guía de gestión de secretos de OWASP.

Indica expresamente cualquier periodo de transición en el que funcionen ambas credenciales. Asígnale una persona responsable y una condición de finalización. Que la aplicación funcione correctamente no sustituye a la confirmación de que la credencial anterior ha quedado invalidada.

Cambia el proceso que causó la filtración

La credencial de sustitución necesita una vía más segura para llegar a la aplicación o a la compilación. De lo contrario, la siguiente versión podría repetir el mismo problema con un secreto nuevo.

Docker advierte contra el uso de argumentos de Dockerfile o variables de entorno para pasar secretos a la compilación, porque pueden persistir en la imagen final. Recomienda los montajes de secretos, que ponen las credenciales temporalmente a disposición de una instrucción de compilación. Guía de Docker sobre secretos de compilación.

La comprobación SecretsUsedInArgOrEnv también señala que pueden persistir en los metadatos de la imagen. Es un buen motivo para inspeccionar el resultado de la compilación, además de revisar la línea de código modificada. Referencia de la comprobación de Docker.

Recomendamos que la nota de aceptación cubra dos puntos: qué cambió en la gestión de secretos y qué se comprobó en el resultado de sustitución. Una revisión de código permite evaluar si el cambio parece correcto. Revisar el archivo o la imagen recién generados permite comprobar si ese resultado concreto contiene el problema que se pretendía eliminar.

Adapta la comprobación a la filtración. Si una compilación escribió URL con credenciales en la configuración, examina ese resultado. Si un proceso de publicación expuso sus variables de entorno, examina el registro resultante y quién puede acceder a él. Evita una nota genérica como «el escáner no detectó problemas» sin indicar su alcance ni el material que examinó.

Reconsidera también qué acceso necesita la credencial de sustitución. GitHub recomienda GitHub Apps para actuar en nombre de una organización o para integraciones de larga duración. Si sigues usando un token de acceso personal, elige sus permisos y su duración de forma deliberada; cambiar el tipo de credencial no demuestra, por sí solo, que el acceso sea adecuado. Guía de GitHub sobre tokens de acceso personal.

Puede quedar trabajo más amplio de refuerzo de la seguridad tras corregir el defecto inmediato. Sepáralo de lo que afirmas al cerrar el informe. «La compilación afectada está corregida; Maya revisará los demás pipelines de compilación para el viernes» es una decisión útil. «Toda la gestión de secretos es ahora segura» no se sostiene con ese trabajo.

Revisa el impacto y explicita los límites

Revocar una credencial resuelve si esta puede seguir dando acceso. No explica qué ocurrió mientras era válida.

La guía de investigación de incidentes de GitHub recomienda examinar en el registro de auditoría la actividad asociada al token comprometido y a actores inesperados, además de los hallazgos pertinentes sobre la exposición. También advierte de que un incidente puede pasar de un vector de ataque a otro, por lo que el hallazgo de una credencial puede llevar a ampliar la investigación. Áreas de investigación de GitHub.

Para el registro de cierre, recomendamos una breve descripción del alcance de la revisión. Indica los sistemas revisados, el periodo disponible, quién los revisó y el resultado. Añade lo que no se pudo determinar. El lector no debería tener que deducir si «nada sospechoso» significa una semana de registros completos o unas horas de registros parciales.

Separa las observaciones de las conclusiones. Puedes no encontrar actividad inesperada en los registros disponibles y, aun así, carecer de información sobre parte del periodo de exposición. Escribe ambas cosas. Explicar esa limitación permite a la persona responsable del incidente decidir si hace falta más trabajo.

Ten en cuenta los permisos que tenía la credencial al decidir dónde buscar. El acceso a la configuración de despliegue plantea preguntas distintas al acceso de solo lectura a un único paquete. Anota por qué elegiste ese alcance para que quien revise el caso después pueda cuestionarlo sin repetir toda la investigación.

Si la investigación descubre otro problema, asígnale una persona responsable y una referencia propias. Cerrar el informe original de exposición no debería hacer desaparecer un incidente que sigue abierto en otro lugar. Del mismo modo, no mantengas abierto indefinidamente un informe de un investigador cuyo problema concreto ya se ha resuelto sin explicar qué otra decisión está pendiente.

Escribe una nota de cierre que otra persona pueda revisar

Una buena nota de cierre expone el resultado, las pruebas y el trabajo pendiente. Debe ser breve para facilitar el relevo y concreta para permitir una revisión crítica.

GitHub refleja esta distinción en su propio proceso de alertas: eliminar un token del repositorio no cierra automáticamente la alerta de detección de secretos. Su guía también contempla un comentario de cierre que pasa a formar parte de la cronología de la alerta. Resolver alertas de detección de secretos.

Este es un ejemplo ficticio. La organización, los identificadores, las horas y los hallazgos se han inventado para mostrar el formato; no describen a Baseten ni a ningún cliente de Kit.

Informe: Credencial de compilación expuesta en el artefacto release-184.

Exposición: Lena restringió el acceso al artefacto afectado a las 10:15 UTC. Una comprobación autorizada confirmó que la vía pública descrita en el informe ya no lo servía. Se revisaron otros artefactos en la tarea de inventario enlazada.

Credencial anterior: Arun revocó la credencial build-reader-previous a las 10:18 UTC. El registro del proveedor y el resultado de la validación aprobada se guardan en la carpeta del incidente, con acceso restringido. Los servicios dependientes ya usan la credencial de sustitución.

Prevención: Lena modificó la gestión de secretos de la compilación. Se inspeccionaron el artefacto de sustitución y sus metadatos en busca del patrón de filtración descrito. Las pruebas identifican el nuevo artefacto y la hora de revisión.

Impacto: Jo revisó los registros disponibles de identidades y repositorios correspondientes al periodo de exposición indicado. No se encontró ningún uso inesperado en esos registros. No se disponía de los registros de descargas anteriores del registro de contenedores, por lo que no podemos determinar quién obtuvo copias antiguas.

Decisión: Jo aprobó el cierre de este informe. La tarea enlazada para mejorar los registros sigue asignada a Arun. La comunicación con el investigador describe las medidas correctivas terminadas y los límites de la investigación sin incluir credenciales.

Fíjate en lo que la nota no afirma. No dice que hayan desaparecido todas las copias, que el investigador haya confirmado personalmente cada acción ni que una búsqueda sin hallazgos en los registros demuestre que nadie accedió al sistema.

Puedes usar los mismos encabezados como plantilla. Acepta «no aplicable» solo cuando el responsable explique el motivo. Si la credencial ya no era válida cuando se recibió el informe, por ejemplo, registra cómo se comprobó y si el artefacto expuesto contiene algo más que requiera atención.

Antes de aprobar el cierre, pide a otra persona que lea la nota si el equipo puede hacerlo. Pídele que señale una frase cuyas pruebas no estén claras. Es una sugerencia práctica para detectar ambigüedades en los relevos, no un paso obligatorio de certificación.

Guarda la decisión de cierre y la conversación juntas en Kit

Conserva el resumen de las pruebas junto al informe para explicar su estado. Cualquier compañero que lo consulte más adelante debería poder ver quién decidió que la corrección estaba verificada y qué cubría esa decisión.

El ciclo de vida de los informes de Kit registra los cambios de estado con la persona que los realiza, la fecha y hora, y un comentario opcional. Un miembro autorizado del equipo puede marcar una corrección como verificada y añadir una nota. La documentación de triaje explica el proceso.

Esta acción registra una decisión humana. Kit no revoca la credencial filtrada, no exige las cuatro comprobaciones anteriores ni requiere la confirmación del investigador antes de ese cambio de estado. Tu equipo debe reunir las pruebas y decidir cuáles son suficientes. Usa la nota para resumirlas y enlaza los registros de acceso restringido que contienen los detalles.

La conversación del informe admite tanto discusiones internas como mensajes dirigidos al investigador. Guarda los detalles técnicos de la investigación en el canal adecuado y comunica después al investigador qué medidas correctivas se han completado y si cualquier seguimiento solicitado sigue dentro del alcance autorizado. La guía de comunicación con investigadores explica esas opciones de visibilidad.

En el próximo informe de credenciales filtradas, empieza con cuatro apartados: exposición, credencial anterior, prevención e impacto. Asigna las responsabilidades mientras avanza la respuesta. Al cerrar el informe, la nota debería explicar lo que sabes sin obligar a nadie a adivinar qué significaba «resuelto».