Livrer des logiciels en toute sécurité

La rapidité et le délai de mise sur le marché comptent parmi les priorités majeures des entreprises du monde entier qui créent des logiciels et des applications pour répondre aux besoins de leurs clients. Ces impératifs stratégiques ont conduit au formidable essor des conteneurs en tant que plates-formes de choix. Au cours de l'année dernière, après avoir profité des nombreux avantages des conteneurs, tels que l'accélération du délai de mise sur le marché, une meilleure disponibilité, une sécurité renforcée, une plus grande évolutivité ou encore une réduction des coûts, bon nombre de ces entreprises ont commencé à envisager également l'approche sans serveur.

Bien que les solutions logicielles aient permis de réduire le temps nécessaire pour fournir une nouvelle fonctionnalité ou même un nouveau produit, de nombreuses pratiques de sécurité actuelles ne permettent pas de suivre cette évolution rapide, ce qui peut entraîner l'un ou l'autre des trois problèmes suivants :

1. Les processus actuels ralentissent l'activité des développeurs, ce qui entraîne des retards.
2. Les équipes chargées de la sécurité et des opérations font des compromis qui exposent l'entreprise à des menaces.
3. Les équipes de développement s'adaptent aux processus de sécurité actuels afin de respecter les délais, ce qui les rend vulnérables.

Ces dernières années, de nombreuses failles de sécurité ont été classées dans la catégorie "attaques sur la chaîne d'approvisionnement logicielle".

Log4Shell , par exemple, était une faille dangereuse du logiciel Apache Log4j identifiée en décembre 2021. Signalée avec un score CVSS maximal de 10, cette faille s'est avérée particulièrement dévastatrice en raison de la popularité de Log4j, un framework de journalisation basé sur Java. Deux éléments ont contribué à sa gravité : d'abord, il était très facile d'exploiter et de permettre une exécution complète du code à distance. Ensuite, cette faille se trouvait souvent dans les couches profondes de l'arborescence des dépendances et demeurait donc facilement indétectable.

Solarwinds, une société de logiciels de gestion informatique, a été attaqué par des acteurs locaux, qui ont injecté du code malveillant dans les builds officiels de logiciels Open Source utilisés par l'entreprise. Cette mise à jour malveillante a été transmise à 18 000 clients, y compris les départements du Trésor et du Commerce des États-Unis.

Kaseya, un autre fournisseur de logiciels de gestion informatique, a été attaqué par une faille "zero-day" qui a piraté le serveur Kaseya VSA et envoyé un script malveillant pour distribuer des rançongiciels qui ont chiffré tous les fichiers des systèmes concernés.

En raison du besoin urgent de répondre à ces incidents et à d'autres attaques similaires, la Maison-Blanche a décidé de publier un décret exécutif en mai 2021 exigeant des entreprises qui travaillent avec le gouvernement fédéral de respecter certaines normes de sécurité logicielle.

À bien des égards, le terme "chaîne d'approvisionnement logicielle" est très pertinent : les processus qui permettent de créer une chaîne d'approvisionnement logicielle sont très semblables à ceux de la fabrication d'une voiture.

Un constructeur automobile obtient différentes pièces prêtes à l'emploi, génère ses propres composants propriétaires, puis les assemble à l'aide d'un processus très automatisé. Le fabricant garantit la sécurité de ses opérations en veillant à ce que chaque composant tiers provienne d'une source fiable. Les composants propriétaires sont rigoureusement testés afin de s'assurer qu'ils ne présentent pas de problèmes de sécurité. Enfin, l'assemblage s'effectue via un processus de confiance qui aboutit à la finalisation du véhicule.

La chaîne d'approvisionnement logicielle est semblable à ces processus à bien des égards. Un fabricant de logiciels obtient des composants tiers, souvent de nature Open Source, qui exécutent des fonctions spécifiques, puis il développe son propre logiciel, qui constitue sa propriété intellectuelle principale. Le code est ensuite exécuté dans un processus de compilation qui combine ces composants en artefacts déployables, qui sont ensuite déployés en production.

