Menaces sur la chaîne d'approvisionnement logicielle

Les vecteurs d'attaque pour les chaînes d'approvisionnement logicielles représentent les différents moyens par lesquels un tiers peut compromettre intentionnellement ou accidentellement votre logiciel.

Les risques liés aux logiciels vulnérables incluent la fuite d'identifiants ou de données confidentielles, la corruption de données, l'installation de logiciels malveillants et les pannes d'applications. Ces problèmes se traduisent par une perte de temps, d'argent et une perte de confiance des clients.

Les points d'entrée des menaces couvrent l'ensemble du cycle de vie du logiciel et peuvent provenir de l'intérieur ou de l'extérieur de votre organisation.

Schéma illustrant les points d'entrée des attaques sur la chaîne d'approvisionnement logicielle

La légende du diagramme inclut deux ensembles de menaces:

Software Delivery Shield, une solution de sécurité sur la chaîne d'approvisionnement logicielle entièrement gérée sur Google Cloud, intègre les bonnes pratiques pour vous aider à limiter ces deux types de menaces.

Les sous-sections de ce document décrivent les menaces dans le contexte de la source, des builds, du déploiement et des dépendances.

Menaces sources

Ces menaces affectent l'intégrité de votre code source.

  • 1: écrivez du code non sécurisé. L'absence de pratiques de codage sécurisées peut entraîner l'écriture involontaire du code inclut des failles. Les postes de travail des développeurs non sécurisés peuvent également introduire du code malveillant ou non sécurisé. Voici quelques solutions d'atténuation:

    • Définir des règles pour les stations de travail des développeurs. Cloud Workstations fournit des stations de travail entièrement gérées et préconfigurées que vous pouvez personnaliser en fonction de vos besoins.
    • Lecture locale du code. Cloud Code Source Protect (preview privée) fournit des informations sur la sécurité en temps réel, y compris des informations sur les failles et les licences des dépendances. Les développeurs peuvent également utiliser l'API On-Demand Scanning pour analyser les images de conteneurs afin de détecter les failles du système d'exploitation et des packages de langage.
    • Formation aux pratiques permettant de renforcer la sécurité du code

  • A: Envoyer un code incorrect au dépôt source. Cela inclut non seulement le code malveillant, mais également le code qui introduit involontairement des failles dans le cadre d'une attaque, comme les scripts intersites. Voici quelques solutions d'atténuation:

    • Nécessité d'un examen manuel pour les modifications apportées au code source
    • Utiliser des outils d'analyse de code et d'analyse lint qui s'intègrent aux IDE et aux systèmes de contrôle du code source

  • B: Compromettre le système de contrôle des sources Limiter l'accès au système de contrôle des sources et aux autres systèmes de votre pipeline de compilation, ainsi que l'utilisation de l'authentification multifacteur, permet d'atténuer ce risque.

Lors de l'évaluation de l'intégrité de votre source, examinez également les scripts et la configuration compatibles que vous utilisez pour créer et déployer votre logiciel. Incluez-les dans votre système de contrôle des sources et vos processus de révision de code afin d'éviter les failles dans ces fichiers.

Pour en savoir plus sur la protection de votre source, consultez la section Protéger la source.

Créer des menaces

Ces menaces compromettent votre logiciel lorsque vous le créez ou l'empaquetez, ou incitent les utilisateurs à utiliser une mauvaise version.

  • C: Compiler avec une source qui ne provient pas du système de contrôle des sources de confiance. Voici quelques mesures d'atténuation qui contribuent à réduire ce risque :
    • Utiliser des services de compilation, tels que Cloud Build, qui génèrent des informations de provenance afin que vous puissiez valider que vos compilations utilisent une source fiable.
    • Placer votre infrastructure CI/CD dans un périmètre réseau pour empêcher l'exfiltration des données de vos compilations Pour les services Google Cloud, utilisez VPC Service Controls.
    • Stockage et utilisation de copies de confiance des dépendances Open Source dont vous avez besoin dans un magasin d'artefacts privé tel que Artifact Registry
  • D: compromettre le système de compilation Voici quelques mesures d'atténuation qui permettent de réduire ce risque :
    • Suivez le principe du moindre privilège en limitant l'accès direct au système de compilation aux personnes qui en ont besoin. Dans Google Cloud, vous pouvez attribuer des rôles prédéfinis appropriés ou créer des rôles personnalisés.
    • Utiliser des services de compilation gérés tels que Cloud Build Cloud Build exécute des compilations éphémères en configurant un environnement de VM pour chaque build et en le détruisant après la compilation.
    • Placez votre infrastructure CI/CD dans un périmètre réseau pour empêcher l'exfiltration des données de vos builds. Pour les services Google Cloud, utilisez VPC Service Controls.
  • F: empaqueter et publier les logiciels créés en dehors du processus officiel Des systèmes qui génèrent et signent la provenance de la compilation vous permettent de vérifier que votre logiciel a été créé par un système de compilation de confiance.
  • G: compromettre le dépôt dans lequel vous stockez vos logiciels pour vos utilisateurs internes ou externes Voici quelques mesures d'atténuation qui permettent de réduire ce risque :
    • Stockage et utilisation de copies de confiance des dépendances Open Source dont vous avez besoin dans des magasins d'artefacts privés tels que Artifact Registry
    • Valider la provenance de la compilation et de la source
    • Restriction des autorisations d'importation aux comptes non humains dédiés et aux administrateurs de dépôt. Sur Google Cloud, les comptes de service agissent pour le compte de services et d'applications.

