Corrección de un secreto filtrado en el repositorio

Introducción

Los secretos, como las claves de API, los tokens y las credenciales, pueden suponer riesgos de seguridad significativos para el equipo y la organización si se exponen involuntariamente en el código base o se almacenan incorrectamente.

Debes considerar que cualquier secreto filtrado está en peligro inmediatamente y es esencial que lleves a cabo los pasos de corrección adecuados, como revocar el secreto. Simplemente quitar el secreto del código base, insertar una nueva confirmación o eliminar y volver a crear el repositorio no impide que el secreto se convierta en una vulnerabilidad.

Este procedimiento te guía por lo que debes hacer si has confirmado accidentalmente un secreto en el repositorio o si se te ha alertado de una filtración de secretos en el repositorio.

Requisitos previos

• Tienes al menos acceso de escritura al repositorio.
• Opcional: se ha habilitado Secret scanning para el repositorio.

  Nota:

  Secret scanning es gratuito para los repositorios públicos. Está disponible como parte de GitHub Advanced Security en repositorios públicos y privados en planes de GitHub Team y GitHub Enterprise Cloud.

Paso 1. Identificación del secreto y recopilación del contexto

Recopila toda la información que puedas sobre el secreto filtrado. Esto te ayudará a evaluar el riesgo y determinar el mejor curso de acción para la corrección.

1. Determina el tipo de secreto y su proveedor.
   • Por ejemplo, ¿el secreto es un GitHub personal access token (PAT), una clave de API de OpenAI o una clave privada SSH?
2. Localizar el repositorio, el archivo y la línea que contiene el secreto filtrado.
3. Identifica al propietario del secreto. Se trata de la persona o equipo que es responsable del secreto o lo ha creado.
   • Comprueba el archivo CODEOWNERS del repositorio para determinar el equipo responsable.
   • Usa git log -S para facilitar la búsqueda del historial de confirmaciones del repositorio para identificar quién ha confirmado el secreto.

Paso 2. Evaluar el riesgo

La forma de abordar la corrección la determinan los factores de riesgo asociados a la filtración de secretos.

Secret scanning puede ayudarte a evaluar el riesgo asociado a una alerta, pero si aún no has habilitado secret scanning, puedes realizar una evaluación de riesgos en función de la información disponible.

Opción 1. Secret scanning está habilitado

Revisa la alerta de secret scanning asociada a la filtración, y comprueba las etiquetas de alerta y los metadatos disponibles:

1. Comprueba el estado de validez del secreto para determinar si sigue activo. La alerta incluirá un estado que describe si el secreto está activo, inactivo o si se desconoce su validez.

   Nota:

   • Las comprobaciones de validez solo están disponibles para determinados tipos de secretos. Para comprobar si se admite el tipo de secreto, consulta Patrones de examen de secretos admitidos.
   • El proveedor de secretos es siempre la fuente de veracidad más confiable para determinar la validez de un secreto.
2. Busca la etiqueta public exposure para determinar si el secreto se ha filtrado en un repositorio público.
3. Busca la etiqueta multiple leaks para determinar si el secreto se expone en varias ubicaciones.
4. Si el secreto es un PAT deGitHub, comprueba los metadatos de la alerta para obtener información sobre cuándo se ha usado el secreto por última vez y su ámbito de acceso.
5. Evalúa qué servicios o aplicaciones dependen del secreto y considera la posibilidad de tiempo de inactividad o interrupción si revocaras inmediatamente el secreto.

Opción 2. Secret scanning no está habilitado

Si aún no has habilitado secret scanning para el repositorio, realiza una evaluación de riesgos basada en lo siguiente:

1. Comprueba la visibilidad del repositorio. ¿El repositorio es público?
2. Busca indicaciones de que el secreto se ha usado recientemente. ¿Hay confirmaciones o solicitudes de cambios recientes que hagan referencia al secreto? ¿Hay registros o trazas de auditoría que muestren que el secreto está en uso?
3. Evalúa el archivo que contiene el secreto y el contexto adyacente. ¿El secreto se usa en un script de implementación de producción (mayor riesgo) o en un archivo de prueba (menor riesgo)? ¿El secreto está asociado a una credencial de base de datos o una clave de administrador (mayor riesgo)?
4. Evalúa qué servicios o aplicaciones dependen del secreto y considera la posibilidad de tiempo de inactividad o interrupción si revocaras inmediatamente el secreto.