Il ne suffit que d'un seul lien non sécurisé pour introduire une brèche dans la chaîne d'approvisionnement logicielle.

Comme pour les attaques massives de l'année dernière, chacune des étapes du processus peut présenter une vulnérabilité que des pirates informatiques peuvent exploiter.

Par exemple, le package npm moyen compte 12 dépendances directes et environ 300 dépendances indirectes. En outre, nous savons que près de 40 % de tous les packages npm publiés dépendent d'un code présentant des failles connues.

Ces failles ne rendront pas nécessairement le code dangereux. Par exemple, la faille peut se trouver dans une partie d'une bibliothèque qui n'a jamais été utilisée. Quoi qu'il en soit, ces failles doivent tout de même être vérifiées.

Ce problème est d'une ampleur monumentale. Si ne serait-ce qu'une seule de ces failles n'était pas corrigée, cela pourrait permettre à des pirates d'accéder à votre chaîne d'approvisionnement logicielle.

Chez Google, nous développons des applications à l'échelle mondiale depuis des décennies. Au fil du temps, nous avons mis à disposition en Open Source bon nombre de nos projets internes afin d'accélérer le développement. En parallèle, nous avons développé plusieurs processus internes pour aider à sécuriser l'expérience logicielle.

Voici quelques-unes des initiatives auxquelles nous contribuons afin de renforcer les chaînes d'approvisionnement logicielles dans le monde entier.

• Augmentation des investissements : nous avons annoncé en août 2020 que nous allions investir 10 milliards de dollars dans les cinq prochaines années pour renforcer la cybersécurité, développer des programmes zéro confiance, aider à sécuriser la chaîne d'approvisionnement logicielle et améliorer la sécurité Open Source.
• Supply-chain Levels for Software Artifacts (SLSA)  ou "Niveaux de la chaîne d'approvisionnement pour les artefacts logiciels" est un framework de bout en bout permettant d'assurer l'intégrité de la chaîne d'approvisionnement. Il s'agit d'un équivalent Open Source de nombreux processus que nous avons mis en œuvre en interne chez Google. Le framework SLSA permet de vérifier la provenance de ce qui a été créé et comment.
• DevOps Research and Assessment (DORA) – Notre équipe DORA a mené un programme de recherche de sept ans pour identifier un certain nombre de capacités en termes de technologies, de processus, de mesures et de culture permettant d'optimiser les performances organisationnelles et celles de la livraison de logiciels.
• Security Fondation en Open Source : nous avons cofondé Security Foundation en Open Source en 2019, un forum sectoriel sur la sécurité de la chaîne d'approvisionnement.
• Allstar : Allstar est une application GitHub installée dans des entreprises ou des dépôts afin de définir et d'appliquer des stratégies de sécurité. Cela permet l'application continue des bonnes pratiques de sécurité pour les projets GitHub.
• Tableaux de données Open Source : les tableaux de données présentent des métriques d'évaluation telles que des stratégies de sécurité bien définies, un processus de revue de code et une couverture de test continue par le biais d'outils de floutage et d'analyse de code statique, afin de fournir un score de risque pour les projets Open Source.

Nous pensons que deux éléments sont nécessaires pour résoudre le problème de la sécurité de la chaîne d'approvisionnement logicielle :

1. Des standards et frameworks à l'échelle du secteur.
2. Des services gérés qui mettent en œuvre ces normes à l'aide du principe du moindre privilège. C'est ce que l'on appelle une architecture zéro confiance. Une architecture zéro confiance est une infrastructure dans laquelle la confiance n'est intrinsèque à aucune personne, aucun appareil ni aucun réseau. En effet, toute la confiance permettant l'accès aux informations doit être acquise.

Examinons ces éléments séparément :

Dans son état actuel, le framework SLSA est un ensemble de directives de sécurité adoptables progressivement, établies sur la base d'un consensus sectoriel. Sous sa forme finale, le framework SLSA diffère d'une liste de bonnes pratiques concernant son application dans la mesure où il permet de créer automatiquement des métadonnées vérifiables qui peuvent être insérées dans les moteurs de stratégies afin d'accorder une "certification SLSA" à un package ou une plate-forme de compilation spécifique.

