Acerca de esta guía
En esta guía se describen los cambios de mayor impacto que puede realizar para mejorar la seguridad del código. Cada sección detalla un cambio que puedes hacer a tus procesos para mejorar la seguridad. Los cambios de mayor impacto se enumeran primero.
¿Cuál es el riesgo?
Entre los principales riesgos del proceso de desarrollo se incluyen los siguientes:
- Uso de dependencias con vulnerabilidades de seguridad que un atacante podría aprovechar.
- Filtrado de credenciales de autenticación o un token que un atacante podría usar para acceder a los recursos.
- Introducción de una vulnerabilidad en el código propio que un atacante podría aprovechar.
Estos riesgos abren los recursos y proyectos a los ataque y esos riesgos pasan directamente a cualquiera que use un paquete que cree. En las secciones siguientes se explica cómo puede protegerse a sí mismo y a los usuarios de estos riesgos.
Creación de un programa de administración de vulnerabilidades para dependencias
Puede proteger el código del que depende mediante la creación de un programa de administración de vulnerabilidades para las dependencias. De forma general, debe incluir procesos para asegurarse de que:
-
Crea un inventario de las dependencias.
-
Sabe cuándo hay una vulnerabilidad de seguridad en una dependencia.
-
Aplica revisiones de dependencia en las solicitudes de incorporación de cambios.
-
Evalúa el impacto de esa vulnerabilidad en el código y decide qué acción realizar.
Generación automática de inventario
Como primer paso, le interesa realizar un inventario completo de las dependencias. En el gráfico de dependencias de un repositorio se muestran las dependencias de los ecosistemas admitidos. Si realizas una comprobación en las dependencias o usas otros ecosistemas, deberás complementarlo con datos de herramientas de terceros o enumerando las dependencias manualmente. Para más información, consulta "Acerca del gráfico de dependencias."
Detección automática de vulnerabilidades en dependencias
Dependabot puede ayudarle mediante la supervisión de las dependencias y la notificación cuando contienen una vulnerabilidad conocida. Incluso puede habilitar Dependabot para generar automáticamente solicitudes de incorporación de cambios que actualicen la dependencia a una versión segura. Para más información, consulta "Acerca de las alertas Dependabot" y "Sobre las actualizaciones de seguridad de Dependabot".
Detección automática de vulnerabilidades en solicitudes de incorporación de cambios
Acción de revisión de dependencias aplica una revisión de dependencia en las solicitudes de incorporación de cambios, lo que facilita la visualización de si una solicitud de incorporación de cambios presentará una versión vulnerable de una dependencia en el repositorio. Cuando se detecta una vulnerabilidad, Acción de revisión de dependencias puede bloquear la combinación de la solicitud de incorporación de cambios. Para más información, consulta "Acerca de la revisión de dependencias".
Evaluación de la exposición al riesgo de una dependencia vulnerable
Cuando descubra que usa una dependencia vulnerable, por ejemplo, una biblioteca o un marco, debe evaluar el nivel de exposición del proyecto y determinar qué acción realizar. Normalmente, las vulnerabilidades se notifican con una puntuación de gravedad para mostrar la gravedad de su impacto. La puntuación de gravedad es una guía útil, pero no puede indicarle el impacto completo de la vulnerabilidad en el código.
Para evaluar el impacto de una vulnerabilidad en el código, también debe tener en cuenta cómo usa la biblioteca y determinar cuánto riesgo supone realmente para el sistema. Es posible que la vulnerabilidad forme parte de una característica que no usa, y puede actualizar la biblioteca afectada y continuar con el ciclo de versión normal. O bien, es posible que el código esté muy expuesto al riesgo y tenga actualizar la biblioteca afectada y enviar una compilación actualizada inmediatamente. Esta decisión depende de cómo use la biblioteca en el sistema y es una decisión que solo usted debe tomar.
Protección de los tokens de comunicación
A menudo, el código necesita comunicarse con otros sistemas por una red y necesita secretos (como una contraseña o una clave de API) para autenticarse. El sistema necesita acceso a esos secretos para ejecutarse, pero se recomienda no incluirlos en el código fuente. Esto es especialmente importante para los repositorios a los que muchas personas pueden tener acceso y crítico para los repositorios públicos.
Detección automática de secretos confirmados en un repositorio
Nota: Secret scanning está disponible para repositorios que son propiedad de una organización en GitHub Enterprise Server si la empresa tiene una licencia de GitHub Advanced Security. Para más información, consulta "Acerca del examen de secretos" y "Acerca de GitHub Advanced Security".
Nota: El administrador del sitio debe habilitar secret scanning para tu instancia de GitHub Enterprise Server para que puedas utilizar esta característica. Para obtener más información, vea «Configurar el escaneo de secretos para tu aplicativo».
Es posible que no puedas habilitar o deshabilitar secret scanning si un propietario de empresa ha establecido una directiva GitHub Advanced Security (GHAS) en el nivel empresarial. Para obtener más información, vea «Aplicación de directivas de seguridad y análisis de código de la empresa».
Puede configurar secret scanning para comprobar si hay secretos emitidos por muchos proveedores de servicios y notificarle cuándo se detecta alguno. También puede definir patrones personalizados para detectar secretos adicionales en el nivel del repositorio, la organización o la empresa. Para obtener más información, vea «Acerca del examen de secretos» y «Patrones de análisis de secretos».
Almacenamiento seguro de secretos que se usan en GitHub Enterprise Server
Además de en el código, es probable que tengas que usar secretos en otros lugares. Por ejemplo, para permitir que los flujos de trabajo de GitHub Actions o Dependabot se comuniquen con otros sistemas. Para más información sobre cómo almacenar y usar secretos de forma segura, consulta "Uso de secretos en Acciones de GitHub" y "Configuración del acceso a registros privados para Dependabot".
Mantener los patrones de programación vulnerables fuera del repositorio
Nota: Code scanning está disponible para repositorios que son propiedad de una organización en GitHub Enterprise Server. Esta característica requiere una licencia para la GitHub Advanced Security. Para obtener más información, vea «Acerca de GitHub Advanced Security».
Nota: El administrador del sitio debe habilitar code scanning para tu instancia de GitHub Enterprise Server para puedas utilizar esta característica. Para obtener más información, vea «Configurar el escaneo de código para tu aplicativo».
Es posible que no puedas habilitar o deshabilitar code scanning si un propietario de una empresa ha establecido una directiva GitHub Advanced Security (GHAS) en el nivel empresarial. Para obtener más información, vea «Aplicación de directivas de seguridad y análisis de código de la empresa».
Creación de un proceso de revisión de solicitudes de incorporación de cambios
Para mejorar la calidad y la seguridad del código, asegúrese de que todas las solicitudes de incorporación de cambios se revisen y prueben antes de combinarlas. GitHub tiene muchas características que puede usar para controlar el proceso de revisión y combinación. Para empezar, consulta "Acerca de las ramas protegidas".
Examen del código en busca de patrones vulnerables
A menudo, es difícil que los revisores detecten patrones de código no seguros sin ayuda. Además de examinar el código en busca de secretos, puede comprobar si hay patrones asociados a vulnerabilidades de seguridad. Por ejemplo, una función que no es segura para memoria o no puede aplicar escape a la entrada de usuario que podría dar lugar a una vulnerabilidad de inyección. GitHub ofrece varias maneras diferentes de abordar cómo y cuándo se examina el código. Para empezar, consulta "Acerca del examen de código".