Paso 3. Estrategias de corrección

El siguiente paso depende de la evaluación de riesgos que hayas realizado en el paso anterior.

Actuación rápida para secretos de alto riesgo

Los escáneres automatizados pueden localizar secretos expuestos públicamente en cuestión de minutos. Pueden ser aprovechados por actores malintencionados en cuestión de horas. Cuanto más tiempo se deje expuesto un secreto activo, mayor será la posibilidad de infracciones graves.

Si el secreto es de alto riesgo (es decir, el secreto sigue activo, se expone en un repositorio público o es una credencial de producción), te recomendamos que:

1. Priorices la revocación inmediata del secreto. Consulta el Paso 4.

   Nota:

   Si te preocupa el tiempo de inactividad de los servicios, es posible que primero quieras generar un nuevo secreto con los mismos permisos, hacer que la aplicación empiece a usar el nuevo token y, después, revocar el secreto antiguo.

2. Comunícate con el propietario del secreto (identificado en el paso 1), los administradores del repositorio y los jefes de seguridad durante o después de la revocación.

Plan para secretos de riesgo medio y bajo

Si el secreto tiene un riesgo medio o bajo (es decir, el secreto ya no está activo, se expone en un repositorio privado o es una credencial de desarrollo o prueba), puedes planear la estrategia de corrección en consecuencia:

1. Con la información recopilada en el paso 1, busca el equipo responsable del secreto y avisa de la filtración del secreto.
2. Explica qué se ha filtrado y cuándo. Explica que tendrás que revocar el secreto, generar uno nuevo y que los servicios afectados necesitarán una actualización.
3. Informa a los administradores del repositorio y a los responsables de seguridad sobre la filtración, y explica las acciones de corrección necesarias o ya realizadas.
4. Planea un tiempo para la revocación y la rotación junto con el equipo adecuado para coordinar una transición sin problemas.

Es importante corregir incluso los secretos de riesgo medio o bajo, ya que pueden suponer un riesgo tanto para la seguridad como para el cumplimiento si se dejan expuestos.

Paso 4. Revocación del secreto

No basta con quitar simplemente el secreto del código base. El paso de corrección más importante es revocar el secreto con el proveedor del secreto. Al revocar el secreto, reduces drásticamente la posibilidad de que se aproveche.

1. Con la información recopilada en el paso 1, busca el sitio web o la documentación del proveedor de secretos.

2. Sigue las instrucciones del proveedor para revocar el secreto. Normalmente, esto implica iniciar sesión en el portal del proveedor y navegar a la sección donde se administra el secreto.

   Si no tienes acceso al portal del proveedor, ponte en contacto con el propietario del secreto o con el administrador del repositorio correspondiente a fin de obtener ayuda para revocar el secreto.

3. Genera un nuevo secreto, si es necesario, para reemplazar el secreto revocado. Esto suele ser necesario para restaurar la funcionalidad de los servicios que se basaban en el secreto original.

Paso 5: Identificación y actualización de los servicios afectados

A continuación, debes coordinar las actualizaciones de todos los servicios afectados que usen el secreto filtrado y actualizarlos con el nuevo secreto.

Identificar

1. Usa la búsqueda de código de GitHub para comprobar todo el código, las incidencias y las solicitudes de cambios del secreto.
   • Busca en toda la organización con org:YOUR-ORG "SECRET-STRING".
   • Busca en el repositorio mediante repo:YOUR-REPO "SECRET-STRING".
2. Comprueba las claves de implementación almacenadas del repositorio, los secretos y las variables.
   • Haz clic en "Settings" y, en "Security", haz clic en Secrets and variables o Deploy keys.
3. Comprueba si hay instancias instalados de GitHub Apps e integraciones que puedan usar el secreto.

Coordenada

1. Indica a Copilot que cree incidencias (y subincidencias) para cada tarea implicada en la actualización de un servicio afectado.
2. Si hay varias partes interesadas implicadas, crea un panel de proyecto para las incidencias con el fin de realizar el seguimiento del progreso y facilitar la comunicación.

Actualización y comprobación

1. Actualiza la aplicación con el nuevo secreto y asegúrate de que la aplicación usa correctamente la nueva credencial.

   Sugerencia

   Una forma segura de proporcionar credenciales confidenciales a la aplicación consiste en usar un almacén. Por ejemplo, puedes hacer que las credenciales confidenciales estén disponibles para las acciones y flujos de trabajo de GitHub mediante el almacén "Secrets and variables" en la página de configuración del repositorio.

