Prácticas recomendadas para una cadena de suministro de software seguro

El código abierto es omnipresente. Está en muchos códigos base propietarios y en proyectos de la comunidad. En el caso de organizaciones e individuos, la pregunta actual no es tanto si se usa el código abierto, sino qué código abierto se usa y en qué medida.

Si desconoce lo que hay en la cadena de suministro de software, una vulnerabilidad de nivel superior en una de las dependencias puede ser grave, lo que hace que usted y los clientes sean vulnerables a posibles riesgos. En este documento, se profundizará en el término "cadena de suministro de software", su importancia y cómo puede ayudar a proteger la cadena de suministro del proyecto mediante procedimientos recomendados.

Dependencias

El término "cadena de suministro de software" se usa para hacer referencia a todo lo que entra en el software y su procedencia. La cadena de suministro de software depende de las dependencias y de sus propiedades. Una dependencia es lo que debe ejecutar el software. Puede ser código, archivos binarios u otros componentes, y su procedencia, como un repositorio o un administrador de paquetes.

Incluye quién ha escrito el código, cuándo se ha contribuido, cómo se ha revisado en busca de problemas de seguridad, las vulnerabilidades conocidas, las versiones admitidas, la información de licencia y todo lo que la toca en cualquier momento del proceso.

La cadena de suministro también abarca otros elementos de la pila más allá de una sola aplicación, como los scripts de compilación y empaquetado, o bien el software que ejecuta la infraestructura en la que se basa la aplicación.

Vulnerabilidades

En la actualidad, las dependencias de software son generalizadas. Es muy habitual que en los proyectos se usen cientos de dependencias de código abierto para la funcionalidad que no se ha tenido que escribir personalmente. Esto puede significar que la mayor parte de la aplicación se compone de código que no ha creado.

Las posibles vulnerabilidades en las dependencias de terceros o de código abierto son, supuestamente, las que no puede controlar de forma tan estricta como en el código que escribe, lo que puede crear posibles riesgos de seguridad en la cadena de suministro.

Si una de estas dependencias tiene una vulnerabilidad, lo más probable es que usted también tenga una vulnerabilidad. Esto puede resultar terrible, ya que una de las dependencias puede cambiar sin que lo sepa. Incluso si actualmente existe una vulnerabilidad en una dependencia, pero no se usa de forma malintencionada, en el futuro se usará.

Poder aprovechar el trabajo de miles de desarrolladores de código abierto y creadores de bibliotecas significa que miles de extraños pueden colaborar de forma eficaz directamente en el código de producción. El producto, a través de la cadena de suministro de software, se ve afectado por vulnerabilidades sin revisar, errores inocentes o incluso ataques malintencionados contra las dependencias.

Ataques a la cadena de suministro

La definición tradicional de una cadena de suministro procede de la fabricación; es la cadena de procesos necesarios para crear algo y suministrarlo. Incluye los procesos de planificación, suministro de materiales, fabricación y venta al por menor. Una cadena de suministro de software es similar, pero consta de código, y no de materiales. En lugar de fabricación, se trata de desarrollo. En lugar de profundizar desde el principio, el código se obtiene de proveedores (comerciales o de código abierto) y, en general, el código abierto proviene de repositorios. Agregar código desde un repositorio significa que el producto toma una dependencia de ese código.

Un ejemplo de ataque de cadena de suministro de software se da cuando se agrega intencionadamente código malintencionado a una dependencia y se usa la cadena de suministro de dicha dependencia para distribuir el código entre las víctimas. Los ataques de la cadena de suministro son reales. Hay muchos métodos para atacar una cadena de suministro: insertar directamente código malintencionado como colaborador nuevo, apropiarse de la cuenta de un colaborador sin que otros usuarios lo noten o poner en peligro una clave de firma para distribuir software que oficialmente no forma parte de la dependencia.

Un ataque de la cadena de suministro de software no suele ser el objetivo final, sino que es el principio de una oportunidad para que un atacante inserte malware o proporcione una puerta trasera para el acceso futuro.

Software sin revisar

Hoy en día, el uso de código abierto es significativo y no se espera que se ralentice a corto plazo. Como el software de código abierto no se va a dejar de usar, la amenaza para la seguridad de la cadena de suministro es el software sin revisar. Por tanto, ¿cómo puede resolver el riesgo de que una dependencia del proyecto tenga una vulnerabilidad?

