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 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

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

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".

Pasos siguientes

• "Protección de la cadena de suministro de un extremo a otro"

• "Procedimientos recomendados para proteger las cuentas"

• "Procedimientos recomendados para proteger el sistema de compilación"