2. Prueba los servicios afectados para asegurarte de que funcionan correctamente con el nuevo secreto.

Paso 6. Comprobación del acceso no autorizado

Una vez que los servicios estén de nuevo en funcionamiento, es importante comprobar si se ha producido un acceso no autorizado mientras se exponía el secreto.

1. Revisa los registros de auditoría de GitHub para ver los eventos relacionados con el secreto y su uso.

   • Registro de seguridad de tu cuenta personal. Consulta Revisar tu registro de seguridad.
   • Registro de auditoría de tu organización. Consulta Revisar el registro de auditoría de tu organización.
   • Registro de auditoría de tu empresa. Consulta Eventos de registro de auditoría de la empresa.

   Para los registros de auditoría de nivel empresarial y de la organización, puedes buscar específicamente eventos relacionados con un token de acceso. Consulta Identificación de eventos de registro de auditoría que realiza un token de acceso (organizaciones) y Identificación de eventos de registro de auditoría que realiza un token de acceso (empresas).

   El acceso a los registros de auditoría de GitHub depende de tu rol, por lo que es posible que tengas que ponerte en contacto con el propietario de la organización o con el administrador de la empresa si no tienes los permisos necesarios.

2. Revisa los registros de auditoría del proveedor de secretos.

   • Por ejemplo, para los secretos de Amazon Web Services (AWS), puedes buscar en los registros de CloudTrail intentos de acceso no autorizado mediante el secreto filtrado. Consulta ¿Qué es AWS CloudTrail? en la documentación de AWS CloudTrail.

Paso 7. Limpieza del repositorio

Aunque ya has revocado y actualizado el secreto en el código base, es posible que el secreto siga existiendo en el historial de confirmaciones del repositorio. Idealmente, deberías buscar y quitar todas las instancias del secreto del repositorio.

Pero la limpieza del historial de Git puede ser un proceso destructivo y perjudicial, ya que puede implicar la inserción forzada de cambios en el repositorio.

Junto con los responsables de seguridad del repositorio, valora con atención los efectos de limpiar el historial del repositorio en relación con tus obligaciones de cumplimiento o seguridad. Consulta Eliminación de datos confidenciales de un repositorio.

Paso 8. Resolución de la alerta

1. Para cerrar la alerta de secret scanning en el repositorio, selecciona Close as y marca la alerta como "Revoked."
2. Documenta el incidente en el sistema de administración de incidentes o la knowledge base del equipo, incluidos los pasos realizados para corregir la filtración y las lecciones aprendidas.

Paso 9. Evitar filtraciones adicionales

El control de filtraciones de secretos suele ser perjudicial, complicado y lento. El enfoque para el control de secretos siempre debe estar en evitar filtraciones a toda costa:

1. Asegúrate de que la protección contra inserción (parte de GitHub Advanced Security) está habilitada para el repositorio, si aún no lo está. Explora la implementación de controles de omisión estrictos para que solo los usuarios de confianza puedan omitir la protección contra inserción. Consulta Acerca de la protección de inserción.
2. Asegúrate de que has habilitado la opción "Push protection for users" en tu cuenta personal, lo que te protege de la inserción accidental de secretos admitidos en cualquier repositorio público.
3. Promueve, o implementa, procedimientos recomendados para la administración de secretos dentro de tu equipo u organización:
   • Usa variables de entorno para almacenar secretos en lugar de codificarlos de forma rígida en el código base.
   • Usa herramientas de administración de secretos como el almacén "Secrets and variables" de GitHub en la página de configuración del repositorio para almacenar y administrar secretos de forma segura.
   • Gira periódicamente los secretos para minimizar el impacto de las posibles filtraciones.
4. Documenta los incidentes y los pasos de corrección para ayudar a tu equipo a aprender de errores anteriores y mejorar las prácticas futuras.
5. Promueve el aprendizaje y el entrenamiento de seguridad periódicos, y participa en ellos. Por ejemplo, consulta el curso Seguridad avanzada de GitHub de Microsoft Learn.

Información adicional

• Acerca del examen de secretos
• Acerca de la protección de inserción
• Patrones de examen de secretos admitidos
• Acerca de GitHub Advanced Security