Procedimientos recomendados para proteger el código en la cadena de suministro

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:

1. Crea un inventario de las dependencias.

2. Sabe cuándo hay una vulnerabilidad de seguridad en una dependencia.

3. Aplica revisiones de dependencia en las solicitudes de incorporación de cambios.

4. 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 sincroniza las dependencias o usa otros ecosistemas, tendrá que complementarlo con datos de herramientas de terceros, o bien enumerar las dependencias manualmente. Si tienes al menos acceso de lectura al repositorio, puedes exportar el gráfico de dependencias del repositorio como una la lista de materiales de software (SBOM) compatible con SPDX, a través de la interfaz de usuario de GitHub o la API REST de GitHub. Para más información, consulta Exportación de una lista de materiales de software para el repositorio.

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 [AUTOTITLE](/code-security/dependabot/dependabot-alerts/about-dependabot-alerts) y [AUTOTITLE](/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates).

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 al repositorio. Cuando se detecta una vulnerabilidad, Acción de revisión de dependencias puede bloquear la solicitud de extracción de la combinación. Para más información, consulta [AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#the-dependency-review-action).

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

Si su organización usa GitHub Advanced Security, puede habilitar escaneo de secretos en cualquier repositorio propiedad de la organización, incluidos los repositorios privados. Además, escaneo de secretos está disponible disponibles y en beta en los repositorios propiedad del usuario en GitHub.

También puede definir patrones personalizados para detectar secretos adicionales en el nivel del repositorio, la organización o la empresa. Para más información, consulta Acerca de las alertas de examen de secretos.

Almacenamiento seguro de secretos que utilizas en GitHub

Además de tu código, probablemente necesites usar secretos en otros lugares. Por ejemplo, para permitir GitHub Actions flujos de trabajo o Dependabot comunicarse 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

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 tanto el cómo como el cuándo examinas tu código. Para empezar, consulta Acerca del examen de código.

Pasos siguientes

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview)
  

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-accounts)
  

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds)