Les vecteurs d'attaque des chaînes d'approvisionnement logicielles sont les différentes façons dont une personne peut compromettre intentionnellement ou accidentellement votre logiciel.
Les logiciels vulnérables présentent des risques, comme 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 entraînent une perte de temps, d'argent et 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.
La légende du diagramme comprend deux ensembles de menaces:
- Les lettres A à H indiquent les vecteurs d'attaque dans la chaîne d'approvisionnement logicielle qui sont décrits comme des menaces dans le framework Supply chain Levels for Software Artifacts (SLSA).
- Les numéros 1 à 4 indiquent des vecteurs d'attaque supplémentaires que le framework SLSA ne décrit pas directement.
Google Cloud fournit un ensemble modulaire de fonctionnalités et d'outils qui intègrent les bonnes pratiques pour atténuer ces deux ensembles 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 provenant de la source
Ces menaces affectent l'intégrité de votre code source.
1: Écrire du code non sécurisé. L'absence de bonnes pratiques de codage sécurisé peut entraîner l'écriture de code qui inclut involontairement des failles. Les stations de travail de développement non sécurisées peuvent également introduire du code malveillant ou non sécurisé. Les mesures d'atténuation incluent les suivantes:
- Définir des règles pour les postes de travail des développeurs Cloud Workstations fournit des stations de travail préconfigurées et entièrement gérées que vous pouvez personnaliser en fonction de vos besoins.
- Analyse locale du code. Source protect Cloud Code (version preview privée) fournit des commentaires de sécurité en temps réel, y compris des informations sur les failles et les licences pour les dépendances. Les développeurs peuvent également utiliser l'API On-Demand Scanning pour rechercher les failles des images de conteneur dans les OS et les packages de langages.
- Formation sur les pratiques permettant de renforcer la sécurité du code.
A: Envoyer du code dangereux au dépôt source. Cela inclut non seulement le code malveillant, mais aussi le code qui introduit involontairement des failles dans une attaque telle que le scénario de script intersites. Les mesures d'atténuation incluent les suivantes:
- Exiger un examen humain pour les modifications apportées au code source
- Utilisation d'outils d'analyse du code et de linting qui s'intègrent aux IDE et aux systèmes de contrôle des sources.
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, et utiliser l'authentification multifacteur permet de réduire ce risque.
Lorsque vous évaluez l'intégrité de vos sources, examinez également les scripts et les configurations associés que vous utilisez pour compiler et déployer votre logiciel. Incluez-les dans votre système de contrôle des sources et vos processus d'examen du code afin de réduire le risque de failles dans ces fichiers.
Pour en savoir plus sur la protection de votre source, consultez Protéger la source.
Menaces de compilation
Ces menaces compromettent votre logiciel lorsque vous le compilez ou l'empaquetez, ou incitent les utilisateurs de votre logiciel à utiliser une mauvaise version.
- C: Compiler avec une source qui ne provient pas du système de contrôle de source approuvé.
Voici quelques mesures d'atténuation qui permettent de réduire ce risque :
- Utiliser des services de compilation, tels que Cloud Build, qui génèrent des informations sur la provenance afin de pouvoir vérifier que vos compilations utilisent une source fiable.
- Placer votre infrastructure CI/CD dans un périmètre réseau pour éviter l'exfiltration de données de vos builds Pour les services Google Cloud, utilisez VPC Service Controls.
- Stocker et utiliser des copies fiables des dépendances Open Source dont vous avez besoin dans un magasin d'artefacts privé tel qu'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.
- Utilisez 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 compilation et en le détruisant après la compilation.
- Placez votre infrastructure CI/CD dans un périmètre réseau pour éviter l'exfiltration de données de vos builds. Pour les services Google Cloud, utilisez VPC Service Controls.
- F: Empaqueter et publier un logiciel créé en dehors du processus officiel. Les systèmes de compilation qui génèrent et signent la provenance de la compilation vous permettent de vérifier que votre logiciel a été compilé par un système de compilation fiable.
- G: compromettre le dépôt dans lequel vous stockez votre logiciel pour vos utilisateurs internes ou externes. Voici quelques mesures d'atténuation qui permettent de réduire ce risque :
- Stocker et utiliser des copies fiables des dépendances Open Source dont vous avez besoin dans des magasins d'artefacts privés tels qu'Artifact Registry.
- Valider la provenance du build et de la source
- Limiter les autorisations d'importation aux comptes non humains dédiés et aux administrateurs de dépôts. Dans Google Cloud, les comptes de service agissent au nom des services et des applications.
Menaces de déploiement et d'exécution
H: La résolution des dépendances en spécifiant une plage de versions ou une balise qui n'est pas associée 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 de celles qu'il utilise pour les futures exécutions du même build.
- Une dépendance peut se résoudre en une version compromise ou en une version avec des modifications qui endommagent votre logiciel. Les acteurs malintentionnés peuvent profiter de cette incertitude pour que votre compilation choisisse 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 contribuer à atténuer les risques de confusion de dépendances.
2: compromettre le processus de déploiement. Si vous utilisez un processus de déploiement continu, la compromission de ce processus peut entraîner 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 diffusion 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 contribuer à atténuer ce risque. Vous pouvez utiliser l'autorisation binaire pour vérifier que les images de conteneur sont conformes aux critères de stratégie et bloquer le déploiement d'images de conteneur à partir de sources non approuvées.
4: Les failles et les erreurs de configuration dans les logiciels en cours d'exécution.
- De nouvelles failles sont découvertes régulièrement, ce qui signifie que de nouvelles découvertes peuvent modifier le niveau de risque de sécurité pour vos applications en production.
- Certaines configurations augmentent le risque d'accès non autorisé, par exemple en exécutant le code en tant qu'utilisateur racine ou en autorisant 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 et les problèmes de configuration de vos charges de travail en cours d'exécution.
Dans Cloud Run, vous pouvez également consulter des insights de sécurité sur vos révisions déployées, y compris les failles connues dans les images de conteneur que vous avez déployées.
Pour en savoir plus sur la protection de votre source, consultez Protéger les builds, et pour en savoir plus sur la protection des déploiements, consultez Protéger les déploiements.
Menaces de dépendance
Les dépendances incluent les dépendances directes dans vos builds, ainsi que toutes les dépendances transitives, l'arborescence récursive des dépendances en aval de vos dépendances directes.
Dans le diagramme, E indique que vous utilisez une mauvaise dépendance dans votre compilation. Une dépendance incorrecte peut inclure les éléments suivants:
- Tout logiciel sur lequel votre application dépend, y compris les composants que vous développez en interne, les logiciels tiers commerciaux et les logiciels Open Source.
- Failles provenant de l'un des autres vecteurs d'attaque. Exemple :
- Un pirate informatique accède à votre système de contrôle des sources et modifie la version d'une dépendance utilisée par votre projet.
- Votre build inclut un composant développé par une autre équipe de votre organisation. Il compile et publie le composant directement à partir de ses environnements de développement locaux et introduit accidentellement une faille dans une bibliothèque qu'il n'utilise qu'en local pour les tests et le débogage.
- Suppression intentionnelle d'une dépendance Open Source d'un dépôt public. La suppression peut entraîner la défaillance des pipelines consommateurs s'ils récupèrent la dépendance directement à partir du dépôt public.
Consultez les bonnes pratiques concernant les dépendances pour découvrir comment atténuer les risques.
Atténuer les menaces
L'intégrité globale de votre chaîne d'approvisionnement n'est aussi forte que 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.
En revanche, vous n'avez pas besoin de tout changer en même temps. L'effet cumulatif des actes, plus communément appelé modèle du fromage suisse, s'applique à la sécurité de la chaîne d'approvisionnement logicielle. Chaque mesure d'atténuation que vous mettez en œuvre réduit votre risque. Lorsque vous combinez des mesures d'atténuation dans 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, à répondre et à corriger les menaces.
- Découvrez les bonnes pratiques pour protéger votre chaîne d'approvisionnement logicielle et les produits Google Cloud conçus pour les mettre en œuvre.
- Intégrez les fonctionnalités de sécurité Google Cloud à vos processus de développement, de compilation et de déploiement pour améliorer la posture de sécurité de votre chaîne d'approvisionnement logiciel. Vous pouvez implémenter les services progressivement, en fonction de vos priorités et de votre infrastructure existante.
Étape suivante
- Évaluez votre stratégie de sécurité.
- Découvrez les bonnes pratiques à suivre pour protéger votre chaîne d'approvisionnement logicielle.