Le SLSA est conçu pour être incrémentiel et exploitable, et pour offrir des avantages en matière de sécurité à chaque étape. Une fois qu'un artefact est qualifié au plus haut niveau, les clients ont l'assurance qu'il n'a pas été falsifié et peuvent vérifier sa traçabilité de manière sécurisée jusqu'à sa source, ce qui est difficile, voire impossible à faire pour la plupart des logiciels d'aujourd'hui.

La certification SLSAC se compose de quatre niveaux, SLSA 4 représentant l'état final idéal. Les niveaux inférieurs représentent des jalons incrémentiels avec des garanties d'intégrité incrémentielle correspondantes. Les exigences sont actuellement définies comme suit :

Pour le niveau SLSA 1, le processus de compilation doit être entièrement scripté/automatisé et générer la provenance. La "Provenance" désigne les métadonnées de compilation d'un artefact, y compris le processus de compilation, la source racine et les dépendances. Connaître la provenance permet aux utilisateurs des logiciels de prendre des décisions de sécurité basées sur les risques. Avec une certification SLSA 1, bien que la provenance ne protège pas contre la falsification, elle offre un niveau basique d'identification de la source du code et peut faciliter la gestion des failles.

La certification SLSA 2 exige d'utiliser le contrôle des versions et un service de compilation hébergé qui génère une provenance authentifiée. Ces exigences supplémentaires renforcent la confiance du client concernant l'origine du logiciel. À ce niveau, la provenance empêche la falsification dans la mesure où le service de compilation est fiable. La niveau SLSA 2 facilite la mise à niveau vers la certification SLSA 3.

La certification SLSA 3 exige également que les plates-formes source et de compilation respectent des normes spécifiques afin de garantir la vérifiabilité de la source et l'intégrité de la provenance, respectivement. La certification SLSA 3 offre des mesures de sécurité bien plus efficaces contre les accès non autorisés que les niveaux précédents, car elle protège contre les classes de menaces spécifiques, telles que la contamination des compilations croisées.

La certification SLSA 4 est actuellement le niveau le plus élevé. Elle exige un examen par deux personnes de toutes les modifications et un processus de compilation reproductible et hermétique. L'examen en binôme est une bonne pratique du secteur, qui permet de détecter les erreurs et de dissuader les comportements malveillants. Les compilations hermétiques garantissent l'établissement d'une liste complète des provenances des dépendances. Les compilations reproductibles, bien qu'elles ne soient pas strictement obligatoires, présentent de nombreux avantages en termes de vérifiabilité et de fiabilité. De manière générale, le niveau SLSA 4 certifie avec un haut degré d'assurance que le logiciel n'a pas été falsifié. Pour en savoir plus sur les niveaux proposés, accédez au dépôt GitHub, ainsi qu'aux exigences correspondantes concernant la source, la compilation et la provenance.

La chaîne d'approvisionnement logicielle peut se diviser en cinq phases distinctes : code, compilation, packaging, déploiement et exécution. Nous aborderons chacune de ces phases dans notre approche de la sécurité.

Les outils entièrement gérés de Google Cloud, du code à l'exécution, en passant par la compilation et le déploiement, sont conformes aux normes et bonnes pratiques mises en œuvre par défaut.

Pour sécuriser votre chaîne d'approvisionnement logicielle, vous devez établir, valider et maintenir une chaîne de confiance qui détermine la provenance de votre code et garantit que ce que vous exécutez en production est conforme à vos intentions. Chez Google, nous procédons par le biais d'attestations générées et vérifiées tout au long du processus de développement et de déploiement logiciel. Cela nous permet d'assurer un niveau de sécurité ambiante par le biais d'actions telles que la revue du code, la vérification de la provenance du code et l'application des stratégies. Ensemble, ces processus nous aident à minimiser les risques liés à la chaîne d'approvisionnement logicielle, tout en améliorant la productivité des développeurs.