• Conviene saber lo que hay en el entorno. Para esto es necesario detectar las dependencias y las dependencias transitivas a fin de comprender sus riesgos, como los de las vulnerabilidades o las restricciones de licencia.
• Administre las dependencias. Cuando se detecta una nueva vulnerabilidad de seguridad, debe determinar si le afecta y, en caso afirmativo, realizar la actualización a la versión más reciente y la revisión de seguridad disponibles. Esto es especialmente importante para revisar los cambios que presentan nuevas dependencias o para auditar de forma periódica las más antiguas.
• Supervise la cadena de suministro. Esto se realiza mediante la auditoría de los controles que se han implementado para administrar las dependencias. Le ayudará a aplicar condiciones más restrictivas que las dependencias deben cumplir.

Trataremos las diversas herramientas y técnicas que NuGet y GitHub proporcionan, y que puede usar hoy para abordar los posibles riesgos en el proyecto.

Conocimiento de lo que hay en el entorno

Gráfico de dependencias de NuGet

📦 Consumidor de paquetes

Puede ver las dependencias de NuGet en el proyecto si examina directamente el archivo del proyecto correspondiente.

Se suele encontrar en uno de los dos lugares siguientes:

• packages.config: en la raíz del proyecto.
• <PackageReference>: en el archivo del proyecto.

En función del método que use para administrar las dependencias de NuGet, también puede utilizar Visual Studio para verlas directamente en el Explorador de soluciones o en el Administrador de paquetes NuGet.

En los entornos de CLI, puede usar el comando dotnet list package para enumerar las dependencias del proyecto o de la solución.

Para obtener más información sobre la administración de dependencias de NuGet, vea la documentación siguiente.

Gráfico de dependencias de GitHub

📦 Consumidor de paquetes | 📦🖊 Creador de paquetes

Puede usar el gráfico de dependencias de GitHub para ver los paquetes de los que depende el proyecto, así como los repositorios que dependen de él. Esto puede ayudarle a ver las vulnerabilidades detectadas en sus dependencias.

Para obtener más información sobre las dependencias del repositorio de GitHub, vea la documentación siguiente.

Versiones de las dependencias

📦 Consumidor de paquetes | 📦🖊 Creador de paquetes

Para garantizar una cadena de dependencias segura, querrá asegurarse de que todas las dependencias y las herramientas se actualizan de forma periódica a la versión estable más reciente, ya que a menudo incluirán la funcionalidad y las revisiones de seguridad más recientes para las vulnerabilidades conocidas. Las dependencias pueden incluir código del que dependa, archivos binarios que utilice, herramientas que use y otros componentes. Esto puede incluir:

• Visual Studio
• Entorno de ejecución y SDK de .NET
• NuGet
• Paquetes de NuGet

Administración de las dependencias

Dependencias de NuGet en desuso y vulnerables

📦 Consumidor de paquetes | 📦🖊 Creador de paquetes

Puede usar la CLI de dotnet para obtener una lista de las dependencias conocidas vulnerables o en desuso que puede incluir el proyecto o la solución. Puede usar los comandos dotnet list package --deprecated o dotnet list package --vulnerable para proporcionar una lista de las vulnerabilidades o los elementos en desuso conocidos.

Dependencias vulnerables de GitHub

📦 Consumidor de paquetes | 📦🖊 Creador de paquetes

Si el proyecto se hospeda en GitHub, puede aprovechar la seguridad de GitHub para encontrar vulnerabilidades de seguridad y errores en el proyecto, y Dependabot los corregirá mediante la apertura de una solicitud de incorporación de cambios en el código base.

La detección de dependencias vulnerables antes de que se introduzcan es un objetivo del movimiento de "desplazamiento a la izquierda". Para ayudarle a hacerlo es recomendable poder tener información sobre las dependencias, como sus licencias, las dependencias transitivas y la antigüedad de las dependencias.

Para obtener más información sobre las alertas de Dependabot y las actualizaciones de seguridad, vea la documentación siguiente.

Fuentes de NuGet

📦 Consumidor de paquetes

Cuando se usan varias fuentes de origen de NuGet públicas y privadas, se puede descargar un paquete desde cualquiera de ellas. Para asegurarse de que la compilación es predecible y segura contra ataques conocidos, como la confusión de dependencias, un procedimiento recomendado consiste en conocer de qué fuentes concretas proceden los paquetes. Puede usar una fuente única o una fuente privada con funciones ascendentes para la protección.

Para obtener más información sobre cómo proteger las fuentes de paquetes, vea 3 formas de mitigar los riesgos al usar fuentes de paquetes privadas.

