INTERVIEW La sécurité de la chaîne d’approvisionnement des logiciels est montée en flèche dans l’agenda de la sécurité informatique depuis la dernière conversation avec Brian Fox, co-fondateur et CTO du fournisseur DevSecOps Sonatype.
Le bogue historique Log4j et l’attaque de la chaîne d’approvisionnement SolarWinds en particulier ont incité la Maison Blanche à agir avec une clarté, une rapidité et même un soutien bipartisan qui s’est avéré insaisissable dans d’autres domaines politiques.
Fox, qui a tiré la sonnette d’alarme sur la sécurité de la chaîne d’approvisionnement pendant de nombreuses années, a salué la reconnaissance tardive de la menace par le gouvernement, mais prévient que l’industrie de la cybersécurité ne parvient toujours pas à prioriser suffisamment le problème.
Deux ans après notre dernière interview, le membre récemment nommé du conseil de gouvernance d’OpenSSF considère également l’héritage de « Log4Shell », repousse les critiques du modèle open source piloté par des bénévoles et prévoit que les techniques d’attaque vont muter lorsque les défenseurs se « vaccineront » enfin contre les méthodes actuelles. .
Daily Swig : Sonatype a soutenu les efforts de la Maison Blanche pour renforcer la chaîne d’approvisionnement en logiciels – comment cela progresse-t-il ?
Brian Fox : À la suite de l’incident de Log4j, il y a eu un premier [open source security] sommet en janvier, témoignages devant le Sénat et enquêtes au Sénat et à la Chambre, puis la Maison Blanche a convoqué quelques réunions.
Un sommet de suivi en mai avec de nombreux participants de tout l’écosystème [resulted in a] Plan de mobilisation en 10 points qui comprend tout, depuis une meilleure éducation des développeurs autour des pratiques sécurisées, à un meilleur outillage, au financement, aux audits de projets open source populaires, à la hiérarchisation des projets les plus utilisés, à la conduite d’un meilleur outillage autour des nomenclatures logicielles, [and] signatures numériques…
A NE PAS MANQUER Le bug « endémique » de Log4j devrait persister dans la nature pendant au moins une décennie, prévient le gouvernement américain
Un certain nombre d’entreprises ont fait des promesses monétaires – [totalling] environ 30 millions de dollars – pour aider cet effort, ce qui est beaucoup, mais les estimations [of the sum needed] pour conduire les 10 flux ressemblait plus à 150 millions de dollars [over two years].
Il y a d’autres tentatives de pourparlers qui essaient d’impliquer d’autres gouvernements, parce que ce n’est pas seulement un problème centré sur les États-Unis ; c’est un problème mondial.
DS : Alors, êtes-vous rassuré que le gouvernement américain s’attaque au problème globalement de la bonne manière ?
BF : Généralement, oui. Le décret exécutif d’il y a un peu plus d’un an a mis en place des exigences pour que toute personne vendant des logiciels au gouvernement américain ait une nomenclature logicielle reproductible. [SBOM] pour divulguer tous les composants – pensez aux étiquettes des aliments.
Cependant, il y avait un [similar] projet de loi devant le Congrès en 2013 qui n’a pas eu de temps d’antenne. C’est donc bien de voir cela se produire maintenant, mais il aurait été préférable que cela se produise il y a presque dix ans.
Je pense qu’il y aura un effet d’entraînement. Même les éditeurs de logiciels qui ne vendent pas directement au gouvernement américain, si leurs consommateurs vendent au gouvernement américain, ils devront fournir une nomenclature complète, n’est-ce pas ?
DS : Êtes-vous toujours aussi frustré qu’en 2020, lorsque vous déploriez que « de nombreuses entreprises n’aient toujours pas d’inventaires de leurs composants open source » ?
BF : Ça s’améliore, mais je suis impatient. Dans le sillage de Log4j, en mai 2022, 33 % des téléchargements de Log4j depuis le référentiel central au cours des dernières 24 heures étaient des versions vulnérables connues.
Plus de six mois après [from the Log4j bug surfacing], était-ce acceptable ? Tout le monde a eu une panique collective, tout le monde écrivait à ce sujet – il n’y a aucune raison pour que vous ne le sachiez pas.
Souvent, les entreprises qui ont de très bonnes pratiques en matière de pièces physiques ont de terribles pratiques en matière de biens numériques – cela me coupe le souffle. Je ne comprends pas pourquoi je dois les éduquer.
INTERVIEW PRÉCÉDENTE Brian Fox de Sonatype sur la sécurité open source et DevSecOps « sans drame »
Le plan de mobilisation se concentre en grande partie sur l’amélioration des projets open source. Cela doit être fait, mais cela passe largement à côté du fait que les organisations ont la responsabilité de comprendre quels composants elles utilisent.
Prendre le Incident de l’airbag Takata. Disons tout le [automotive] les fabricants disaient : « nous allons donner plus d’argent à Takata pour fabriquer de meilleurs airbags, nous n’avons donc plus besoin de suivre les pièces qui entrent dans nos voitures » – nous nous moquions d’eux. Mais c’est un peu ce qui se passe en ce moment [in the software supply chain].
Log4j a été corrigé et corrigé pendant Thanksgiving [within a day of the proof of concept surfacing] – mais cela ne résout pas ce problème [of users not updating their systems].
DS : Que pensez-vous des critiques du modèle volontaire de l’écosystème open source ?
BF : Je ne pense pas que jeter de l’argent sur les mainteneurs résout le problème. En fait, cela peut souvent compliquer les choses, car vous avez alors de nouvelles personnes motivées uniquement par l’argent.
La plupart des problèmes ne sont pas aussi simples que [maintainers] faire un travail terrible. Prenez Log4j – ce n’était même pas vraiment un bogue dans le code. C’était une interaction étrange entre une fonctionnalité de Log4j et une fonctionnalité de l’environnement d’exécution Java qui exécutait le code JNDI.
La réaction instinctive est : « Ce sont des bénévoles, donc ce doivent être des amateurs » – et ce n’est tout simplement pas vrai. La plupart des personnes travaillant sur ces projets sont en fait de très bons développeurs de logiciels travaillant pour de grandes entreprises pendant la journée. Souvent, les entreprises les paient pour travailler sur ces projets.
DS : Pouvez-vous résumer le paysage actuel des menaces open source et comment Sonatype aide les développeurs à protéger l’écosystème ?
BF : Il y a une attaque théorique où un committer malveillant se présente à un projet populaire et met quelque chose de malveillant dans un vrai package. Jusqu’à présent, cela ne se produit pas.
Parce que les consommateurs ne font pas assez attention, il est très facile de les confondre en créant un faux composant contenant un logiciel malveillant qui ressemble au composant réel.
Nous essayons de détecter les composants malveillants ou anormaux et d’empêcher les consommateurs d’y accéder via notre produit pare-feu. La [attack] les cibles sont les développeurs et l’infrastructure de développement, et le mauvais comportement – la porte dérobée – est déclenché dès que vous le téléchargez. Ils n’essaient pas de glisser du code dans votre logiciel pour qu’il soit distribué à votre utilisateur final ou à la production.
Donc, la seule façon d’empêcher cela est de savoir, en temps réel, quand ce composant arrive sur le dépôt public, qu’il y a quelque chose qui ne va pas, et de pouvoir l’arrêter.
La ponctualité est super importante. Le retrouver six semaines plus tard ne sert à rien car pendant ce temps [time] tous ceux qui l’ont touché ont été souillés.
Nous utilisons un MLAI [machine learning, artificial intelligence] technique, afin que nous puissions nous entraîner sur de nouvelles attaques et que le modèle s’améliore de plus en plus. Depuis le mois dernier, nous avons signalé plus de 88 000 paquets malveillants utilisant cette technique, c’est donc des centaines d’ordres de grandeur de plus [productive] que la recherche zero-day.
DS : Sommes-nous susceptibles de voir des attaquants innover de la manière que vous envisagez – empoisonner directement les projets plutôt que duper les développeurs – de si tôt ?
BF : Ils continuent d’exploiter le vecteur cible dont je parlais avec des attaques parfois plus avancées, mais beaucoup ressemblent à des imitateurs.
Nous avons déjà vu ce modèle. C’est un peu comme Covid – si tout le monde reçoit le vaccin, une mutation trouve un moyen de la contourner et c’est celle qui survit.
Mais pas assez de personnes sont immunisées contre la série d’attaques actuelle, nous ne voyons donc pas une tonne d’innovations.
C’est pourquoi nous en trouvons et en signalons des dizaines chaque jour. C’est ridicule.
Mais que se passe-t-il quand nous devenons vraiment bons à [defense]? Pendant plus d’une décennie et demie, j’ai eu peur que les attaquants commencent à se concentrer sur la chaîne d’approvisionnement. Cela n’a commencé à se produire qu’en 2019.
Donc, si nous parvenons à bloquer ces éléments faciles à détecter, vous les verrez se déplacer dans les projets avec des attaques plus insidieuses et difficiles à détecter.
La [White House] Le plan de mobilisation aidera les projets open source à devenir intrinsèquement plus sûrs, mais c’est un long chemin, donc je crains que nous n’y arrivions pas assez vite.
DS : Dans quelle mesure l’industrie a-t-elle été réceptive à votre message sur la protection de la chaîne d’approvisionnement ?
BF : Une grande partie de l’industrie mène toujours la bataille de la dernière décennie, qui consiste à effectuer des analyses statiques, à hiérarchiser les vulnérabilités et à analyser les produits avant qu’ils ne soient mis en production ou distribués en aval.
Dans les années 1990, les navigateurs présentaient des vulnérabilités partout et, vous ne le saviez pas, vous pouviez être piraté simplement en chargeant un site Web néfaste.
C’est un peu ce qui se passe avec ces attaques malveillantes. Les développeurs saisissent le mauvais composant, qui n’essaie pas de compiler – c’est littéralement juste une charge utile pour fournir une porte dérobée ou faire ce qu’il fait. Ainsi, la construction du développeur échoue et il se rend compte que ce n’est pas le composant qu’il voulait [but not only that] ils ont potentiellement été piratés.
Si vous ne vérifiez que ce que les développeurs ont engagé ou construisent pour la publication, vous êtes aveugle à ces 88 000 et plus [monthly] attaques contre les machines des développeurs.
Nous nous sommes vraiment penchés sur ce message et beaucoup de gens s’y accrochent enfin.