À la base, nous nous appuyons sur des services d'infrastructure sécurisés courants comme la gestion de l'authentification et des accès ou encore les journaux d'audit. Ensuite, nous sécurisons votre chaîne d'approvisionnement logicielle pour vous permettre de définir, de vérifier et d'appliquer des attestations tout au long du cycle de vie de vos logiciels.

Regardons de plus près comment garantir la sécurité ambiante au sein de votre processus de développement grâce aux stratégies et à la provenance sur Google Cloud.

La sécurisation de votre chaîne d'approvisionnement logicielle s'applique dès que vos développeurs commencent à concevoir votre application et à écrire du code. Cela concerne à la fois les logiciels propriétaires et les composants Open Source, chacun présentant ses propres défis.

Logiciels et dépendances Open Source

Le modèle Open Source permet aux développeurs de créer des applications plus rapidement afin de gagner en agilité et en productivité. Toutefois, les logiciels Open Source sont loin d'être parfaits et même si notre secteur en dépend, nous avons souvent très peu d'informations sur leurs dépendances et les différents niveaux de risques qui en découlent. Pour la plupart des entreprises, le risque est principalement associés aux failles ou aux licences.

Les logiciels, packages, images de base et autres artefacts Open Source dont vous avez besoin constituent la base de votre "chaîne de confiance".

Par exemple, supposons que votre entreprise crée un logiciel "a". Ce schéma représente la chaîne de confiance. En d'autres termes, il s'agit du nombre de dépendances implicites de votre projet. Dans le schéma, les dépendances "b" à "h" sont des dépendances directes, et "i" à "m" sont des dépendances indirectes.

Supposons maintenant qu'il existe une faille plus profonde dans l'arbre des dépendances. Le problème peut apparaître très rapidement dans de nombreux composants. De plus, les dépendances changent assez fréquemment : en moyenne, 40 000 packages npm subissent une modification de leurs dépendances.

Open Source Insights est un outil conçu par Google Cloud qui fournit un graphique de dépendances transitif afin que vous puissiez voir vos dépendances et les leurs dans toute l'arborescence des dépendances. Open Source Insights est continuellement mis à jour avec des conseils de sécurité, des informations de licence et d'autres données de sécurité dans plusieurs langues, le tout au même endroit. Utilisé avec les tableaux de données Open Source, qui fournissent un score de risque pour les projets Open Source, Open Source Insights permet à vos développeurs de faire de meilleurs choix parmi les millions de packages Open Source disponibles.

Pour résoudre ce problème, vous devez vous concentrer sur les dépendances du point de vue du code. Comme ces dépendances transitent vers la fin de la chaîne d'approvisionnement, elles sont plus difficiles à inspecter. Pour sécuriser vos dépendances, nous vous recommandons de commencer par l'approvisionnement :

• Utilisez des outils comme Open Source Insights et les tableaux de données OSS pour mieux comprendre vos dépendances.
• Analysez et validez l'ensemble du code, des packages et des images de base via un processus automatisé faisant partie intégrante de votre workflow.
• Contrôlez la manière dont les utilisateurs accèdent à ces dépendances. Il est essentiel de contrôler étroitement les dépôts, à la fois pour le code propriétaire et pour le code Open Source, en imposant des contraintes de revue du code et des exigences de vérification.

Nous aborderons plus en détail les processus de compilation et de déploiement, mais il est également important de vérifier la provenance du build, de profiter d'un environnement de compilation sécurisé et de vérifier que les images sont signées, puis validées lors du déploiement.

Les développeurs peuvent également utiliser un certain nombre de bonnes pratiques de codage telles que les suivantes :

• Automatiser les tests
• Utiliser des langages logiciels sécurisés lors des accès à la mémoire
• Exiger des revues de code
• Assurer l'authenticité des commits
• Identifier le code malveillant de manière précoce
• Éviter d'exposer des informations sensibles
• Exiger la journalisation et la sortie de compilation
• Exploiter la gestion des licences

L'étape suivante du processus de sécurisation de votre chaîne d'approvisionnement logicielle consiste à établir un environnement de compilation sécurisé à grande échelle. En substance, le processus de compilation commence par l'importation de votre code source dans l'un des nombreux langages disponibles d'un dépôt et se poursuit par l'exécution des builds pour satisfaire aux spécifications définies dans vos fichiers de configuration.

