Les vecteurs d'attaque pour les chaînes d'approvisionnement de logiciels 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'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 les deux types 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 à la source
- Créer des menaces
- Menaces liées au déploiement et à l'exécution
- Menaces de dépendance
Menaces liées aux sources
Ces menaces ont un impact sur l'intégrité de votre code source.
1 : Écrivez du code non sécurisé. Le manque de pratiques de codage sécurisées 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 stations de travail entièrement gérées et préconfigurées que vous pouvez personnaliser pour répondre à vos besoins.
- Analyse locale du code. Source protect Cloud Code (preview privée) fournit des informations sur la 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 et détecter les failles du système d'exploitation et des packages de langages.
- Informations sur les pratiques permettant de renforcer la sécurité du code.
A : envoyez du code dangereux au dépôt source. Cela inclut non seulement le code malveillant, mais aussi le code qui introduit involontairement des failles pour une attaque, comme le scripting intersite. Voici quelques mesures d'atténuation :
- Exiger une revue humaine pour les modifications apportées au code source.
- Utilisez 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. Restreindre 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 multifactorielle permet d'atténuer ce risque.
Lorsque vous évaluez l'intégrité de votre source, examinez également les scripts et 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 les risques liés aux failles de sécurité dans ces fichiers.
Pour en savoir plus sur la protection de votre source, consultez Protéger la source.
Créer des menaces
Ces menaces compromettent votre logiciel lorsque vous le compilez ou l'empaquetez, ou incitent les utilisateurs de votre logiciel à utiliser une version incorrecte.
- C : Compilation avec une source qui ne provient pas du système de contrôle de la source approuvé.
Voici quelques mesures d'atténuation qui permettent de réduire ce risque :
- Utilisez 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 de données à partir de vos compilations. Pour les services Google Cloud , utilisez VPC Service Controls.
- Stockez et utilisez 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 les 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 à partir de vos compilations. Pour les services Google Cloud , utilisez VPC Service Controls.
- F : Empaqueter et publier des logiciels qui ont été créés en dehors du processus officiel. Les systèmes de compilation qui génèrent et signent la provenance des compilations 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 :
- Stockez et utilisez des copies fiables des dépendances Open Source dont vous avez besoin dans des dépôts d'artefacts privés tels qu'Artifact Registry.
- Valider la provenance de la compilation et de la source.
- Limitez les autorisations d'importation aux comptes non humains dédiés et aux administrateurs du 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 une version avec des modifications qui cassent 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 de dépendances.
2 : compromettre le processus de déploiement. Si vous utilisez un processus de déploiement continu, une compromission de ce processus peut entraîner des modifications indésirables du logiciel que vous fournissez à vos utilisateurs. Vous pouvez limiter les risques en restreignant 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 piratés 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 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. Cela 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'é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 insights sur la sécurité concernant vos révisions déployées, y compris les failles connues dans les images de conteneurs que vous avez déployées.
Consultez Protéger les compilations pour en savoir plus sur la protection de votre source et Protéger les déploiements pour en savoir plus sur la protection des 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 en aval de vos dépendances directes.
Dans le diagramme, E indique l'utilisation d'une mauvaise dépendance dans votre compilation. Voici quelques exemples de dépendances incorrectes :
- 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.
- Failles provenant de l'un des autres vecteurs d'attaque. Exemple :
- Un pirate informatique accède à votre système de contrôle de source 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. Ils créent 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.
Consultez les bonnes pratiques concernant les dépendances pour découvrir comment limiter les risques.
Atténuer les menaces
L'intégrité globale de votre chaîne d'approvisionnement dépend de sa partie la plus vulnérable. Si vous négligez un vecteur d'attaque, vous augmentez 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 des actes, plus connu sous le nom de modèle du gruyère, s'applique à la sécurité de la chaîne d'approvisionnement logicielle. Chaque mesure d'atténuation que vous mettez en œuvre réduit vos risques. En combinant les mesures d'atténuation dans votre chaîne d'approvisionnement, vous renforcez votre 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 les produits Google Cloud conçus pour les appliquer.
- Intégrez des fonctionnalités de sécurité Google Cloud à 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. Vous pouvez implémenter les services progressivement, en fonction de vos priorités et de votre infrastructure existante.
Étapes suivantes
- Évaluez votre stratégie de sécurité.
- Découvrez les bonnes pratiques pour protéger votre chaîne d'approvisionnement logicielle.