Les développeurs de logiciels ont un problème de sécurité de la chaîne d’approvisionnement

Log4j a été le seau d’eau froide qui a réveillé la plupart des développeurs sur leur problème de sécurité de la chaîne d’approvisionnement logicielle.

Nous avons passé des décennies à créer des logiciels et à être obsédés par notre environnement de generation. Mais nous nous appuyons sur des boîtes Jenkins non patchées qui se trouvent sous le bureau de quelqu’un. Nous passons tout ce temps à protéger nos environnements d’exécution, puis à les déployer à l’aide d’outils amateurs.

Nos environnements de design ne sont pas aussi sécurisés que nos environnements de output.

C’est ce qui a conduit à de nombreuses attaques très médiatisées au cours des 12 derniers mois, de SolarWinds à l’attaque Codecov, en passant par la fuite de secrets and techniques Travis CI. Nous sommes devenus si doués pour protéger notre infrastructure que les attaquants ont cherché un moyen furthermore straightforward d’entrer et l’ont trouvé dans les portes que nous avons laissées ouvertes dans la chaîne d’approvisionnement.

Vous ne pouvez pas passer le périmètre de sécurité ? Trouvez simplement une dépendance open source ou une bibliothèque et entrez dans cette voie. Ensuite, pivotez vers tous les shoppers. C’est le piratage de la chaîne d’approvisionnement logicielle moderne.

Nous avons besoin de racines de confiance pour les logiciels

Nous avons des racines de confiance pour les gens d’aujourd’hui. Nous avons une authentification à deux facteurs, nous avons des systèmes d’identification. Ce sont des choses qui attestent de l’identité d’une personne. Et le matériel a la même selected. Nous avons des clés de cryptage. Nous avons du matériel dont nous pouvons être sûrs qu’il n’a pas été altéré au démarrage.

Même en tant qu’internautes, nous avons des racines de confiance. Nous avons des URI, des URN et des URL, en fait les espaces de noms sur World wide web qui relient les identités, les noms et les emplacements des web sites que nous parcourons. Les certificats SSL indiquent à nos navigateurs que les web pages sont sécurisés. Les pare-feu DNS se situent entre les résolveurs récursifs de l’utilisateur pour s’assurer que notre cache n’est pas chargé de mauvaises requêtes. Tout cela se passe dans les coulisses et a été incroyablement efficace pour soutenir des milliards d’internautes pendant des décennies.

Mais nous n’avons pas cela pour les artefacts logiciels aujourd’hui.

Les développeurs font trop confiance implicitement

Prenez un événement aussi courant que l’installation de Prometheus (un projet d’observabilité open resource populaire) à partir du hub d’artefacts de la Cloud Native Computing Basis (CNCF). Si vous effectuez votre installation Helm, puis examinez toutes les pictures qui sont extraites et commencez à exécuter votre cluster, vous voyez de nombreuses visuals de conteneur qui finissent par s’exécuter à partir d’une set up straightforward. Les développeurs confient tout un tas de choses à tout un tas de personnes et de systèmes différents. Chacun d’entre eux pourrait être altéré ou attaqué, ou pourrait être malveillant.

sécurité de la chaîne d'approvisionnement zéro confiance Dan Lorenc

C’est le contraire de Zero Have faith in : nous faisons confiance à des dizaines de systèmes dont nous ne savons rien. Nous ne connaissons pas les auteurs, nous ne savons pas si le code est malveillant, et parce que chaque picture a ses propres artefacts, toute la chaîne d’approvisionnement est récursive. Nous ne faisons donc pas seulement confiance aux artefacts, mais également aux personnes qui ont fait confiance aux dépendances de ces artefacts.

Nous faisons également confiance aux personnes qui gèrent les référentiels. Donc, si les opérateurs du référentiel sont compromis, les compromettants font désormais partie de votre cercle de confiance. Toute personne contrôlant l’un de ces référentiels pourrait changer quelque chose et vous attaquer.