Les fournisseurs de services cloud comme Google vous donnent accès à un environnement de compilation géré et à jour qui vous permet de créer des images à n'importe quelle échelle.

Lors du processus de compilation, vous devez tenir compte de plusieurs points :

• Vos secrets sont-ils sécurisés pendant le processus de compilation et après ?
• Qui a accès à vos environnements de compilation ?
• Qu'en est-il des vecteurs d'attaque relativement nouveaux ou des risques d'exfiltration ?

Pour développer un environnement de compilation sécurisé, vous devez commencer par les secrets. Ils sont essentiels et relativement faciles à sécuriser. Commencez par vous assurer que vos secrets ne sont jamais en texte brut et, dans la mesure du possible, ne font pas partie de votre build. Vérifiez qu'ils sont chiffrés et que vos builds sont paramétrés pour faire référence à des secrets externes à utiliser si nécessaire. Cela simplifie également la rotation périodique des secrets et réduit l'impact des fuites.

L'étape suivante consiste à configurer des autorisations pour votre build. Votre processus de compilation repose sur différents utilisateurs et comptes de service. Par exemple, certains utilisateurs peuvent avoir besoin de gérer les secrets, tandis que d'autres doivent gérer le processus de compilation en ajoutant ou en modifiant des étapes, et d'autres ont simplement besoin de consulter les journaux.

Veillez à respecter les bonnes pratiques suivantes :

• Le principe le plus important est le principe du moindre privilège. Mettez en place des autorisations précises afin d'accorder aux utilisateurs et aux comptes de service les autorisations précises dont ils ont besoin pour travailler efficacement.
• Assurez-vous de savoir comment les utilisateurs et les comptes de service interagissent et de bien comprendre la chaîne de responsabilité, depuis la configuration d'une compilation à son exécution, ainsi que ses effets en aval.

Ensuite, à mesure que vous faites évoluer le processus, établissez des limites autour de votre compilation dans la mesure du possible, puis utilisez l'automatisation pour effectuer un scaling à la hausse via un modèle de configuration en tant que code et de paramétrage. Cela vous permet de vérifier efficacement les modifications apportées à votre processus de compilation. Assurez-vous également de respecter les exigences de conformité en instaurant des barrières d'approbation pour les builds et les déploiements sensibles, en envoyant des demandes d'extraction en cas de modification de l'infrastructure et en exigeant l'examen régulier des journaux d'audits par des personnes.

Enfin, assurez-vous que le réseau répond à vos besoins. Dans la plupart des cas, il est préférable d'héberger votre propre code source sur des réseaux privés protégés par des pare-feu. Avec Google Cloud, vous avez accès à des fonctionnalités telles que les pools privés Cloud Build, un environnement de compilation sans serveur verrouillé au sein du périmètre de votre propre réseau privé, ainsi qu'à des fonctionnalités telles que VPC Service Controls pour éviter les exfiltrations de données de propriété intellectuelle.

Autorisation binaire

Bien qu'IAM soit à la fois une stratégie incontournable et logique, elle n'est pas infaillible. Les fuites d'identifiants représentent un risque de sécurité grave. Pour réduire votre dépendance à une stratégie IAM, vous pouvez donc passer à un système basé sur des attestations qui sera moins susceptible de générer des erreurs. Google utilise un contrôle appelé "autorisation binaire", qui ne permet de déployer que des charges de travail de confiance.

Le service d'autorisation binaire établit, valide et gère une chaîne de confiance via des attestations et des vérifications de stratégie tout au long du processus. L'autorisation binaire génère essentiellement des signatures cryptographiques (attestations) à mesure que du code et d'autres artefacts sont déplacés en production, puis avant d'être déployées, ces attestations sont vérifiées en fonction des stratégies.

