À qui appartient la sécurité de la chaîne d’approvisionnement logicielle ? Développeurs ? Ou les équipes d’ingénierie de la plate-forme et de la sécurité qui les soutiennent ?
Auparavant, le CIO, le CISO ou le CTO et leur équipe de sécurité décidaient de la distribution Linux, du système d’exploitation et de la plate-forme d’infrastructure dont l’entreprise obtiendrait ses contrats de support et ses SLA de sécurité. Aujourd’hui, les développeurs font tout cela dans Docker Files et GitHub Steps, et il n’y a pas le même style de surveillance organisationnelle qui existait avant que les choses ne passent aux développeurs.
Aujourd’hui, les équipes de conformité et de sécurité définissent les politiques et les exigences de niveau supérieur, tandis que les développeurs ont la possibilité de choisir l’outil qu’ils souhaitent, à issue qu’il réponde à ces exigences. C’est une séparation des préoccupations qui accélère considérablement la productivité des développeurs.
Mais comme je l’ai écrit précédemment, Log4j a été le seau d’eau froide qui a réveillé les organisations confront à un problème de sécurité systémique. Même au milieu de toute cette autonomie des développeurs et de cette productivité, les composants open up supply qui composent leur chaîne d’approvisionnement logicielle sont devenus la nouvelle cible préférée des mauvais acteurs.
L’open supply est idéal pour les développeurs et idéal pour les attaquants
La sécurité du réseau est devenue un vecteur d’attaque beaucoup as well as difficile pour les attaquants qu’auparavant. Mais open up-supply ? Trouvez simplement une dépendance open up resource ou une bibliothèque, entrez de cette façon, puis pivotez vers toutes les autres dépendances. Les chaînes d’approvisionnement concernent vraiment les liens entre les organisations et leurs artefacts logiciels. Et c’est avec ça que les attaquants s’amusent tellement aujourd’hui.
Ce qui rend le logiciel open up source idéal pour les développeurs le rend également idéal pour les pirates.
C’est ouvert
Les développeurs adorent : tout le monde peut voir le code et tout le monde peut y contribuer. Linus Torvalds a dit : « De nombreux globes oculaires rendent tous les bogues superficiels », et c’est l’un des grands avantages de l’open source. In addition les gens regardent les choses, additionally les bugs sont susceptibles d’être trouvés.
Les attaquants adorent : toute personne disposant d’un compte GitHub peut contribuer au code des bibliothèques critiques. Les commits de code malveillants se produisent fréquemment. Les bibliothèques sont prises en demand et transférées à différents propriétaires qui n’ont pas à l’esprit les meilleurs intérêts de chacun.
Un exemple célèbre était le plugin Chrome appelé The Terrific Suspender. La personne qui la maintenait l’a transmise à quelqu’un d’autre qui a immédiatement commencé à brancher des logiciels malveillants. Il existe de nombreux exemples de ce kind de changement de contributeur bienveillant à contributeur malveillant.
C’est transparent
Les développeurs adorent : s’il y a des problèmes, vous pouvez les examiner, les trouver et auditer le code.
Les attaquants adorent : le grand volume d’open supply rend l’audit de code peu pratique. De furthermore, une grande partie du code est distribuée dans une supply différente de la façon dont il est réellement consommé.
Par exemple, même si vous regardez le code supply d’un bundle Python ou Node.js, lorsque vous exécutez pip put in ou npm put invous récupérez en fait un offer à partir de ce qui a été compilé, et il n’y a aucune garantie que le deal provienne réellement du code source que vous avez audité.
Selon la façon dont vous consommez le code resource, si vous ne récupérez pas réellement le code resource et ne compilez pas à partir de zéro à chaque fois, une grande partie de la transparence peut être une illusion. Un exemple célèbre est la violation de Codecov, où le programme d’installation était un script bash qui a été compromis et auquel un logiciel malveillant a été injecté pour voler des tricks. Cette brèche a été utilisée comme pivot vers d’autres versions qui pourraient être altérées.
C’est gratuit
Les développeurs adorent : l’open resource est livré avec une licence qui garantit votre capacité à utiliser librement le code que d’autres ont écrit, et c’est génial. C’est beaucoup furthermore facile que de devoir passer par l’approvisionnement pour faire améliorer un logiciel en interne.
Les attaquants adorent : Attaque cardiaque à partir de 2014 a été le premier sign d’alarme montrant à quel level l’infrastructure critique d’Internet fonctionne grâce au travail bénévole. Un autre exemple célèbre était une bibliothèque Golang appelée Jwt-go. C’était une bibliothèque très populaire utilisée dans l’ensemble de l’écosystème Golang (y compris Kubernetes), mais lorsqu’une vulnérabilité a été découverte à l’intérieur, le responsable n’était plus là pour fournir des correctifs. Cela a conduit au chaos où les gens ont créé différents correctifs pour corriger le bogue. À un moment donné, il y avait cinq ou six versions de correctifs concurrentes pour le même bogue, toutes faisant le tour de l’arborescence des dépendances, avant qu’un seul correctif n’émerge et corrige la vulnérabilité pour toujours.
L’open resource est également idéal pour la sécurité de la chaîne d’approvisionnement logicielle
La seule façon de renforcer tous ces liens est de travailler ensemble. Et la communauté est notre additionally grande power. Après tout, la communauté open up resource – tous les mainteneurs du projet qui ont consacré leur temps et leurs attempts et partagé leur code – ont rendu l’open resource omniprésente dans l’industrie et dans la chaîne d’approvisionnement de chacun. Nous pouvons tirer parti de cette même communauté pour commencer à sécuriser cette chaîne d’approvisionnement.
Si vous souhaitez suivre l’évolution de ce domaine de la sécurité de la chaîne d’approvisionnement logicielle, que vous soyez développeur ou membre d’une plate-forme ou d’une équipe d’ingénieurs en sécurité, voici quelques-uns des projets open up supply auxquels vous devriez prêter attention :
SLSA
SLSA (Source chain Levels for Software package Artifacts, prononcé « salsa ») est un ensemble prescriptif et progressif d’exigences pour la sécurité du système de design. Il existe quatre niveaux que l’utilisateur interprète et implémente. Le niveau 1 consiste à utiliser un système de development (ne le faites pas à la key sur un ordinateur portable). Le niveau 2 consiste à exporter certains journaux et métadonnées (afin que vous puissiez ensuite rechercher des éléments et réagir aux incidents). Le niveau 3 consiste à suivre une série de bonnes pratiques. Le niveau 4 consiste à utiliser un système de construction vraiment sécurisé.
tekton
tekton est un système de construction open up source conçu dans un souci de sécurité. De nombreux systèmes de development peuvent fonctionner de manière sécurisée. Tekton est un exemple phare de bons défauts avec SLSA intégré.
In-Toto
In-Toto et TUF (ci-dessous) sont tous deux sortis d’un laboratoire de recherche à NYU des années avant que quiconque ne parle de sécurité de la chaîne d’approvisionnement logicielle. Ils enregistrent l’ensemble correct des étapes qui se produisent au cours d’une chaîne d’approvisionnement et relient des chaînes cryptographiques qui peuvent être vérifiées conformément aux politiques. In-Toto se concentre sur le côté design, tandis que TUF se concentre sur le côté distribution (a-t-il été trafiqué ?).
TUF
TUF (The Update Framework) gère les systèmes de mise à jour automatique, les gestionnaires de paquets, la distribution et les ensembles de responsables qui se déconnectent via le quorum. TUF est également spécialisé dans la récupération de clés cryptographiques lorsque de mauvaises choses se produisent.
Sigstore
Sigstore est un cadre de signature de code gratuit et very simple pour les artefacts logiciels open up source. La signature est un moyen d’établir une chaîne de contrôle cryptographiquement vérifiable, c’est-à-dire un enregistrement infalsifiable des origines du logiciel.
De meilleurs garde-fous pour la chaîne d’approvisionnement logicielle
Au cours des 10 dernières années, le choix de l’outillage et la sécurité a été déplacée vers la gauche pour les développeurs. Je pense que nous allons voir les développeurs continuer à conserver leur autonomie dans la sélection des meilleurs outils à utiliser, mais que la responsabilité d’une posture de sécurité gouvernante et des politiques associées doit revenir à la droite.
Une idée fausse courante est que les équipes de sécurité passent leurs journées à examiner le code ligne par ligne pour trouver des bogues de sécurité et s’assurer qu’il n’y a pas de vulnérabilités. Ce n’est pas du tout comme ça que ça marche. Les équipes de sécurité sont beaucoup furthermore petites que les équipes de développeurs. Ils sont là pour mettre en place des processus pour aider les développeurs à faire les bons choix et à éliminer Des lessons des vulnérabilités, plutôt qu’un bogue de sécurité à la fois. C’est la seule façon pour la sécurité de suivre le rythme d’équipes de centaines d’ingénieurs.
Les équipes de sécurité ont besoin d’un ensemble standard de processus pour verrouiller les racines de confiance des artefacts logiciels, et les développeurs ont besoin d’une voie claire pour équilibrer la sélection open supply par rapport à des politiques de sécurité clairement définies. L’open resource a posé le problème, et l’open source aidera à trouver les réponses. Un jour, les développeurs ne déploieront que des illustrations or photos qui ont été vérifiées pour prévenir les vulnérabilités connues.
Dan Lorenc est PDG et co-fondateur de Garde-chaîne. Auparavant, il était ingénieur logiciel et responsable de l’équipe de sécurité Open up Source de Google (GOSST). Il a fondé des projets comme Minikube, Skaffold, TektonCD et Sigstore.
—
Le New Tech Forum offre un lieu pour explorer et discuter des technologies d’entreprise émergentes avec une profondeur et une ampleur sans précédent. La sélection est subjective, basée sur notre sélection des technologies que nous pensons importantes et les furthermore intéressantes pour les lecteurs d’InfoWorld. InfoWorld n’accepte pas les supports advertising and marketing pour publication et se réserve le droit de modifier tout le contenu contribué. Envoyez toutes les demandes à [email protected]