Fase 6: Lanzamiento y escalado del análisis de secretos

Puedes habilitar el análisis de secretos para repositorios individuales o para todos los repositorios de una organización o empresa. Para más información, consulta "Administración de la configuración de seguridad y análisis para el repositorio", "Administrar la configuración de seguridad y análisis de su organización" o "Administración de las características de GitHub Advanced Security para la empresa".

En este artículo se explica un proceso de alto nivel centrado en habilitar secret scanning para todos los repositorios de una organización. Los principios que se describen en este artículo se pueden seguir aplicando incluso si adoptas el enfoque más escalonado de habilitar secret scanning para repositorios individuales.

1. Céntrate en los secretos recién confirmados

Al habilitar secret scanning, debes centrarte en corregir las credenciales recién confirmadas detectadas por el análisis de secretos. Si te centras en limpiar las credenciales confirmadas, los desarrolladores podrían seguir insertando accidentalmente nuevas credenciales, lo que significa que el recuento total de secretos permanecerá aproximadamente al mismo nivel, no disminuirá como se prevé. Por este motivo, es esencial detener la filtración de nuevas credenciales antes de centrarse en revocar los secretos actuales.

Hay algunos enfoques para abordar las credenciales recién confirmadas, pero un enfoque de ejemplo sería el siguiente:

1. Notificación: usa webhooks para asegurarte de que los equipos adecuados vean las nuevas alertas de secretos lo antes posible. Un webhook se desencadena cuando se crea, se resuelve o se vuelve a abrir una alerta de secreto. Después, puedes analizar la carga del webhook e integrarla en las herramientas que tú y tu equipo uséis, como Slack, Teams, Splunk o el correo electrónico. Para obtener más información, vea «Acerca de webhooks» y «Eventos y cargas de webhook».

2. Seguimiento: crea un proceso de corrección de alto nivel que funcione para todos los tipos de secretos. Por ejemplo, puedes ponerte en contacto con el desarrollador que confirmó el secreto y su responsable técnico en ese proyecto, resaltar los peligros de confirmar secretos en GitHub y pedirles que revoquen y actualicen el secreto detectado.

   Nota: Este paso se puede automatizar. En el caso de grandes empresas y organizaciones con cientos de repositorios, el seguimiento manual es insostenible. Puedes incorporar la automatización en el proceso de webhook definido en el primer paso. La carga del webhook contiene información sobre el repositorio y la organización acerca del secreto filtrado. Con esta información, puedes ponerte en contacto con los mantenedores actuales del repositorio y crear un correo electrónico o mensaje para las personas responsables, o bien abrir una incidencia.

3. Formación: crea un documento de formación interno asignado al desarrollador que confirmó el secreto. En este documento de formación, puedes explicar los riesgos creados mediante la confirmación de secretos y dirigirlos a la información de procedimientos recomendados sobre el uso de secretos de forma segura en el desarrollo. Si un desarrollador no aprende de la experiencia y continúa confirmando secretos, podrías crear un proceso de escalación, pero la formación suele funcionar bien.

Repite los dos últimos pasos para cualquier secreto nuevo que se haya filtrado. Este proceso anima a los desarrolladores a asumir la responsabilidad de administrar los secretos usados en su código de forma segura y te permite medir la reducción de los secretos recién confirmados.

2. Habilitación de la protección de inserción

Una vez que hayas habilitado secret scanning, también debes habilitar la protección de inserción. Con la protección de inserción, secret scanning comprueba las inserciones de secretos y bloques admitidos en GitHub antes de que los secretos se expongan a otros usuarios. Para más información sobre cómo habilitar la protección de inserción, consulta "Protección contra el envío de cambios para repositorios y organizaciones".

Una vez habilitada, puedes hacer lo siguiente:

1. Proporcionar instrucciones: configura un vínculo personalizado en el mensaje que los colaboradores verán si su inserción la bloquea secret scanning. El recurso vinculado puede proporcionar instrucciones para los colaboradores sobre cómo resolver la inserción bloqueada. Para obtener más información, vea «Protección contra el envío de cambios para repositorios y organizaciones».