Ensuite, il y a les systèmes de design. Les systèmes de design peuvent être attaqués et insérer du code malveillant. C’est exactement ce qui s’est passé avec Vents solaires. Même si vous connaissez et faites confiance aux opérateurs des illustrations or photos et aux personnes qui exploitent les systèmes qui hébergent les images, si celles-ci sont construites de manière non sécurisée, certains logiciels malveillants peuvent être insérés. Et encore une fois, c’est récursif tout le lengthy. Les mainteneurs de dépendances, les systèmes de building qu’ils utilisent, les gestionnaires d’artefacts sur lesquels ils sont hébergés, ils sont tous minés.

Ainsi, lorsque les développeurs installent des offers logiciels, il y a beaucoup de choses auxquelles ils font implicitement confiance, qu’ils veuillent leur faire confiance ou non.

Les pièges de la sécurité de la chaîne d’approvisionnement logicielle

La pire stratégie que vous puissiez avoir en matière de sécurité de la chaîne d’approvisionnement logicielle est de ne rien faire, ce que font de nombreux développeurs aujourd’hui. Ils permettent à tout de fonctionner sur des environnements de output. Si vous n’avez aucune sécurité sur les artefacts qui peuvent s’exécuter, vous n’avez aucune idée d’où ils viennent. C’est le pire du pire. Ce n’est pas du tout attentif.

L’autorisation de balises spécifiques est le niveau supérieur. Si vous parcourez certains des didacticiels sur les meilleures pratiques avec Kubernetes, c’est assez facile à configurer. Si vous poussez toutes vos images vers un seul emplacement, vous pouvez au moins restreindre les choses à cet emplacement. C’est bien mieux que de ne rien faire, mais ce n’est toujours pas génial, car alors tout ce qui est poussé là-bas est maintenant à l’intérieur de votre cercle de confiance, à l’intérieur de cette clôture de barbelés, et ce n’est pas vraiment Zero Have confidence in. L’autorisation de référentiels spécifiques a les mêmes limitations que l’autorisation de balises spécifiques.

Même les schémas de signature dans la sécurité de la chaîne d’approvisionnement masquent le même problème. Tout ce qui est signé est désormais exécuté, quelle que soit son origine, ce qui entraîne des tonnes d’attaques liées à l’incitation de quelqu’un à signer la mauvaise selected ou à l’impossibilité de révoquer un certificat.

Il est temps de commencer à se poser les bonnes thoughts

Disons que vous marchez sur le trottoir à l’extérieur de votre bureau et que vous trouvez une clé USB posée sur le sol. J’espère que tout le monde sait que vous ne devez absolument pas emporter ce lecteur dans votre bureau et le brancher sur votre poste de travail. Tout le monde dans le logiciel devrait (à juste titre) crier “Non !” De véritables attaques se sont produites de cette façon, et les organisations de sécurité du monde entier martèlent cet avertissement à tous les employés dans le cadre de la formation.

Mais pour une raison quelconque, nous ne nous arrêtons même pas pour réfléchir à deux fois avant de courir docker pull ou npm install, même si cela est sans doute pire que de brancher une clé USB aléatoire. Les deux cases impliquent de prendre le code d’une personne en qui vous n’avez pas confiance et de l’exécuter, mais le conteneur Docker ou le package NPM finira par se rendre jusque dans votre environnement de output !

L’essence de cette évolution de la sécurité de la chaîne d’approvisionnement est qu’en tant qu’industrie, nous nous éloignons de la confiance d’où proviennent les artefacts logiciels et passer beaucoup plus de temps à trouver des racines de confiance pour Quel l’artefact est.

Qui a publié ce binaire ? Remark a-t-il été construit ? Quelle edition de l’outil a été utilisée ? À partir de quelle resource a-t-il été construit ? Qui a signé ce code ? Quelque selected a-t-il été trafiqué ? Ce sont les bonnes issues à se poser.

La semaine prochaine, nous examinerons le paysage open up source en évolution rapide qui forme une nouvelle pile de sécurité pour la sécurité de la chaîne d’approvisionnement, et déballerons les ideas essentiels que les développeurs doivent comprendre – des racines de la confiance à la provenance, en passant par le TPM (Reliable Platform Module ) attestation.

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 Supply 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 systems que nous pensons importantes et les in addition 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 à newtechforum@infoworld.com.

Copyright © 2022 IDG Communications, Inc.