Amazon n' CodeCatalyst est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour de plus amples informations, veuillez consulter Comment effectuer une migration depuis CodeCatalyst.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Modifier les contrôles d'origine des packages

Dans Amazon CodeCatalyst, les versions de packages peuvent être ajoutées à un référentiel de packages en les publiant directement, en les extrayant d'un référentiel en amont ou en les ingérant depuis un référentiel public externe via une passerelle. Si vous autorisez l'ajout de versions d'un package à la fois par publication directe et par ingestion depuis des référentiels publics, vous êtes vulnérable à une attaque de substitution de dépendances. Pour de plus amples informations, veuillez consulter Attaques de substitution de dépendance. Pour vous protéger contre une attaque de substitution de dépendances, configurez les contrôles d'origine des packages sur un package d'un référentiel afin de limiter la manière dont les versions de ce package peuvent être ajoutées au référentiel.

Vous devriez envisager de configurer les contrôles d'origine des packages pour que les nouvelles versions des différents packages proviennent à la fois de sources internes, telles que la publication directe, et de sources externes, telles que des référentiels publics. Par défaut, les contrôles d'origine des packages sont configurés en fonction de la manière dont la première version d'un package est ajoutée au référentiel.

Paramètres de contrôle de l'origine des colis

Les contrôles d'origine des packages vous permettent de configurer la manière dont les versions des packages peuvent être ajoutées à un référentiel. Les listes suivantes incluent les paramètres et valeurs de contrôle de l'origine des packages disponibles.

Publish

Ce paramètre permet de configurer si les versions des packages peuvent être publiées directement dans le référentiel à l'aide de gestionnaires de packages ou d'outils similaires.

En amont

Ce paramètre permet de configurer si les versions des packages peuvent être ingérées depuis des référentiels publics externes ou conservées depuis des référentiels en amont à la demande d'un gestionnaire de packages.

Paramètres de contrôle de l'origine des packages par défaut

Les contrôles d'origine des packages par défaut pour un package seront basés sur la manière dont la première version de ce package est ajoutée au référentiel de packages.

Scénarios courants de contrôle d'accès aux packages

Cette section décrit certains scénarios courants d'ajout d'une version de package à un référentiel de CodeCatalyst packages. Les paramètres de contrôle de l'origine des packages sont définis pour les nouveaux packages en fonction de la manière dont la première version du package est ajoutée.

Dans les scénarios suivants, un package interne est publié directement depuis un gestionnaire de packages vers votre référentiel, tel qu'un package que vous gérez. Un package externe est un package qui existe dans un référentiel public et qui peut être ingéré dans votre référentiel via un référentiel passerelle en amont.

Une version de package externe est publiée pour un package interne existant

Dans ce scénario, considérez un package interne, PackageA. Votre équipe publie la première version du package pour PackageA dans un référentiel de CodeCatalyst packages. Comme il s'agit de la première version de package pour ce package, les paramètres de contrôle de l'origine du package sont automatiquement définis sur Publier : Autoriser et En amont : Bloquer. Une fois le package publié dans votre référentiel, un package portant le même nom est publié dans un référentiel public connecté à votre référentiel de CodeCatalyst packages. Il peut s'agir d'une tentative d'attaque de substitution de dépendances contre le package interne ou d'une coïncidence. Quoi qu'il en soit, les contrôles d'origine des packages sont configurés pour bloquer l'ingestion de la nouvelle version externe afin de se protéger contre une attaque potentielle.

Dans l'image suivante, RePoa est votre référentiel de CodeCatalyst packages avec une connexion en amont au npm-public-registry-gateway référentiel. Votre dépôt contient les versions 1.1 et 2.1 de PackageA, mais la version 3.0 est publiée dans le référentiel public. Normalement, RePoa ingère la version 3.0 une fois que le package est demandé par un gestionnaire de packages. L'ingestion de packages étant définie sur Bloquer, la version 3.0 n'est pas ingérée dans votre référentiel de CodeCatalyst packages et n'est pas disponible pour les gestionnaires de packages qui y sont connectés.

Une version de package interne est publiée pour un package externe existant

Dans ce scénario, un package, PackageB, existe en externe dans un référentiel public que vous avez connecté à votre référentiel. Lorsqu'un gestionnaire de packages connecté à votre référentiel demande PackageB, la version du package est ingérée dans votre référentiel depuis le référentiel public. Comme il s'agit de la première version de package de PackageB ajoutée à votre référentiel, les paramètres d'origine du package sont configurés pour Publier : BLOQUER et En amont : AUTORISER. Plus tard, vous tenterez de publier une version portant le même nom de package dans le référentiel. Vous n'êtes peut-être pas au courant de l'existence du package public et essayez de publier un package indépendant portant le même nom, ou vous essayez peut-être de publier une version corrigée, ou vous essayez peut-être de publier directement la version exacte du package qui existe déjà en externe. CodeCatalyst rejette la version que vous essayez de publier, mais vous pouvez annuler explicitement le rejet et publier la version, si nécessaire.

