Les vecteurs d'attaque pour les chaînes d'approvisionnement logicielle sont les différentes manières dont une personne peut compromettre votre logiciel intentionnellement ou accidentellement.
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'application. 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 des logiciels et peuvent provenir de l'intérieur ou de l'extérieur de votre organisation.
La légende du schéma 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 SLSA (Supply-chain Levels for Software Artifacts).
- Les chiffres 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 les deux ensembles de menaces.
Les sous-sections de ce document décrivent les menaces dans le contexte de la source, des compilations, du déploiement et des dépendances.
- Menaces liées à la source
- Menaces liées à la compilation
- Menaces liées au déploiement et à l'exécution
- Menaces liées aux dépendances
Menaces liées à la source
Ces menaces ont un impact sur l'intégrité de votre code source.
1: Écrire du code non sécurisé. Le manque de pratiques de codage sécurisé peut entraîner l'écriture de code qui inclut involontairement 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 mesures d'atténuation :
- Définir des règles pour les postes de travail des développeurs. Cloud Workstations fournit des postes de travail entièrement gérés et préconfigurés que vous pouvez personnaliser pour répondre à vos besoins.
- Analyse locale du code. Cloud Code source protect (aperçu privé) 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 analyser les images de conteneurs afin de détecter les failles du système d'exploitation et des packages de langage.
- Formation sur les pratiques permettant de sécuriser le code.
A: Envoyer du code dangereux au dépôt source. Cela inclut non seulement le code malveillant, mais également le code qui introduit involontairement des failles dans une attaque telle que le script intersites. Voici quelques mesures d'atténuation :
- Exiger une revue humaine pour les modifications apportées au code source.
- Utiliser des outils d'analyse et de linting de code 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 à d'autres systèmes de votre pipeline de compilation, et utiliser l'authentification multifacteur permet d'atténuer ce risque.
Lorsque vous évaluez l'intégrité de votre source, examinez également les scripts et configurations d'assistance que vous utilisez pour compiler et déployer votre logiciel. Incluez-les dans votre système de contrôle des sources et vos processus de revue de 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 liées à la compilation
Ces menaces compromettent votre logiciel lorsque vous le compilez ou l'empaquetez, ou incitent les consommateurs de votre logiciel à utiliser une version incorrecte.
- 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 permettent de réduire ce risque :
- Utiliser des services de compilation, tels que Cloud Build, qui génèrent des informations de provenance afin de pouvoir valider que vos compilations utilisent une source de confiance.
- Placer votre infrastructure CI/CD dans un périmètre réseau pour empêcher l'exfiltration de données de vos compilations. Pour les Google Cloud services, utilisez VPC Service Controls.
- Stocker et utiliser des 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 accorder 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 empêcher l'exfiltration de données de vos compilations. Pour les Google Cloud services, utilisez VPC Service Controls.
- F : Empaqueter et publier des logiciels compilés en dehors du processus officiel. Les systèmes de compilation qui génèrent et signent la provenance de la compilation vous permettent de valider que votre logiciel a été compilé par un système de compilation de confiance.
- 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 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.
- Limiter les 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 au nom des services et des 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 compilations ne sont pas reproductibles, car les dépendances qu'une compilation utilise la première fois peuvent être différentes de celles qu'elle utilise pour les futures exécutions de la même compilation.
- Une dépendance peut être résolue en une version compromise ou en une version comportant 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 pour les dépendances peuvent aider à atténuer les risques de confusion des dépendances.
2 : Compromettre le processus de déploiement. Si vous utilisez un processus de déploiement continu, 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 valider que les images de conteneurs sont conformes aux critères des règles et bloquer le déploiement d'images de conteneurs provenant de sources non fiables.
4 : Failles et 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 nouveaux résultats peuvent modifier le niveau de risque de sécurité de vos applications en production.
- Certaines configurations augmentent le risque d'accès non autorisé, par exemple 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 et les problèmes de configuration dans vos charges de travail en cours d'exécution.
Dans Cloud Run, vous pouvez également afficher des informations 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.
Pour en savoir plus sur la protection de votre source, consultez Protéger la source. Pour en savoir plus sur la protection des déploiements, consultez Protéger les déploiements.
Menaces liées aux dépendances
Les dépendances incluent les dépendances directes dans vos compilations, ainsi que toutes les dépendances transitives, l'arborescence récursive des dépendances qui sont en aval de vos dépendances directes.
Dans le schéma, E indique l'utilisation d'une dépendance incorrecte dans votre compilation. Une dépendance incorrecte peut inclure les éléments suivants :
- Tout logiciel dont votre application dépend, y compris les composants que vous développez en interne, les logiciels commerciaux tiers et les logiciels Open Source.
- Les 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 compilation inclut un composant développé par une autre équipe de votre organisation. Ils compilent 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 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 l'échec des pipelines consommateurs s'ils récupèrent la dépendance directement à partir du dépôt public.
Pour découvrir comment atténuer les risques, consultez les bonnes pratiques concernant les dépendances.
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 même temps, vous n'avez pas besoin de tout changer en même temps. L'effet cumulatif, plus connu sous le nom de 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, et lorsque vous combinez des mesures d'atténuation dans votre chaîne d'approvisionnement, vous augmentez 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 pour protéger votre chaîne d'approvisionnement logicielle, et Google Cloud les produits conçus pour les prendre en charge.
- Intégrez Google Cloud des fonctionnalités de sécurité dans vos processus de développement, de compilation, et de déploiement pour améliorer la stratégie de sécurité de votre chaîne d'approvisionnement logicielle logicielle. Vous pouvez implémenter des 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 pour protéger votre chaîne d'approvisionnement logicielle.