Lorsque vous utilisez Google Cloud Build, un ensemble d'attestations est capturé et ajouté à votre chaîne de confiance globale. Par exemple, les attestations sont générées pour savoir quelles tâches ont été exécutées, ou encore quels outils et quels processus de compilation ont été utilisés. Grâce à Cloud Build, vous pouvez atteindre la certification SLSA de niveau 1 en capturant la source de la configuration de compilation, qui peut être utilisée pour vérifier que la compilation a bien été scriptée. Les compilations scriptées sont davantage sécurisées que les compilations manuelles et sont exigées pour obtenir la certification SLSA de niveau 1. En outre, vous pouvez rechercher la provenance de votre build et d'autres attestations à l'aide du condensé d'image de conteneur, qui crée une signature unique pour chaque image. Cette étape est également exigée pour la certification SLSA de niveau 1.

Une fois la compilation terminée, votre image de conteneur est presque prête pour la production. Il est essentiel de disposer d'un emplacement sécurisé pour stocker vos images afin d'éviter toute falsification des images existantes et l'importation d'images non autorisées. Votre gestionnaire de packages aura probablement besoin d'images aussi bien pour les compilations propriétaires que les compilations Open Source, ainsi que des packages de langage utilisés par vos applications.

Artifact Registry de Google Cloud vous fournit un dépôt de ce type. Artifact Registry est un gestionnaire unique qui permet à votre entreprise de gérer les images de conteneurs et les packages de langage (tels que Maven et npm). Entièrement intégré aux outils et aux environnements d'exécution de Google Cloud, il est également compatible avec les protocoles d'artefacts natifs. Ainsi, vous pouvez facilement intégrer vos outils CI/CD lorsque vous configurez des pipelines automatisés.

Comme à l'étape de compilation, il est essentiel de vous assurer que les autorisations d'accès à Artifact Registry sont bien définies et respectent les principes du moindre privilège. En plus de limiter l'accès non autorisé, Package Repository peut offrir beaucoup plus de valeur. Artifact Registry, par exemple, inclut l'analyse des failles dans vos images et vous permet ainsi de vous assurer qu'elles peuvent être déployées en toute sécurité. Ce service analyse les images par rapport à une base de données de failles toujours actualisée et mise à jour pour évaluer les nouvelles menaces et peut vous avertir lorsqu'une faille est détectée.

Cette étape génère des métadonnées supplémentaires, y compris une attestation indiquant si les résultats d'une analyse de faille dans un artefact atteignent certains seuils de sécurité. Ces informations sont ensuite stockées dans notre service d'analyse qui structure et organise les métadonnées de l'artefact afin de les rendre facilement accessibles pour l'autorisation binaire. Cette fonctionnalité vous permet d'empêcher automatiquement le déploiement d'images à risque sur Google Kubernetes Engine (GKE).

Les deux dernières phases de la chaîne d'approvisionnement logicielle de sécurité sont le déploiement et l'exécution. Bien qu'il s'agisse de deux étapes distinctes, il est judicieux de les considérer ensemble comme un moyen de vérifier que seules les compilations autorisées passent en production.

Chez Google, nous avons développé des bonnes pratiques pour déterminer les types de compilations autorisées. La première étape consiste à garantir l'intégrité de votre chaîne d'approvisionnement afin qu'elle ne génère que des artefacts fiables. L'étape suivante consiste à gérer les failles dans le cycle de livraison des logiciels. Enfin, nous avons réuni ces deux éléments pour appliquer des workflows basés sur des règles d'intégrité et d'analyse des failles.

Lorsque vous atteignez cette étape, vous avez déjà terminé les phases de codage, de compilation et de packaging. L'authenticité des attestations recueillies sur la chaîne d'approvisionnement peut être validée par une autorisation binaire. En mode forcé, une image n'est déployée que lorsque les attestations répondent aux règles de votre entreprise et, en mode audit, les cas de non-respect des règles sont consignés et déclenchent des alertes. Vous pouvez également utiliser l'autorisation binaire pour empêcher l'exécution des compilations, sauf si elles ont été créées à l'aide du processus Cloud Build approuvé. L'autorisation binaire garantit que seul le code correctement examiné et autorisé est déployé.

