La pression réglementaire et juridique accrue exercée sur les organisations productrices de logiciels pour sécuriser leurs chaînes d’approvisionnement et garantir l’intégrité de leurs logiciels ne devrait pas surprendre. Au cours des dernières années, la chaîne d’approvisionnement logicielle est devenue une cible de plus en plus attractive pour les attaquants qui y voient des opportunités de multiplier leurs attaques par plusieurs ordres de grandeur. Par exemple, ne cherchez pas plus loin que la faille Log4j de 2021, où Log4j (un cadre de journalisation open source maintenu par Apache et utilisé dans une myriade d’applications différentes) était à l’origine d’exploits qui mettaient en danger des milliers de systèmes.
La fonctionnalité de communication de Log4j était vulnérable et offrait ainsi une opportunité à un attaquant d’injecter du code malveillant dans les journaux qui pouvait ensuite être exécuté sur le système. Après sa découverte, les chercheurs en sécurité ont constaté des millions de tentatives d’exploitation, dont beaucoup se sont transformées en attaques par déni de service (DoS). Selon certaines des dernières recherches de Gartner, près de la moitié des entreprises auront été la cible d’une attaque contre la chaîne d’approvisionnement logicielle d’ici 2025.
Mais qu’est-ce que la chaîne d’approvisionnement logicielle ? Pour commencer, elle est définie comme la somme totale de tous les codes, personnes, systèmes et processus qui contribuent au développement et à la livraison d’artefacts logiciels, à l’intérieur comme à l’extérieur d’une organisation. Et ce qui rend la sécurisation de la chaîne d’approvisionnement logicielle si difficile, c’est la nature complexe et hautement distribuée du développement d’applications modernes. Les organisations emploient des équipes mondiales de développeurs qui s’appuient sur un nombre sans précédent de dépendances open source, ainsi que sur une multitude de référentiels de code et de registres d’artefacts, de pipelines CI/CD et de ressources d’infrastructure utilisées pour créer et déployer leurs applications.
Et même si la sécurité et la conformité constituent toujours une préoccupation majeure pour les entreprises, le défi de la sécurisation des chaînes d’approvisionnement logicielles de l’organisation apparaît de plus en plus grand. De nombreuses organisations font des progrès substantiels dans la mise en œuvre des pratiques DevSecOps, mais bon nombre d’entre elles en sont encore aux premiers stades de la détermination de ce qu’elles doivent faire.
C’est exactement pourquoi nous avons rédigé cet article. Bien que ce qui suit ne soit en aucun cas une liste exhaustive, voici quatre principes directeurs pour faire avancer vos efforts de sécurité de la chaîne d’approvisionnement logicielle dans la bonne direction.
Tenez compte de tous les aspects de votre chaîne d’approvisionnement en logiciels lors de l’application de la sécurité
Étant donné que plus de 80 % des bases de code présentent au moins une vulnérabilité open source, il va de soi que les dépendances aux logiciels libres ont été au cœur de la sécurité de la chaîne d’approvisionnement logicielle. Cependant, les chaînes d’approvisionnement de logiciels modernes englobent d’autres entités dont les mesures de sécurité sont soit négligées, soit mal comprises au sein de l’organisation pour être correctement gérées. Ces entités sont des référentiels de code, des pipelines CI et CD, des infrastructures et des registres d’artefacts, chacun nécessitant des contrôles de sécurité et une évaluation régulière de la conformité.
Des cadres tels que OWASP Top-10 pour CI/CD et Benchmark de sécurité de la chaîne d’approvisionnement des logiciels CIS. L’adhésion à ces cadres nécessitera un RBAC granulaire, l’application du principe du moindre privilège, l’analyse des conteneurs et de l’infrastructure en tant que code pour détecter les vulnérabilités et les erreurs de configuration, l’isolation des builds, l’intégration des tests de sécurité des applications et une gestion appropriée des secrets, pour n’en nommer que quelques-uns.
Les SBOM sont essentiels pour résoudre les problèmes Zero-Day et autres problèmes de composants
Une partie du décret 14028, publié par la Maison Blanche à la mi-2021 pour renforcer la posture de cybersécurité du pays, exige que les producteurs de logiciels fournissent à leurs clients fédéraux une nomenclature logicielle (SBOM). Les SBOM sont essentiellement des enregistrements formels destinés à fournir une visibilité sur tous les composants qui composent un logiciel. Ils fournissent un inventaire détaillé et lisible par machine qui répertorie toutes les bibliothèques, dépendances et composants open source et tiers utilisés dans la création du logiciel.
Qu’une organisation soit contrainte ou non par l’EO 14028, la génération et la gestion de SBOM pour les artefacts logiciels sont une pratique précieuse. Les SBOM sont un outil indispensable pour remédier aux problèmes de composants ou aux vulnérabilités Zero Day. Lorsqu’ils sont stockés dans un référentiel consultable, les SBOM fournissent une carte de l’endroit où existe une dépendance spécifique et permettent aux équipes de sécurité de retracer rapidement les vulnérabilités jusqu’aux composants concernés.
Gouvernez le cycle de vie du développement logiciel avec la stratégie en tant que code
Dans le monde du développement d’applications moderne, des garde-fous à toute épreuve constituent un outil essentiel pour éliminer les erreurs et les actions intentionnelles qui compromettent la sécurité et la conformité. Une bonne gouvernance tout au long de la chaîne d’approvisionnement en logiciels signifie que l’organisation a rendu facile la réalisation des bonnes choses et extrêmement difficile la réalisation des mauvaises choses.
Alors que de nombreuses plates-formes et outils proposent des politiques prêtes à l’emploi qui peuvent être rapidement appliquées, la stratégie en tant que code basée sur la norme industrielle Open Policy Agent permet de créer et d’appliquer des politiques entièrement personnalisables. Politiques régissant tout, depuis les privilèges d’accès jusqu’à l’autorisation ou le refus de l’utilisation des dépendances OSS en fonction de critères tels que le fournisseur, la version, l’URL du package et la licence.
Être capable de vérifier et d’assurer la confiance dans vos artefacts logiciels à l’aide de SLSA
Comment les utilisateurs et les consommateurs peuvent-ils savoir qu’un logiciel est digne de confiance ? Pour déterminer la fiabilité d’un artefact logiciel, vous souhaitez savoir qui a écrit le code, qui l’a construit et sur quelle plate-forme de développement il a été construit. Savoir quels composants contiennent ce serait également quelque chose que vous devriez savoir.
Il est possible de décider de faire ou non confiance à un logiciel une fois que la provenance – l’enregistrement des origines et de la chaîne de possession d’un logiciel – peut être vérifiée. Pour cela, le Cadre de niveaux de chaîne d’approvisionnement pour les artefacts logiciels (SLSA) a été créé. Il donne aux organisations productrices de logiciels la possibilité de capturer des informations sur n’importe quel aspect de la chaîne d’approvisionnement logicielle, de vérifier les propriétés des artefacts et leur construction, et de réduire le risque de problèmes de sécurité. En pratique, il est essentiel pour les organisations productrices de logiciels d’adopter et d’adhérer aux exigences du cadre SLSA et de mettre en œuvre un moyen de vérifier et de générer des attestations logicielles qui sont des déclarations authentifiées (métadonnées) sur les artefacts logiciels tout au long de leurs chaînes d’approvisionnement logicielles.
Compte tenu de l’ampleur et de la complexité de la sécurisation de la chaîne d’approvisionnement logicielle moderne, les orientations ci-dessus ne font qu’effleurer la surface. Mais comme tout le reste dans le monde de la création et du déploiement d’applications modernes, la pratique évolue rapidement. Pour vous aider à démarrer, nous vous recommandons de lire Comment fournir des logiciels en toute sécurité – un ebook rempli de bonnes pratiques conçues pour renforcer votre posture de sécurité et minimiser les risques pour votre entreprise.