Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Edición de los controles de origen del paquete

En Amazon CodeCatalyst, las versiones de los paquetes se pueden añadir a un repositorio de paquetes publicándolas directamente, retirándolas de un repositorio anterior o incorporándolas desde un repositorio público externo a través de una puerta de enlace. Si permites que las versiones de un paquete se añadan publicándolas directamente o ingiriéndolas desde repositorios públicos, estás expuesto a un ataque de sustitución de dependencias. Para obtener más información, consulte Ataques de sustitución de dependencias. Para protegerse de un ataque de sustitución de dependencias, configura los controles de origen del paquete en un repositorio para limitar la forma en que se pueden añadir las versiones de ese paquete al repositorio.

Deberías considerar la posibilidad de configurar los controles de origen de los paquetes para que las nuevas versiones de distintos paquetes procedan tanto de fuentes internas, como la publicación directa, como de fuentes externas, como los repositorios públicos. De forma predeterminada, los controles de origen de los paquetes se configuran en función de cómo se agrega la primera versión de un paquete al repositorio.

Configuración de control de origen del paquete

Con los controles de origen de los paquetes, puede configurar cómo se pueden añadir las versiones de los paquetes a un repositorio. Las siguientes listas incluyen la configuración y los valores de control de origen de los paquetes disponibles.

Publicación

Esta configuración configura si las versiones de los paquetes se pueden publicar directamente en el repositorio mediante administradores de paquetes o herramientas similares.

Repositorios ascendentes

Esta configuración configura si las versiones de los paquetes pueden ingerirse desde repositorios públicos externos o conservarse desde repositorios originales cuando lo solicite un administrador de paquetes.

Configuración de control de origen de paquetes predeterminada

Los controles de origen de los paquetes predeterminados se basarán en la forma en que se añada la primera versión de ese paquete al repositorio de paquetes.

Escenarios comunes de control de acceso a paquetes

En esta sección se describen algunos escenarios comunes en los que se agrega una versión de paquete a un repositorio de CodeCatalyst paquetes. La configuración de control de origen del paquete se establece para los paquetes nuevos en función de cómo se añada la primera versión del paquete.

En los siguientes escenarios, un paquete interno se publica directamente desde un administrador de paquetes en su repositorio, como un paquete que usted mantiene. Un paquete externo es un paquete que existe en un repositorio público y que se puede introducir en tu repositorio a través de un repositorio de puerta de enlace en sentido ascendente.

Se publica una versión de paquete externo para un paquete interno existente

En este escenario, consideremos un paquete interno, packageA. Tu equipo publica la primera versión del paquete del paquete A en un CodeCatalyst repositorio de paquetes. Como esta es la primera versión del paquete, la configuración del control de origen del paquete se establece automáticamente en Publish: Allow and Upstream: Block. Una vez publicado el paquete en tu repositorio, se publica un paquete con el mismo nombre en un repositorio público que está conectado a tu repositorio de CodeCatalyst paquetes. Podría tratarse de un intento de ataque de sustitución de dependencias contra el paquete interno o podría ser una coincidencia. En cualquier caso, los controles de origen de los paquetes están configurados para bloquear la ingesta de la nueva versión externa y protegerse así de un posible ataque.

En la siguiente imagen, RePoA es el repositorio de CodeCatalyst paquetes con una conexión ascendente al repositorio. npm-public-registry-gateway Su repositorio contiene las versiones 1.1 y 2.1 de packageA, pero la versión 3.0 está publicada en el repositorio público. Normalmente, RePoA ingiere la versión 3.0 después de que un administrador de paquetes solicite el paquete. Como la ingesta de paquetes está configurada como Bloquear, la versión 3.0 no se ingiere en su repositorio de CodeCatalyst paquetes y no está disponible para los administradores de paquetes conectados a él.

Se publica una versión de paquete interno para un paquete externo existente

En este escenario, un paquete, el paquete B, existe externamente en un repositorio público que usted ha conectado a su repositorio. Cuando un administrador de paquetes conectado a su repositorio solicita el packageB, la versión del paquete se introduce en su repositorio desde el repositorio público. Como esta es la primera versión de paquete del paquete B que se agrega a su repositorio, los ajustes de origen del paquete están configurados como Publish: y Upstream: BLOCK. ALLOW Más adelante, intenta publicar una versión con el mismo nombre de paquete en el repositorio. Es posible que no conozcas el paquete público y estés intentando publicar un paquete no relacionado con el mismo nombre, que estés intentando publicar una versión parcheada o que estés intentando publicar directamente la versión exacta del paquete que ya existe externamente. CodeCatalyst rechaza la versión que está intentando publicar, pero puede anular el rechazo de forma explícita y publicar la versión, si es necesario.