Il est essentiel de déployer vos images dans un environnement d'exécution fiable. Notre plate-forme Kubernetes gérée, GKE, applique une approche axée sur la sécurité des conteneurs.

GKE se charge de la plupart des préoccupations liées à la sécurité des clusters. Les mises à niveau automatiques des clusters vous permettent de corriger vos applications Kubernetes et de les mettre à jour automatiquement à l'aide de versions disponibles. Le démarrage sécurisé, les nœuds protégés et les vérifications de l'intégrité garantissent que le noyau et les composants du cluster n'ont pas été modifiés, qu'ils s'exécutent comme prévu et que les nœuds malveillants ne peuvent pas rejoindre votre cluster. Enfin, l'informatique confidentielle vous permet d'exécuter des clusters avec des nœuds dont la mémoire est chiffrée afin que les données restent confidentielles même pendant leur traitement. Ajoutez à cela le chiffrement des données au repos et en transit sur le réseau, et GKE offre un environnement très sécurisé, privé et confidentiel pour exécuter vos charges de travail conteneurisées.

En outre, GKE fournit également une sécurité renforcée pour vos applications grâce à la gestion des certificats pour vos équilibreurs de charge, Workload Identity, ainsi que des fonctionnalités réseau avancées et un outil puissant pour configurer et sécuriser l'entrée dans votre cluster. GKE offre également des environnements en bac à sable pour exécuter les applications non approuvées tout en protégeant le reste de vos charges de travail.

Avec GKE Autopilot, les bonnes pratiques et les fonctionnalités de sécurité de GKE sont automatiquement mises en œuvre, ce qui réduit encore la surface d'attaque et minimise les erreurs de configuration qui peuvent entraîner des problèmes de sécurité.

Bien sûr, le besoin de validation ne s'arrête pas à l'étape du déploiement. L'autorisation binaire permet également une validation continue, afin de rester en conformité avec la stratégie définie, même après le déploiement. Si une application en cours d'exécution ne respecte pas une règle existante ou que vous venez d'ajouter, une alerte est créée et consignée. Ainsi, vous avez l'assurance que ce que vous exécutez en production correspond exactement à vos intentions.

Gestion des failles

En plus de garantir l'intégrité, un autre intérêt de la sécurité de la chaîne d'approvisionnement est d'assurer la détection rapide des failles et leur correction. Les pirates ont évolué pour introduire activement des failles dans les projets en amont. C'est pourquoi, la gestion des failles et la détection des défauts doivent être intégrées à toutes les étapes du cycle de livraison des logiciels.

Une fois le code prêt pour le déploiement, utilisez un pipeline CI/CD et effectuez une analyse complète du code source et des artefacts générés à l'aide des nombreux outils disponibles. Il peut s'agir d'analyses statiques, d'outils de floutage ou de divers types d'analyseurs de failles.

Une fois votre charge de travail déployée et exécutée en production et qu'elle est diffusée aux utilisateurs, il est nécessaire de surveiller les menaces émergentes et de planifier des mesures immédiates pour y remédier.

Conclusion

Pour résumer, la sécurisation d'une chaîne d'approvisionnement logicielle consiste à adopter de bonnes pratiques telles que le recours à une stratégie SLSA et à utiliser des services gérés de confiance pour vous aider à mettre en œuvre ces bonnes pratiques.

Démarches essentielles :

• Commencez par votre code et vos dépendances, et assurez-vous qu'ils sont fiables.
• Protégez votre système de compilation et utilisez des attestations pour vérifier que toutes les étapes de compilation nécessaires ont été suivies.
• Assurez-vous que tous vos packages et artefacts sont fiables et qu'ils ne peuvent pas être falsifiés.
• Contrôlez qui est autorisé à déployer et conservez une piste de vérification Validez les attestations pour chaque artefact que vous souhaitez déployer à l'aide de l'autorisation binaire.
• Exécutez vos applications dans un environnement de confiance et assurez-vous que personne ne peut les altérer lorsqu'elles sont en cours d'exécution. Surveillez les nouvelles failles découvertes afin de protéger votre déploiement.