Menaces liées au déploiement et à l'exécution

  • H: La résolution des dépendances en spécifiant une plage de versions ou un tag qui n'est pas associé de manière permanente à une version de compilation spécifique peut entraîner plusieurs problèmes:

    • Les builds ne sont pas reproductibles, car les dépendances qu'un build utilise pour la première fois peuvent être différentes des dépendances qu'il utilise pour les exécutions futures d'un même build.
    • Une dépendance peut se résoudre à une version compromise ou à une version comportant des modifications qui perturbent le fonctionnement de votre logiciel. Les acteurs malintentionnés peuvent profiter de cette incertitude et amener votre build à choisir leur version d'un package au lieu de celle que vous aviez l'intention d'utiliser. Un certain nombre de bonnes pratiques concernant les dépendances peuvent aider à réduire les risques de confussion.

  • 2: Compromettre le processus de déploiement Si vous utilisez un processus de déploiement continu, le fait de le compromettre peut introduire des modifications indésirables dans le logiciel que vous fournissez à vos utilisateurs. Vous pouvez atténuer les risques en limitant l'accès à votre service de déploiement et en testant les modifications dans des environnements de préproduction. Cloud Deploy peut vous aider à gérer le processus de livraison continue et la promotion entre les environnements.

  • 3: déployer des logiciels compromis ou non conformes. L'application de règles de déploiement peut aider à atténuer ce risque. Vous pouvez utiliser l'autorisation binaire pour vérifier que les images de conteneurs sont conformes aux critères des règles et bloquer le déploiement des images de conteneurs provenant de sources non fiables.

  • 4: failles et erreurs de configuration dans l'exécution de logiciels.

    • De nouvelles failles sont régulièrement découvertes, ce qui signifie que les nouvelles conclusions peuvent modifier le niveau de risque pour la sécurité de vos applications en production.
    • Certaines configurations augmentent le risque d'accès non autorisé, comme l'exécution en tant qu'utilisateur racine ou l'autorisation de l'élévation des privilèges lors de l'exécution d'un conteneur.

    Le tableau de bord de stratégie de sécurité GKE affiche des informations sur les failles du système d'exploitation et les problèmes de configuration de vos charges de travail en cours d'exécution.

    Dans Cloud Run, vous pouvez également afficher les insights sur la sécurité de vos révisions déployées, y compris les failles connues dans les images de conteneurs que vous avez déployées.

Consultez la section Protéger les builds pour en savoir plus sur la protection de la source et la section Protéger les déploiements pour en savoir plus sur la protection des déploiements.

Menaces de dépendance

Les dépendances incluent les dépendances directes dans vos compilations, ainsi que toutes les dépendances transitives, qui correspondent à l'arborescence récursive des dépendances en aval de vos dépendances directes.

Dans le schéma, E indique l'utilisation d'une dépendance incorrecte dans votre build. Une dépendance incorrecte peut inclure les éléments suivants:

  • Tous les logiciels dont dépend votre application, y compris les composants que vous développez en interne, les logiciels tiers commerciaux et les logiciels Open Source.
  • Failles provenant de n'importe lequel des autres vecteurs d'attaque. Exemple :
    • Un pirate informatique obtient l'accès à votre système de contrôle des sources et modifie la version d'une dépendance que votre projet utilise.
    • Votre build inclut un composant développé par une autre équipe de votre organisation. Ils publient la compilation et publient le composant directement à partir de leurs environnements de développement locaux, et introduisent accidentellement une faille dans une bibliothèque qu'ils n'utilisent que localement pour les tests et le débogage.
  • Suppression intentionnelle d'une dépendance Open Source d'un dépôt public. Cette suppression peut entraîner le dysfonctionnement des pipelines consommables s'ils récupèrent la dépendance directement à partir du dépôt public.

Consultez les bonnes pratiques pour les dépendances afin de découvrir comment atténuer les risques.

Atténuation des menaces

L'intégrité globale de votre chaîne d'approvisionnement dépend de sa partie la plus vulnérable. Négliger un vecteur d'attaque augmente le risque d'attaque dans cette partie de votre chaîne d'approvisionnement.

Pour autant, vous n'avez pas besoin de tout modifier en même temps. L'effet cumulatif, plus connu sous le nom de modèle du fromage suisse, s'applique à la sécurité sur la chaîne d'approvisionnement logicielle. Chaque atténuation que vous mettez en œuvre réduit les risques. Par ailleurs, lorsque vous combinez des stratégies d'atténuation sur votre chaîne d'approvisionnement, vous renforcez la protection contre différents types d'attaques.

  • Évaluez votre stratégie de sécurité à l'aide de frameworks et d'outils qui vous aident à évaluer la capacité de votre organisation à détecter les menaces, à y répondre et à les corriger.
  • Découvrez les bonnes pratiques à suivre pour protéger votre chaîne d'approvisionnement logicielle, ainsi que les produits Google Cloud conçus pour prendre en charge ces pratiques.
  • Utilisez Software Delivery Shield pour protéger vos logiciels sur l'ensemble de votre chaîne d'approvisionnement logicielle sur Google Cloud. Vous pouvez mettre en œuvre les services progressivement, en fonction de vos priorités et de l'infrastructure existante.

Étapes suivantes