Le fork le plus difficile

Mythos existe. Je sais qu'une grande partie de l'industrie pense qu'il s'agit d'un coup marketing, et je comprends pourquoi. Je comprends. Mais j'ai vu les résultats, et ils sont alarmants. Il ne s'agit pas de « Oups, cette ligne est fausse, et c'est une exécution de code à distance (RCE). » Ce sont des combinaisons inédites de quelques dizaines de problèmes parmi des milliers que n'importe quel scanner SAST détecte déjà, enchaînées pour former quelque chose de bien pire. C'est de la vraie créativité, comme le Coup 37. Ce n'est pas un meilleur scanner. C'est une autre catégorie de menace.

D'une certaine manière, cela n'a même pas d'importance. Même si ce modèle spécifique était un canular, cette capacité finira par voir le jour de toute façon. Certains jours, j'aimerais que ce soit un canular. Nous aurions plus de temps. Mais vous pouvez me croire ou non. Le reste de cet article explique ce que nous allons faire pour y remédier dans les deux cas, et je m'y mets dès maintenant.

Washington suit cela de près depuis un moment, mais on ne peut pas réglementer quelque chose que la majeure partie de l'industrie considère comme inventé. Maintenant que tous les conseils d'administration se préparent (ce qui est le cas), DC peut enfin commencer à réfléchir aux mesures à prendre. Il est clair qu'ils doivent jouer un rôle, mais on ne sait pas encore comment ni lequel. Et ils se trouvent dans une situation très délicate.

Réglementer trop peu, c'est risquer qu'une entreprise américaine crée accidentellement une arme qui met en péril nos infrastructures critiques. Réglementer trop, c'est faire en sorte que la même chose se produise en Chine à la place. Tout cela ressemble à s'y méprendre à des recherches sur le gain de fonction des virus. Tout le monde sait qu'il faut se laver les mains en quittant le labo, mais ce n'est pas parce qu'on le rend obligatoire que le reste du monde fera de même. Nous avons déjà vu comment cette histoire s'est terminée à Wuhan.

Voici le problème structurel qui limite l'action de n'importe quel gouvernement : malgré tous les efforts de l'Europe avec le règlement sur la cyberrésilience (CRA), l'open source ne se gouverne pas. Les lois et les décrets ne s'appliquent pas aux personnes qui, aux quatre coins du monde, publient gratuitement des contenus sur Internet. Les États-Unis l'ont bien compris et concentrent donc leurs efforts là où ils le peuvent et le doivent : sur la consommation. C'est le bon réflexe, et c'est exactement vers quoi se dirige la suite de cet article.

L'écosystème open source et le modèle de consommation ne sont pas prêts pour cela

Je travaille sur ce problème chaque jour de ma vie depuis dix ans. J'ai contribué à la création de OpenSSF et d'Alpha-Omega lorsque j'étais chez Google. J'ai créé Sigstore, Scorecards et les premiers scanners de logiciels malveillants open source. J'ai financé les subventions qui ont permis d'intégrer Rust dans le noyau Linux et l'authentification multifacteur (MFA) sur PyPI. Ensuite, j'ai fondé Chainguard pour commercialiser tout cela à grande échelle. Si je vous dis tout cela, ce n'est pas pour me vanter, mais parce que vous devez me croire quand je dis que la façon dont le monde consomme les logiciels open source est fondamentalement viciée, et qu'aucune amélioration progressive n'y remédiera à temps.

Pas sous sa forme actuelle. Peut-être même jamais. Les choses vont devoir changer.

La plupart des entreprises consomment librement de l'open source depuis des années sans vraiment y réfléchir. Les applications modernes sont des empilements de dépendances, et lorsqu'un problème survient dans l'une d'elles, sa correction peut se propager en cascade dans toute la pile. Pour les grandes organisations dotées de bases de code héritées, ce n'est pas un correctif que l'on règle en un après-midi. Et avancer rapidement comporte aujourd'hui ses propres risques. L'IA a également décuplé les attaques sur la chaîne d'approvisionnement. Se précipiter pour corriger une vulnérabilité sans examen minutieux, c'est s'exposer à installer un malware pire que le problème initial.

La situation est encore plus difficile du côté des mainteneurs. Surtout pour l'immense majorité des mainteneurs qui s'impliquent et veulent aider. Beaucoup ne le font pas, et c'est parfaitement compréhensible. Ils ne doivent rien à ceux qui utilisent leurs projets en aval. Certains des logiciels les plus critiques d'Internet sont maintenus par une ou deux personnes pendant leur temps libre. Les scanners automatisés et les rapports générés par IA les submergent déjà sous un bruit de faible qualité depuis des années. Et contrairement aux logiciels commerciaux, les mainteneurs open source n'ont ni contrats ni accords de niveau de service (SLA). Il n'y a aucune garantie qu'un correctif soit rédigé, fusionné, ni même que l'on puisse joindre la personne.

La divulgation coordonnée des vulnérabilités a été conçue pour une époque où la découverte d'une faille critique nécessitait des semaines de travail d'expert et où les cibles se limitaient à un petit nombre de projets bien connus. Un modèle peut désormais en trouver des centaines du jour au lendemain dans les angles morts. Le système actuel ne va pas suivre, et nous avons tous besoin d'un plan de secours pour les vulnérabilités qui ne sont pas corrigées.

Ce qui doit réellement se passer

Nous avons besoin d'un plan A et d'un plan B.