Chez Google, nous intégrons de bonnes pratiques pour chaque étape de ce parcours dans notre portefeuille de produits afin de vous offrir des bases de confiance pour vos compilations.

Prêt à sécuriser votre chaîne d'approvisionnement logicielle ? Nous tenons à préciser que l'approche que vous choisirez pour commencer est dans une large mesure arbitraire. Aucune action ne peut garantir à elle seule la sécurité de l'ensemble de votre chaîne d'approvisionnement et aucune action n'est plus importante que les autres lorsqu'il est question de sécuriser l'intégralité de la chaîne d'approvisionnement logicielle. Cela dit, voici quatre recommandations pour vous lancer.

1. Corrigez vos logiciels

Si vous avez déployé du code dans votre environnement de production comportant des failles connues, vous avez fait tout le travail du pirate à sa place. À partir de là, peu importe le degré de sécurisation que vous avez apporté à votre chaîne d'approvisionnement logicielle, car les pirates disposent déjà d'une voie d'entrée. Voilà pourquoi l'application des correctifs est essentielle.

2. Contrôlez ce qui s'exécute dans votre environnement

Une fois les correctifs appliqués, vous devez pouvoir contrôler la chaîne d'approvisionnement logicielle elle-même. Pour commencer, vous devez être en mesure d'attester que ce que vous exécutez provient vraiment de vos outils de compilation ou de dépôts de confiance. Un tel niveau de contrôle permet d'éviter les attaques intentionnelles et les erreurs involontaires, comme dans le cas d'un développeur qui a déployé une application sans se rendre compte qu'elle n'était pas sûre. Vous disposez ainsi d'une base solide pour ajouter des outils tels que les tests de clics et l'autorisation binaire. 

3. Assurez-vous que les packages des fournisseurs tiers sont sûrs

Un problème émergent, en ce qui concerne la sécurité de la chaîne d'approvisionnement, est la fréquence à laquelle les logiciels des fournisseurs sont piratés afin de fournir un canal d'entrée aux rançongiciels ou aux accès non autorisés aux déploiements de leurs clients cibles. Les packages de fournisseurs tiers que vous exécutez dans votre environnement (par exemple, des produits de gestion de système, de réseau ou de sécurité) disposent souvent d'une haut niveau de privilèges. Nous vous recommandons de demander à ces fournisseurs de fournir davantage d'informations, au-delà de leur déclaration de sécurité, sur les packages que vous utilisez afin d'obtenir plus d'assurance. Vous pouvez, par exemple, leur demander quel est le niveau de conformité SLSA ou s'ils sont concernés par les récentes exigences du décret exécutif.

4. Vous devez disposer d'une copie privée de votre code source.

Si vous utilisez un logiciel Open Source, n'utilisez pas une version que vous extrayez directement sur Internet pour commencer à compiler. Utilisez plutôt une copie privée que vous corrigerez régulièrement. Vous disposerez ainsi d'un bon point de départ pour chaque compilation et saurez exactement d'où vient le code source. 

Bonnes pratiques DevOps

1. Six years of the State of DevOps Repor : "Six années de rapports sur l'état des DevOps" est un ensemble d'articles présentant de façon détaillée les fonctionnalités qui prédisent les performances en livraison de logiciels, ainsi qu'une évaluation rapide pour faire le point sur votre situation et découvrir comment l'améliorer.
2. Google Cloud 2021 Accelerate State of DevOps Report (Rapport Google Cloud 2021 "Accélérer l'état des DevOps")
3. Livre blanc de Google Cloud : Re-architecting to cloud native: an evolutionary approach to increasing developer productivity at scale (Modifier l'architecture pour une exploitation cloud native : une approche évolutive qui accroît la productivité des développeurs à grande échelle)

Sécuriser la chaîne d'approvisionnement logicielle

1. Blog Google Cloud : Qu'est-ce que la sécurité "zéro confiance" ?
2. Blog sur la sécurité Google : Présentation du SLSA, un framework de bout en bout pour l'intégrité de la chaîne d'approvisionnement
3. Livre blanc de Google Cloud : Test Shift-left pour la sécurité : Sécuriser des chaînes d'approvisionnement logicielles