Partage de technologie

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

source:https://thehackernews.com/2024/06/conseils-pratiques-pour-securiser-votre.html

Il n’est pas surprenant que les organisations de production de logiciels soient confrontées à une pression réglementaire et juridique croissante pour protéger leurs chaînes d’approvisionnement et garantir l’intégrité de leurs logiciels. 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 une opportunité d’augmenter leurs attaques de plusieurs ordres de grandeur. Par exemple, regardez les vulnérabilités Log4j en 2021. Log4j (un framework de journalisation open source maintenu par Apache et utilisé dans d'innombrables applications différentes) était à l'origine de vulnérabilités qui mettaient en danger des milliers de systèmes.

La fonctionnalité de communication de Log4j est vulnérable, offrant ainsi aux attaquants la possibilité d'injecter du code malveillant dans les journaux, qui peut 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 une nouvelle étude de Gartner, près de la moitié des entreprises seront la cible d’attaques sur la chaîne d’approvisionnement logicielle d’ici 2025.

Mais qu’est-ce qu’une supply chain logicielle ? Premièrement, il est défini comme la somme de tous les codes, personnes, systèmes et processus au sein et à l’extérieur d’une organisation qui contribuent au développement et à la fourniture d’artefacts logiciels. Ce qui rend la sécurisation de la chaîne d’approvisionnement logicielle si difficile, c’est la complexité et la nature 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 des référentiels de code et des registres d'artefacts étendus, des pipelines CI/CD et des ressources d'infrastructure pour créer et déployer des applications.

Alors que la sécurité et la conformité ont toujours été des préoccupations majeures pour les entreprises, la protection de la chaîne d'approvisionnement logicielle d'une organisation est de plus en plus difficile. Cependant, de nombreuses organisations ont réalisé des progrès substantiels dans la mise en œuvre des pratiques DevSecOps, et 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 qui peuvent faire avancer vos efforts de sécurité de la chaîne d’approvisionnement logicielle dans la bonne direction.

Tenir compte de tous les aspects de la chaîne d'approvisionnement logicielle lors de l'application de la sécurité

Étant donné que plus de 80 % des bases de code contiennent au moins une vulnérabilité open source, les dépendances aux logiciels libres sont naturellement devenues un élément central de la sécurité de la chaîne d'approvisionnement logicielle. Cependant, la chaîne d'approvisionnement logicielle moderne comprend d'autres entités dont la posture de sécurité est soit négligée, soit mal comprise au sein de l'organisation pour être correctement gérée. 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 des évaluations de conformité régulières.

Des cadres tels que le Top-10 OWASP pour les références de sécurité de la chaîne d'approvisionnement des logiciels CI/CD et CIS. Le respect de ces cadres nécessitera un RBAC précis, appliquant le principe du moindre privilège, analysant les conteneurs et l'infrastructure en tant que code pour détecter les vulnérabilités et les erreurs de configuration, isolant les builds, intégrant les tests de sécurité des applications et gérant correctement les secrets, pour n'en nommer que quelques-uns.

SBOM est essentiel pour résoudre les problèmes de type Zero Day et d'autres 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 une nomenclature logicielle (SBOM) à leurs clients fédéraux. Les SBOM sont essentiellement des enregistrements formels conçus pour offrir une visibilité sur tous les composants qui composent le logiciel. Ils fournissent une liste détaillée, lisible par machine, de toutes les bibliothèques, dépendances et composants open source et tiers utilisés pour créer le logiciel.

Qu'une organisation soit ou non mandatée par l'EO 14028, la génération et la gestion de SBOM pour les artefacts logiciels sont une pratique précieuse. SBOM est un outil indispensable pour résoudre les problèmes de composants ou les vulnérabilités zero-day. Lorsqu'il est stocké dans un référentiel consultable, SBOM fournit une carte de la présence de dépendances spécifiques et permet aux équipes de sécurité de retracer rapidement les vulnérabilités jusqu'au composant affecté.

Gérer le cycle de vie du développement logiciel en utilisant la politique 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 les organisations ont rendu facile de faire les bonnes choses et extrêmement difficile de faire les mauvaises choses.

Alors que de nombreuses plates-formes et outils proposent des politiques prêtes à l'emploi qui peuvent être rapidement exécutées, Policy-as-Code, basé sur la norme industrielle Open Policy Agent, permet la création et l'exécution de politiques entièrement personnalisables. Gérez les politiques allant des autorisations d'accès à l'autorisation ou au 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.

Possibilité de vérifier et d'assurer la confiance dans vos artefacts logiciels à l'aide de SLSA

Comment les utilisateurs et les consommateurs savent-ils qu’un logiciel est digne de confiance ? Lorsque vous déterminez la fiabilité d'un artefact logiciel, vous devez 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 se trouvent à l’intérieur est également quelque chose que vous devez savoir.

Une fois que vous pouvez vérifier la provenance (un enregistrement des origines et de la chaîne de contrôle du logiciel), vous pouvez décider de faire ou non confiance au logiciel. À cette fin, le cadre SLSA (Supply Chain Level of Software Artifacts) a été créé. Il permet aux organisations de production de logiciels 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 de leurs versions, et de réduire le risque de problèmes de sécurité. En pratique, les organisations de production de logiciels doivent adopter et se conformer aux exigences du cadre SLSA et mettre en œuvre une méthode de validation et de génération d'attestations logicielles, qui sont des déclarations authentifiées (métadonnées) sur les artefacts logiciels tout au long de la chaîne d'approvisionnement logicielle.