Modification des contrôles d'origine des packages

Sur 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 à partir de référentiels publics, vous êtes vulnérable à une attaque de substitution de dépendance. Pour de plus amples informations, veuillez consulter Attaques de substitution de la dépendance. Pour vous protéger contre une attaque de substitution de dépendance, configurez les contrôles d'origine des packages sur un package dans 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 packages

Grâce aux contrôles de l'origine des packages, vous pouvez 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 d'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.

• ALLOW: Les versions des packages peuvent être publiées directement.

• BLOCK: Les versions du package ne peuvent pas être publiées directement.

En amont

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

• ALLOW: Toute version de package peut être conservée à partir d'autres CodeCatalyst référentiels configurés en tant que référentiels en amont ou ingérée à partir d'une source publique via une connexion externe.

• BLOCK: Les versions des packages ne peuvent pas être conservées à partir d'autres CodeCatalyst référentiels configurés comme des référentiels en amont ou ingérées à partir d'une source publique avec une connexion externe.

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.

• Si la première version du package est publiée directement par un gestionnaire de packages, les paramètres seront Publish : ALLOW et Upstream : BLOCK.

• Si la première version du package est ingérée à partir d'une source publique, les paramètres seront Publish : BLOCK et Upstream : ALLOW.

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 existant dans un dépôt public 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 Upstream : 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épendance 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 avec le 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 dépôt public. Normalement, RePoA ingère la version 3.0 une fois que le package a été 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 sur Publish : BLOCK et Upstream :. ALLOW Plus tard, vous essayez de publier une version portant le même nom de package dans le référentiel. Vous ne connaissez peut-être pas le package public et vous 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 avec le 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 dépôt public. Vous souhaitez publier la version 1.2 dans votre référentiel de packages. Généralement, 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 de package 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 sur Publish : BLOCK et Upstream :. ALLOW Votre équipe décide de publier les 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 en les remplaçant par Publish : ALLOW et Upstream : BLOCK. Les versions de ce package peuvent désormais être publiées directement dans votre dépôt et ingérées à partir de référentiels publics. Une fois que votre équipe a publié les versions du package corrigées, elle rétablit les paramètres d'origine du package sur Publish : BLOCK et Upstream :. ALLOW

Modification des 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.

Pour ajouter ou modifier les contrôles d'origine des packages

1. Dans le panneau de navigation, choisissez Packages.

2. Choisissez le référentiel de packages qui contient le package que vous souhaitez modifier.

3. Dans le tableau Packages, recherchez et choisissez le package que vous souhaitez modifier.

4. Sur la page récapitulative du package, choisissez Origin controls.

5. Dans Contrôles d'origine, choisissez les contrôles d'origine du package que vous souhaitez définir pour ce package. Les deux paramètres de contrôle de l'origine du package, Publish et Upstream, doivent être définis en même temps.

   • Pour autoriser la publication directe des versions du package, dans Publier, sélectionnez Autoriser. Pour bloquer la publication des versions du package, choisissez Bloquer.

   • Pour autoriser l'ingestion de packages provenant de référentiels externes et l'extraction de packages depuis des référentiels en amont, dans Sources en amont, sélectionnez Autoriser. Pour bloquer toute ingestion et extraction de versions de packages depuis des référentiels externes et en amont, choisissez Bloquer.

6. Choisissez Save (Enregistrer).

Publication et référentiels en amont

Dans CodeCatalyst, vous ne pouvez pas publier les versions de package présentes dans des référentiels en amont ou des référentiels publics accessibles. 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.

1. Les paramètres de contrôle de l'origine du package lodash sont Publish : ALLOW et Upstream : ALLOW. S'il lodash@1.0 est présent dans le référentiel en amont ou dans npmjs.com, CodeCatalyst rejette toute tentative de publication dans ce référentiel en myrepo émettant une erreur de conflit 409. Vous pouvez toujours publier une version différente, telle quelodash@1.1.

2. Les paramètres de contrôle de l'origine du package lodash sont Publish : ALLOW et Upstream : BLOCK. Vous pouvez publier n'importe quelle version lodash de dans votre référentiel qui n'existe pas encore car les versions des packages ne sont pas accessibles.

3. Les paramètres de contrôle de l'origine du package lodash sont Publish : BLOCK et Upstream : ALLOW. Vous ne pouvez publier aucune version de package directement dans votre référentiel.

Attaques de substitution de la dépendance

Les gestionnaires de packages simplifient le processus d'empaquetage et de partage de 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 il peut s'agir de packages publics, généralement 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 par substitution de dépendance appartiennent à un sous-ensemble d'attaques connues sous le nom d'attaques de la chaîne logistique logicielle. Une attaque de chaîne d'approvisionnement logicielle est une attaque qui tire parti de vulnérabilités situées à n'importe quel niveau de la chaîne d'approvisionnement logicielle.

Une attaque de substitution de dépendance peut cibler toute personne utilisant à la fois des packages développés en interne et des packages extraits de 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 dont le numéro de version est é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 provoque 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épendance, Amazon CodeCatalyst fournit des contrôles de l'origine des colis. 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. Ils peuvent garantir que les versions des packages ne peuvent pas être publiées directement dans votre référentiel et ingérées à partir de sources publiques, ce qui vous protège 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, consultezModification des contrôles d'origine des packages.