En la imagen siguiente, RePoA es el repositorio de CodeCatalyst paquetes con una conexión ascendente al repositorio. npm-public-registry-gateway El repositorio de paquetes contiene la versión 3.0 que ingirió del repositorio público. Desea publicar la versión 1.2 en su repositorio de paquetes. Normalmente, puede publicar la versión 1.2 en RePoA, pero como la publicación está configurada como Bloquear, la versión 1.2 no se puede publicar.

Publicar una versión parcheada de un paquete externo existente

En este escenario, un paquete, el paquete B, existe externamente en un repositorio público que usted ha conectado a su repositorio de paquetes. Cuando un administrador de paquetes conectado a su repositorio solicita el packageB, la versión del paquete se introduce en su repositorio desde el repositorio público. Como esta es la primera versión de paquete del paquete B que se agrega a su repositorio, los ajustes de origen del paquete están configurados como Publish: y Upstream: BLOCK. ALLOW Tu equipo decide publicar las versiones de los paquetes parcheados de este paquete en el repositorio. Para poder publicar las versiones de los paquetes directamente, tu equipo cambia la configuración del control de origen de los paquetes a Publish: ALLOW y Upstream:. BLOCK Las versiones de este paquete ahora se pueden publicar directamente en su repositorio e ingerir desde los repositorios públicos. Una vez que su equipo publique las versiones de los paquetes parcheados, su equipo revertirá la configuración de origen del paquete a Publicar: BLOCK y Upstream:. ALLOW

Edición de los controles de origen del paquete

Los controles de origen de los paquetes se configuran automáticamente en función de cómo se agrega la primera versión de un paquete al repositorio de paquetes. Para obtener más información, consulte Configuración de control de origen de paquetes predeterminada. Para añadir o editar los controles de origen de un paquete en un repositorio de CodeCatalyst paquetes, lleve a cabo los pasos del siguiente procedimiento.

Repositorios editoriales y originales

En CodeCatalyst, no puede publicar versiones de paquetes que estén presentes en repositorios ascendentes o repositorios públicos accesibles. Por ejemplo, supongamos que desea publicar un paquete npm en un repositorio y lodash@1.0 que myrepo tiene un repositorio ascendente con una conexión externa a npmjs.com. myrepo Considere los siguientes escenarios.

Ataques de sustitución de dependencias

Los gestores de paquetes simplifican el proceso de empaquetar y compartir código reutilizable. Estos paquetes pueden ser paquetes privados desarrollados por una organización para usarlos en sus aplicaciones, o pueden ser públicos, generalmente paquetes de código abierto que se desarrollan fuera de una organización y se distribuyen en repositorios de paquetes públicos. Al solicitar paquetes, los desarrolladores confían en su administrador de paquetes para obtener nuevas versiones de sus dependencias. Los ataques de sustitución de dependencias, también conocidos como ataques de confusión de dependencias, aprovechan el hecho de que un administrador de paquetes normalmente no tiene forma de distinguir las versiones legítimas de un paquete de las versiones maliciosas.

Los ataques de sustitución de dependencias pertenecen a un subconjunto de ataques conocidos como ataques a la cadena de suministro de software. Un ataque a la cadena de suministro de software es un ataque que aprovecha las vulnerabilidades en cualquier punto de la cadena de suministro de software.

Un ataque de sustitución de dependencias puede dirigirse a cualquier persona que utilice tanto paquetes desarrollados internamente como paquetes extraídos de repositorios públicos. Los atacantes identifican los nombres de los paquetes internos y, a continuación, colocan estratégicamente el código malicioso con el mismo nombre en los repositorios de paquetes públicos. Normalmente, el código malicioso se publica en un paquete con un número de versión alto. Los administradores de paquetes obtienen el código malicioso de estas fuentes públicas porque creen que los paquetes maliciosos son las últimas versiones del paquete. Esto provoca una «confusión» o una «sustitución» entre el paquete deseado y el paquete malicioso, lo que hace que el código quede comprometido.

Para evitar los ataques de sustitución de dependencias, Amazon CodeCatalyst proporciona controles de origen de los paquetes. Los controles de origen de los paquetes son ajustes que controlan cómo se pueden añadir los paquetes a tus repositorios. Los controles se configuran automáticamente cuando se añade la primera versión de un paquete nuevo a un CodeCatalyst repositorio. Los controles pueden garantizar que las versiones de los paquetes no puedan publicarse directamente en su repositorio ni ingerirse desde fuentes públicas, lo que le protege de los ataques de sustitución de dependencias. Para obtener más información sobre los controles de origen de los paquetes y cómo cambiarlos, consulte Edición de los controles de origen del paquete.