Plan A : une divulgation coordonnée qui fonctionne réellement à grande échelle. Un groupe unique et de confiance qui achemine les rapports et les correctifs entièrement vérifiés en amont, et soutient les mainteneurs qui souhaitent de l'aide. Pas une douzaine de groupes concurrents qui créent des tickets superflus. Un effort coordonné unique que les mainteneurs reconnaissent et en qui ils ont confiance, afin que leurs rapports remontent en haut de chaque boîte de réception. À l'heure actuelle, Glasswing est parvenu à faire remonter environ 6 % de ses découvertes. Ce programme n'atteindra jamais 100 %. Ce n'est pas ainsi que fonctionne la longue traîne de l'open source. Ma meilleure estimation est que nous pouvons parvenir à une divulgation coordonnée normale, sous de fortes contraintes de temps, pour peut-être 50 % des projets au mieux. Et il faudra beaucoup de travail pour y arriver.

Plan B : comment nous traitons le reste. Et ce n'est pas une division nette. Il y a un immense milieu complexe de projets où le mainteneur répond mais ne peut pas publier de correctif à temps, ou où un correctif existe mais personne en aval ne le récupère. Pour tous ceux-là, et pour les projets dont les mainteneurs ne peuvent pas ou ne veulent pas du tout appliquer de correctifs, nous avons besoin d'un mainteneur de dernier recours. L'open source vous donne le droit de faire un fork. De prendre un projet, d'en assumer la gestion et de le maintenir en vie de manière indépendante. Le fork de projets morts ou sans réponse se produit déjà chaque jour. Mais dans un monde où des centaines de vulnérabilités sont signalées par des dizaines de groupes, nous devons centraliser en un seul endroit la maintenance de ces forks afin que les utilisateurs finaux puissent avoir confiance. Cela impliquera des choix difficiles et des frottements, mais c'est le seul moyen d'éviter la fragmentation.

Il y a un an, cela n'aurait pas été possible à grande échelle. Maintenant, ça l'est. Les mêmes capacités d'IA qui créent cette crise sont celles qui rendent viable un mainteneur de dernier recours. Cette fonction doit reposer sur des bases dotées d'un financement pérenne, de personnel, neutres et de confiance.

Le meilleur moment pour corriger un arbre de dépendances était il y a 20 ans. Le deuxième meilleur moment est maintenant. Et comme le dit le dicton : si vous voulez aller vite, partez seul. Si vous voulez aller loin, partez ensemble. Le problème est que nous devons faire les deux.

Trois bifurcations sur la route

Alors, que faisons-nous réellement ? Il y a trois façons dont cela peut se dérouler, selon la part de ce problème que vous pensez appartenir à quelqu'un d'autre, et le temps qu'il nous faudra pour réaliser que personne ne viendra nous sauver et pour enfin nous reprendre en main.

La naïve : vous ne faites rien et vous espérez. Glasswing corrige tout en amont, votre fournisseur isole par magie chaque charge de travail pour que rien ne puisse s'échapper, votre équipe réécrit votre pipeline de déploiement existant pour livrer toutes les soixante secondes, et votre RSSI dort d'un sommeil paisible pour la première fois depuis 2014. Chaque mainteneur répond à chaque divulgation dans les 24 heures. Chaque entreprise met à jour chaque dépendance le jour de la publication d'un correctif. Personne n'introduit de régression. Personne n'installe de logiciel malveillant déguisé en correctif. Je veux vivre dans ce monde. Nous ne vivons pas dans ce monde.

La chaotique : personne ne centralise. Chaque grand fournisseur de cloud fork ses propres versions de bibliothèques critiques, chacune avec ses propres jeux de correctifs. Trois fournisseurs de sécurité différents proposent des forks concurrents du même framework de journalisation. Votre équipe se retrouve à essayer de déterminer quelle version de quel fork a corrigé quels CVE, et si l'un d'eux en a introduit de nouveaux. C'est l'option par défaut si nous ne faisons rien.

Le fork difficile : une décision délibérée, coordonnée et douloureuse de construire une nouvelle infrastructure de confiance pour la consommation open source. Un pipeline de divulgation unique qui fonctionne à grande échelle. Un lieu de confiance pour les forks maintenus. Des choix difficiles quant aux projets qui sont forkés et aux forks qui survivent. C'est l'option la plus difficile, et c'est la seule qui soit réelle.

L'open source a toujours eu un mécanisme pour cela. Lorsqu'un projet ne peut pas ou ne veut pas s'adapter, vous le fork. Vous en prenez la stewardship, vous faites le travail et vous allez de l'avant. C'est le marché. Ça a toujours été le marché.

Ce qui change maintenant, c'est l'échelle. Nous ne parlons pas de forker un seul projet. Nous parlons de construire l'infrastructure pour forker, maintenir et distribuer des milliers d'entre eux. Sous la pression du temps, avec de vrais adversaires en face. C'est le fork le plus difficile que l'un d'entre nous ait jamais eu à réaliser.

Les mêmes capacités d'IA qui ont créé cette crise sont celles qui la rendent possible. Le logiciel va changer d'une manière qui aurait été inconcevable il y a un an, et je pense qu'un avenir meilleur nous attend de l'autre côté.

Est-ce que tout cela va vraiment fonctionner ? Honnêtement, je n'en ai aucune idée. Mais nous devons commencer, et comme le dit le credo du programmeur : « Nous ne faisons pas cela parce que c'est facile, mais parce que nous pensions que ce serait facile lorsque nous avons commencé. » Celle-ci ne semble même pas facile au départ.