2. Notificar: define un webhook que realiza un seguimiento específico de creadas cuando alguien omite la protección de inserción mediante la propiedad "push_protection_bypassed": true de la alerta. O bien, usa la API para obtener actualizaciones en las que hayan sido el resultado de una omisión de protección de inserción filtrando la lista de resultados de "push_protection_bypassed": true. Para obtener más información, vea «Auditoría de alertas de seguridad».

3. Supervisar: usa información general de seguridad para ver las métricas sobre el rendimiento de la protección de inserción en repositorios de toda la organización, de modo que puedas identificar rápidamente los repositorios en los que es posible que tengas que tomar medidas. Para obtener más información, vea «Visualización de las métricas para la protección de la inserción del examen de secretos en tu organización».

3. Corrección de los secretos confirmados previamente, empezando por el más crítico

Después de haber establecido un proceso para reducir la incorporación de secretos a los códigos base, estás a punto para empezar a trabajar a fin de corregir los secretos que se han confirmado antes de introducir GitHub Advanced Security.

La forma en que definas los secretos más críticos dependerá de los procesos e integraciones de la organización. Por ejemplo, es probable que una empresa no esté preocupada por un secreto de webhook entrante de Slack si no usa Slack. Es posible que te resulte útil empezar por centrarte en los cinco tipos de credenciales más críticos de tu organización.

Una vez que hayas decidido los tipos de secretos, puedes hacer lo siguiente:

1. Define un proceso para corregir cada tipo de secreto. El procedimiento real para cada tipo de secreto suele ser drásticamente diferente. Anota el proceso para cada tipo de secreto en un documento o knowledge base internos.

   Nota: Al crear el proceso para revocar secretos, prueba y asigna la responsabilidad de revocar los secretos al equipo que mantiene el repositorio en lugar de un equipo central. Uno de los principios de GHAS es que los desarrolladores toman posesión de la seguridad y tienen la responsabilidad de corregir los problemas de seguridad, especialmente si los han creado.

2. Cuando hayas creado el proceso que seguirán los equipos para revocar las credenciales, puedes intercalar información sobre los tipos de secretos y otros metadatos asociados a los secretos filtrados para poder determinar a quién debes comunicar el nuevo proceso.

   Puedes usar la información general de seguridad para recopilar esta información. Para más información sobre el uso de la información general de seguridad, consulta "Filtrar alertas en la información general sobre seguridad".

   Parte de la información que puede que quieras recopilar incluye la siguiente:

   • Organización
   • Repositorio
   • Tipo de secreto
   • Valor del secreto
   • Mantenedores en el repositorio con quienes ponerte en contacto

   Nota: Usa la interfaz de usuario si tienes pocos secretos filtrados de ese tipo. Si tienes cientos de secretos filtrados, usa la API para recopilar la información. Para obtener más información, vea «Puntos de conexión de la API REST para el examen de secretos».

3. Después de recopilar información sobre los secretos filtrados, crea un plan de comunicación dirigido para los usuarios que mantienen los repositorios afectados por cada tipo de secreto. Puedes usar el correo electrónico, la mensajería o incluso crear incidencias de GitHub en los repositorios afectados. Si puedes usar las API que proporcionan estas herramientas para enviar las comunicaciones de forma automatizada, esto te facilitará el escalado entre varios tipos de secretos.

3. Expansión del programa para incluir más tipos de secretos y patrones personalizados

Ahora puedes ir más allá de los cinco tipos de secretos más críticos y crear una lista más completa, con un enfoque adicional en la formación. Puedes repetir el paso anterior, corregir los secretos confirmados previamente, para los distintos tipos de secretos a los que te has dirigido.

También puedes incluir más patrones personalizados intercalados en las fases anteriores e invitar a los equipos de seguridad y a los equipos de desarrolladores a enviar más patrones, con lo que puedes establecer un proceso para enviar nuevos patrones a medida que se crean nuevos tipos de secretos. Para obtener más información, vea «Definición de patrones personalizados para el examen de secretos».

A medida que sigas compilando los procesos de corrección para otros tipos de secretos, empieza a crear material de formación proactivo que se pueda compartir con todos los desarrolladores de GitHub de tu organización. Hasta este punto, gran parte del enfoque ha sido reactivo. Es una excelente idea cambiar la atención a ser proactivo y animar a los desarrolladores a no insertar credenciales en GitHub en primer lugar. Esto se puede lograr de varias maneras, pero crear un breve documento que explique los riesgos y las razones sería un gran punto de partida.