Al usar un feed privado, consulte los procedimientos recomendados de seguridad para administrar las credenciales.

Directivas de confianza de cliente

📦 Consumidor de paquetes

Hay directivas que se pueden activar en las que se exige que los paquetes que usa estén firmados. Esto le permite confiar en el creador de un paquete, siempre y cuando esté firmado por el creador, o bien confiar en un paquete si es propiedad de un usuario o una cuenta específicos que está firmado por NuGet.org.

Para configurar directivas de confianza de cliente, vea la documentación siguiente.

Archivos de bloqueo

📦 Consumidor de paquetes

Los archivos de bloqueo almacenan el hash del contenido del paquete. Si el hash de contenido de un paquete que quiere instalar coincide con el archivo de bloqueo, garantizará la repetibilidad del paquete.

Para habilitar los archivos de bloqueo, vea la documentación siguiente.

Asignación de origen del paquete

📦 Consumidor de paquetes

La asignación de origen del paquete le permite declarar de forma centralizada desde qué origen debe restaurar cada paquete de su solución en su archivo nuget.config.

Para habilitar la asignación de origen del paquete, consulte la documentación siguiente.

Supervisión de la cadena de suministro

Escaneo de secretos de GitHub

📦🖊 Creador de paquetes

GitHub examina los repositorios en busca de claves de API de NuGet para evitar usos fraudulentos de secretos que se hayan confirmado accidentalmente.

Para obtener más información sobre el examen de secretos, vea Información sobre el examen de secretos.

Firma del creador del paquete

📦🖊 Creador de paquetes

La firma del creador permite que el creador del paquete plasme su identidad en un paquete y que un consumidor compruebe que procede de usted. Esto le protege contra la alteración del contenido, y sirve como un origen único de verdad sobre el origen y la autenticidad del paquete. Cuando se combina con directivas de confianza de cliente, puede comprobar que un paquete proviene de un creador específico.

Para crear una firma de un paquete, vea Firma de un paquete.

Compilaciones reproducibles

📦🖊 Creador de paquetes

Las compilaciones reproducibles crean archivos binarios que son idénticos byte a byte cada vez que se compilan, y contienen vínculos de código fuente y metadatos del compilador que permiten a un consumidor de paquetes volver a crear el binario directamente y validar que el entorno de compilación no se haya puesto en peligro.

Para obtener más información sobre las compilaciones reproducibles, consulte Producing Packages with Source Link (Generación de paquetes con vínculo de origen) y la especificación Reproducible Build Validation (Validación de compilación reproducible).

Autenticación en dos fases (2FA)

📦🖊 Creador de paquetes

Cada cuenta de nuget.org tiene habilitada la 2FA. Esto agrega una capa adicional de seguridad al iniciar sesión en la cuenta de GitHub o en la cuenta de NuGet.org.

Reserva de prefijo de identificador de paquete

📦🖊 Creador de paquetes

Para proteger la identidad de los paquetes, puede reservar un prefijo de identificador de paquete con el espacio de nombres correspondiente para asociar un propietario coincidente si el prefijo del identificador del paquete coincide con los criterios especificados.

Para obtener información sobre cómo reservar prefijos de identificador, vea Reserva de prefijos de identificador de paquete.

Desuso y descarte de un paquete vulnerable

📦🖊 Creador de paquetes

Para proteger el ecosistema de paquetes de .NET cuando identifique una vulnerabilidad en un paquete que ha creado, debe esforzarse por dejar el paquete en desuso y quitarlo de la lista, de modo que esté oculto para los usuarios que buscan paquetes. Evite usar un paquete que esté en desuso y que no aparezca en la lista.

Para obtener información sobre cómo dejar de usar un paquete y quitarlo de la lista, vea la documentación siguiente sobre cómo dejar de usar paquetes y quitarlos de la lista.

Resumen

La cadena de suministro de software es todo lo que entra o afecta al código. Aunque los peligros de la cadena de suministro son reales y cada vez más conocidos, siguen siendo poco frecuentes, por lo que lo más importante que puede hacer es proteger la cadena de suministro, para lo que debe conocer las dependencias, administrarlas y supervisar la cadena de suministro.

Ha obtenido información sobre los distintos métodos que se proporcionan en NuGet y GitHub, y que están disponibles hoy en día para mejorar la eficacia a la hora de examinar, administrar y supervisar la cadena de suministro.

Para obtener más información sobre cómo proteger el software del mundo, vea el informe de seguridad The State of the Octoverse 2020.