Este artículo forma parte de una serie sobre la adopción de GitHub Advanced Security a escala. Para obtener el artículo anterior de esta serie, consulta "Fase 1: Alinear la estrategia de lanzamiento y los objetivos".
Preparación para la habilitación de code scanning
Code scanning es una característica que se usa para analizar el código en un repositorio de GitHub para buscar vulnerabilidades de seguridad y errores de código. Los problemas identificados por el análisis se muestran en el repositorio. Para más información, consulta "Acerca del examen de código".
El lanzamiento de code scanning en cientos de repositorios puede resultar difícil, sobre todo si no se hace de una forma eficaz. Si sigue estos pasos, se asegurará de que el lanzamiento sea eficaz y correcto. Como parte de la preparación, trabajará con los equipos, usará la automatización para recopilar datos sobre los repositorios y habilitar code scanning.
Preparación de los equipos para code scanning
En primer lugar, prepara a tus equipos para que usen code scanning. Cuantos más equipos usen code scanning, más datos tendrás plara generar planes de corrección y supervisar el progreso del lanzamiento. Durante esta fase, debe centrarse en aprovechar las API y en realizar eventos internos de habilitación.
El enfoque principal debe ser preparar tantos equipos como sea posible para que usen code scanning. También puedes animar a los equipos a corregir correctamente, pero se recomienda priorizar la habilitación y el uso de code scanning por encima de la corrección de incidencias durante esta fase.
Recopilación de información sobre los repositorios
Puedes recopilar información mediante programación sobre los distintos lenguajes de programación que se usan en los repositorios y usar esos datos para habilitar code scanning en todos los repositorios que usan el mismo lenguaje, mediante la GraphQL API de GitHub Enterprise Server.
Nota: Para recopilar estos datos sin ejecutar manualmente las consultas de GraphQL descritas en este artículo, puedes usar nuestra herramienta disponible públicamente. Para obtener más información, consulta el repositorio "herramienta de habilitación de GHAS".
Si quieres recopilar información de repositorios que pertenecen a varias organizaciones de la empresa, puedes usar la consulta siguiente para obtener los nombres de las organizaciones y, a continuación, introducirlos en la consulta del repositorio. Reemplaza OCTO-ENTERPRISE por el nombre de tu empresa.
query {
enterprise(slug: "OCTO-ENTERPRISE") {
organizations(first: 100) {
totalCount
nodes {
name
}
pageInfo {
endCursor
hasNextPage
}
}
}
}
Puedes identificar qué repositorios usan los lenguajes mediante la intercalación de repositorios por lenguaje en el nivel de organización. Puedes modificar la consulta de GraphQL de ejemplo siguiente, reemplazando OCTO-ORG por el nombre de la organización.
query {
organization(login: "OCTO-ORG") {
repositories(first: 100) {
totalCount
nodes {
nameWithOwner
languages(first: 100) {
totalCount
nodes {
name
}
}
}
pageInfo {
endCursor
hasNextPage
}
}
}
}
Para más información sobre la ejecución de consultas de GraphQL, consulta "Formar llamados con GraphQl".
A continuación, convierte los datos de la consulta de GraphQL en un formato legible, como una tabla.
| Idioma | Número de repositorios | Nombre de los repositorios |
|---|---|---|
| JavaScript (TypeScript) | 4212 | org/repo org/repo |
| Python | 2012 | org/repo org/repo |
| Go | 983 | org/repo org/repo |
| Java | 412 | org/repo org/repo |
| Swift | 111 | org/repo org/repo |
| Kotlin | 82 | org/repo org/repo |
| C | 12 | org/repo org/repo |
Puedes filtrar los lenguajes que actualmente no son compatibles con GitHub Advanced Security de esta tabla.
Si tienes repositorios con varios lenguajes, puedes dar formato a los resultados de GraphQL como se muestra en la tabla siguiente. Filtra los lenguajes que no se admiten, pero conserva todos los repositorios con al menos un lenguaje admitido. Puedes habilitar code scanning en estos repositorios y se analizarán todos los lenguajes admitidos.
| Idiomas | Número de repositorios | Nombre de los repositorios |
|---|---|---|
| JavaScript/Python/Go | 16 | org/repo org/repo |
| Rust/TypeScript/Python | 12 | org/repo org/repo |
Comprender qué repositorios usan qué lenguajes te ayudará a identificar los repositorios candidatos para programas piloto en la fase 3 y te preparará para habilitar code scanning en todos los repositorios lenguaje por lenguaje en la fase 5.
Habilitación de code scanning para el dispositivo
Para poder continuar con los programas piloto y el lanzamiento de code scanning en la empresa, primero debes habilitar code scanning para el dispositivo. Para obtener más información, vea «Configuración la digitalización de código para el dispositivo».
Preparación para la habilitación de secret scanning
Nota: Cuando se detecta un secreto en un repositorio que ha habilitado secret scanning, GitHub alerta a todos los usuarios con acceso a alertas de seguridad del repositorio.
Si tu proyecto se comunica con un servicio externo, puede que use un token o una clave privada para la autenticación. Si registras un secreto en un repositorio, cualquiera que tenga acceso de lectura al mismo puede utilizarlo para acceder al servicio externo con tus privilegios. Secret scanning analizará todo el historial de Git en todas las ramas presentes en los repositorios de GitHub en busca de secretos y le alertará o bloqueará la inserción que contiene el secreto. Para obtener más información, vea «Acerca del examen de secretos».
Consideraciones al habilitar secret scanning
La funcionalidad secret scanning de GitHub Enterprise Server es un poco diferente de code scanning, ya que no requiere ninguna configuración específica por lenguaje de programación o por repositorio y requiere menos configuración en general para empezar. Esto significa que habilitar secret scanning en el nivel de organización puede ser fácil, pero hacer clic en Habilitar todo en el nivel de organización y marcar la opción Habilitar secret scanning automáticamente para cada repositorio nuevo tiene algunos efectos descendentes que debes tener en cuenta:
Consumo de licencias
La habilitación de secret scanning para todos los repositorios maximizará el uso de licencias de GitHub Advanced Security. Esto es correcto si tienes suficientes licencias para los confirmadores actuales en todos esos repositorios. Si es probable que el número de desarrolladores activos aumente en los próximos meses, puede que superes el límite de licencias y que no puedas usar GitHub Advanced Security en los repositorios recién creados.
Volumen inicial de secretos detectados alto
Si habilitas secret scanning en una organización grande, prepárate para ver un número elevado de secretos detectados. A veces esto choca a las organizaciones y saltan todas las alarmas. Si quieres activar secret scanning en todos los repositorios a la vez, planea cómo responderás a varias alertas en toda la organización.
Secret scanning se puede habilitar para repositorios individuales. Para obtener más información, vea «Configuración del examen de secretos para los repositorios». Secret scanning también se puede habilitar para todos los repositorios de la organización, como se ha descrito anteriormente. Para más información sobre cómo habilitar esta opción para todos los repositorios, consulta "Administrar la configuración de seguridad y análisis de su organización".
Patrones personalizados para secret scanning
Secret scanning detecta un gran número de patrones predeterminados, pero también se puede configurar para que detecte patrones personalizados, como formatos de secreto exclusivos de tu infraestructura o usados por integradores que secret scanning de GitHub Enterprise Server actualmente no detecta. Para más información sobre los secretos admitidos para los patrones de asociados, consulta "Patrones de análisis de secretos".
A medida que auditas los repositorios y hablas con los equipos de seguridad y desarrolladores, crea una lista de los tipos de secretos que usarás más adelante para configurar patrones personalizados para secret scanning. Para obtener más información, vea «Definición de patrones personalizados para el examen de secretos».
Protección de inserción para secret scanning
La protección de inserción para organizaciones y repositorios indica a secret scanning que compruebe las inserciones de secretos admitidos antes de que los secretos se confirmen en el código base. Para más información sobre los secretos que se admiten, consulta "Patrones de análisis de secretos".
Si se detecta un secreto en una inserción, esta se bloquea. Secret scanning enumera los secretos que detecta para que el creador pueda revisarlos y quitarlos, o si es necesario, permitir que se inserten. Secret scanning también puede comprobar las inserciones para patrones personalizados.
Los desarrolladores tienen la opción de omitir la protección de inserción notificando que un secreto es un falso positivo, que se usa en las pruebas o que se corregirá más adelante.
Si un colaborador omite un bloque de protección de inserción para un secreto, GitHub:
- Crea una alerta en la pestaña Security del repositorio.
- Agrega el evento de omisión al registro de auditoría.
- Envía una alerta por correo electrónico a los propietarios de la organización o de la cuenta personal, administradores de seguridad y administradores de repositorios que están viendo el repositorio, con un vínculo al secreto y el motivo por el que se permitió.
Antes de habilitar la protección de inserción, plantéate si necesitas crear instrucciones para los equipos de desarrolladores en las condiciones aceptables para omitir la protección de inserción. Puedes configurar un vínculo a este recurso en el mensaje que se muestra cuando un desarrollador intenta insertar un secreto bloqueado.
A continuación, familiarízate con las distintas opciones para administrar y supervisar alertas que son el resultado de un colaborador que omite la protección de inserción.
Para obtener más información, vea «Protección contra el envío de cambios para repositorios y organizaciones».
Para ver el siguiente artículo de esta serie, consulta "Fase 3: Programas piloto".