Skip to main content
Publicamos actualizaciones para la documentación con frecuencia y es posible que aún se esté traduciendo esta página. Para obtener la información más reciente, consulta la documentación en inglés.

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

Instrucciones sobre cómo proteger el centro de la cadena de suministro, es decir, el código que escribes y el código del que dependes.

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. Para más información, vea "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 puedes habilitar Dependabot para generar automáticamente solicitudes de incorporación de cambios que actualicen la dependencia a una versión segura. Para obtener más información, consulta "Acerca de Dependabot alerts" y "Acerca de las actualizaciones de seguridad de Dependabot".

Detección automática de vulnerabilidades en solicitudes de incorporación de cambios

dependency review action 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, dependency review action puede bloquear la combinación de la solicitud de incorporación de cambios. Para obtener más información, consulta "Cumplimiento 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 obtener más información, consulta "Acerca de las secret scanning en GitHub Enterprise Server" y "Acerca de GitHub Advanced Security".

Nota: El administrador del sitio debe habilitar secret scanning para your GitHub Enterprise Server instance para que puedas utilizar esta característica. Para más información, consulta "Configuración de secret scanning para el dispositivo".

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 más información, vea "Acerca del examen de secretos" y "Patrones de examen 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 obtener más información sobre cómo almacenar y usar secretos de forma segura, consulta "Secretos cifrados en acciones" y "Administración de secretos cifrados 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 más información, consulte "Acerca de GitHub Advanced Security".

Nota: El administrador del sitio debe habilitar code scanning para your GitHub Enterprise Server instance para puedas utilizar esta característica. Para más información, vea "Configuración de code scanning para el dispositivo".

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, vea "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, vea "Acerca del análisis de código".

Pasos siguientes