Dans l'image suivante, RePoa est votre référentiel de CodeCatalyst packages avec une connexion en amont au npm-public-registry-gateway référentiel. Votre dépôt de packages contient la version 3.0 qu'il a ingérée depuis le référentiel public. Vous souhaitez publier la version 1.2 dans votre référentiel de packages. En général, vous pouvez publier la version 1.2 sur RePoa, mais comme la publication est définie sur Bloquer, la version 1.2 ne peut pas être publiée.

Publication d'une version corrigée d'un package externe existant

Dans ce scénario, un package, PackageB, existe en externe dans un référentiel public que vous avez connecté à votre référentiel de packages. Lorsqu'un gestionnaire de packages connecté à votre référentiel demande PackageB, la version du package est ingérée dans votre référentiel depuis le référentiel public. Comme il s'agit de la première version de package de PackageB ajoutée à votre référentiel, les paramètres d'origine du package sont configurés pour Publier : BLOQUER et En amont : AUTORISER. Votre équipe décide de publier des versions corrigées de ce package dans le référentiel. Pour pouvoir publier directement les versions des packages, votre équipe modifie les paramètres de contrôle de l'origine des packages sur Publier : AUTORISER et En amont : BLOQUER. Les versions de ce package peuvent désormais être publiées directement dans votre référentiel et ingérées à partir de référentiels publics. Une fois que votre équipe a publié les versions corrigées du package, elle rétablit les paramètres d'origine du package sur Publier : BLOQUER et En amont : AUTORISER.

Modifier les contrôles d'origine des packages

Les contrôles d'origine des packages sont configurés automatiquement en fonction de la manière dont la première version d'un package est ajoutée au référentiel de packages. Pour de plus amples informations, veuillez consulter Paramètres de contrôle de l'origine des packages par défaut. Pour ajouter ou modifier des contrôles d'origine de package pour un package dans un référentiel de CodeCatalyst packages, effectuez les étapes de la procédure suivante.

Publication et référentiels en amont

Dans CodeCatalyst, vous ne pouvez pas publier les versions de packages présentes dans des référentiels en amont accessibles ou des référentiels publics. Par exemple, supposons que vous souhaitiez publier un package lodash@1.0 npm dans un référentiel et myrepo que vous disposiez d'un référentiel en amont avec une connexion externe à npmjs.com. myrepo Envisagez les scénarios suivants.

Attaques de substitution de dépendance

Les gestionnaires de packages simplifient le processus d'empaquetage et de partage du code réutilisable. Ces packages peuvent être des packages privés développés par une organisation pour être utilisés dans ses applications, ou ils peuvent être publics, généralement des packages open source développés en dehors d'une organisation et distribués par des référentiels de packages publics. Lorsqu'ils demandent des packages, les développeurs s'appuient sur leur gestionnaire de packages pour récupérer les nouvelles versions de leurs dépendances. Les attaques de substitution de dépendances, également appelées attaques de confusion des dépendances, exploitent le fait qu'un gestionnaire de packages n'a généralement aucun moyen de distinguer les versions légitimes d'un package des versions malveillantes.

Les attaques de substitution de dépendance appartiennent à un sous-ensemble d'attaques appelées attaques contre la chaîne d'approvisionnement logicielle. Une attaque de la chaîne d'approvisionnement logicielle est une attaque qui tire parti de vulnérabilités situées n'importe où dans la chaîne d'approvisionnement logicielle.

Une attaque de substitution de dépendances peut cibler toute personne utilisant à la fois des packages développés en interne et des packages récupérés dans des référentiels publics. Les attaquants identifient les noms de packages internes, puis placent stratégiquement le code malveillant portant le même nom dans des référentiels de packages publics. Généralement, le code malveillant est publié dans un package avec un numéro de version élevé. Les gestionnaires de packages récupèrent le code malveillant à partir de ces flux publics car ils pensent que les packages malveillants sont les dernières versions du package. Cela entraîne une « confusion » ou une « substitution » entre le package souhaité et le package malveillant, ce qui entraîne la compromission du code.

Pour empêcher les attaques de substitution de dépendances, Amazon CodeCatalyst fournit des contrôles d'origine des packages. Les contrôles d'origine des packages sont des paramètres qui contrôlent la manière dont les packages peuvent être ajoutés à vos référentiels. Les contrôles sont configurés automatiquement lorsque la première version d'un nouveau package est ajoutée à un CodeCatalyst référentiel. Les contrôles peuvent garantir que les versions des packages ne peuvent pas être publiées directement dans votre référentiel et ingérées depuis des sources publiques, vous protégeant ainsi des attaques de substitution de dépendances. Pour plus d'informations sur les contrôles d'origine des packages et sur la manière de les modifier, consultezModifier les contrôles d'origine des packages.