Mythos bestaat echt. Ik weet dat een groot deel van de industrie denkt dat het een marketingstunt is, en ik begrijp waarom. Ik snap het. Maar ik heb de bevindingen gezien en ze zijn slecht. Dit zijn geen “oeps, deze zin hier is verkeerd, en dat is RCE.” Het zijn nieuwe combinaties van enkele tientallen problemen uit duizenden dingen die elke SAST-scanner al vindt, aan elkaar geketend tot iets veel ergers. Het is echte creativiteit, zoals Move 37. Dat is geen betere scanner. Dat is een andere categorie van bedreigingen.
In sommige opzichten maakt het niet eens uit. Zelfs als dit specifieke model een hoax zou zijn, komt de mogelijkheid hoe dan ook. Op sommige dagen zou ik willen dat het een hoax was. We zouden meer tijd hebben. Maar je kunt me geloven of niet. De rest van dit bericht gaat over wat we er hoe dan ook aan doen, en ik ga nu aan de slag.
Washington houdt dit al een tijdje in de gaten, maar je kunt niet iets reguleren waarvan het grootste deel van de industrie denkt dat het verzonnen is. Nu elke bestuurskamer zich in de voorbereidingsmodus bevindt (en dat is ook zo), kan DC eindelijk gaan nadenken over welke stappen ze kunnen nemen. Het is duidelijk dat ze een rol moeten spelen, maar het is niet duidelijk hoe en wat die zou moeten zijn. En ze zitten in een hele moeilijke situatie.
Als u te weinig reguleert, loopt u het risico dat een in de VS gevestigd bedrijf per ongeluk een wapen maakt dat onze kritieke infrastructuur in gevaar brengt. Als je te veel reguleert, gebeurt hetzelfde in China. Het geheel voelt als gain-of-function-onderzoek naar virussen. Iedereen weet dat je je handen moet wassen voordat je het laboratorium verlaat, maar het feit dat wij het verplicht stellen betekent niet dat de rest van de wereld dat ook doet. We hebben al gezien hoe dat verhaal gaat in Wuhan.
Hier is het structurele probleem dat de mogelijkheden van elke overheid beperkt: ondanks Europa’s beste pogingen met de CRA is open source niet bestuurbaar. Wetten en uitvoeringsbesluiten zijn niet van toepassing op mensen over de hele wereld die dingen gratis op internet zetten. De VS beseffen dit, dus concentreren ze zich waar ze kunnen en waar ze moeten: op de consumptie. Dat is het juiste instinct, en het is precies waar de rest van dit bericht naartoe gaat.
Het open source ecosysteem en consumptiemodel is hier niet klaar voor
Ik heb de afgelopen tien jaar elke dag van mijn leven aan dit probleem gewerkt. Toen ik bij Google werkte, heb ik meegeholpen aan de oprichting van OpenSSF en Alpha-Omega. Ik heb Sigstore, Scorecards en de eerste open source malwarescanners gemaakt. Ik financierde de subsidies die Rust in de Linux-kernel en MFA op PyPI brachten. Toen startte ik Chainguard om dit allemaal commercieel en op grote schaal te doen. Ik vertel je dit allemaal niet om op te scheppen, maar omdat je me moet geloven als ik zeg: de manier waarop de wereld open source-software consumeert is fundamenteel kapot, en geen enkele stapsgewijze verbetering zal dit op tijd kunnen repareren.
Niet in zijn huidige vorm. Misschien nooit. Het zal moeten veranderen.
De meeste bedrijven gebruiken open source al jaren vrijelijk zonder er echt over na te denken. Moderne apps zijn lagen van afhankelijkheden, en als er iets misgaat in een ervan, kan het oplossen ervan door een hele stapel stromen. Voor grote organisaties met verouderde codebases is dat geen middagoplossing. En snel handelen heeft nu zijn eigen risico’s. AI heeft ook de supply chain-aanvallen een boost gegeven. Haast je om een kwetsbaarheid te patchen zonder zorgvuldige controle, en je zou malware kunnen installeren die erger is dan het oorspronkelijke probleem.
De kant van de beheerder is nog moeilijker. Vooral voor het enorme deel van de beheerders die erom geven en willen helpen. Velen doen dat niet, en dat is helemaal prima. Ze zijn hun stroomafwaartsen niets verschuldigd. Sommige van de meest kritische software op internet worden in hun vrije tijd door een of twee mensen onderhouden. Geautomatiseerde scanners en door AI gegenereerde rapporten begraven ze al jaren in ruis van lage kwaliteit. En in tegenstelling tot commerciële software hebben open source-beheerders geen contracten of SLA’s. Er is geen garantie dat een patch wordt geschreven, samengevoegd of dat de persoon zelfs maar bereikbaar is.
Gecoördineerde openbaarmaking van kwetsbaarheden is ontworpen voor een wereld waarin het vinden van een ernstige kwetsbaarheid wekenlang deskundig werk vergde en de doelen een klein aantal bekende projecten waren. Een model kan er nu honderden in de lange staart vinden. Het bestaande systeem zal het niet bij kunnen houden, en we hebben allemaal een back-upplan nodig voor de kwetsbaarheden die niet worden gepatcht.
Wat er eigenlijk moet gebeuren
We hebben een plan A en een plan B nodig.
Plan A: gecoördineerde openbaarmaking die daadwerkelijk op schaal werkt. Eén enkele, vertrouwde groep die volledig gecontroleerde rapporten en patches stroomopwaarts stuurt, en de beheerders ondersteunt die hulp nodig hebben. Niet een dozijn concurrerende groepen die luidruchtige kaartjes indienen. Eén gecoördineerde inspanning die beheerders herkennen en vertrouwen, zodat hun rapporten bovenaan elke inbox terechtkomen. Op dit moment is Glasswing erin geslaagd om ongeveer 6% van zijn bevindingen upstream te krijgen. Dit programma zal nooit 100% bereiken. Dat is niet hoe de lange staart van open source werkt. Mijn beste inschatting is dat we normale, gecoördineerde openbaarmaking kunnen bewerkstelligen, onder moeilijke tijden, voor op zijn best misschien 50% van de projecten. En het zal veel werk vergen om daar te komen.
Plan B: hoe we met de rest omgaan. En het is geen schone splitsing. Er is een enorme rommelige middenmoot van projecten waarbij de onderhouder reageert maar niet op tijd een oplossing kan leveren, of waarbij er een patch bestaat maar niemand stroomafwaarts deze oppikt. Voor al deze problemen, en voor de projecten waarbij beheerders helemaal niet kunnen of willen patchen, hebben we in laatste instantie een beheerder nodig. Open source geeft je het recht om te forken. Als u een project wilt aannemen, moet u het rentmeesterschap op u nemen en het zelfstandig in leven houden. Het afbreken van dode of niet-reagerende projecten gebeurt al elke dag. Maar in een wereld waarin honderden kwetsbaarheden worden gerapporteerd door tientallen groepen, moeten we ons op één plek centraliseren om de forks te onderhouden waarop eindgebruikers kunnen vertrouwen. Het zal harde oproepen en gekwetste gevoelens met zich meebrengen, maar het is de enige manier waarop we fragmentatie kunnen voorkomen.
Een jaar geleden zou dit op grote schaal niet mogelijk zijn geweest. Nu is het zo. Dezelfde AI-capaciteiten die deze crisis veroorzaken, maken een onderhouder van laatste redmiddel levensvatbaar. Die functie moet ergens leven waar het duurzaam gefinancierd, bemand, neutraal en vertrouwd is.
De beste tijd om een afhankelijkheidsboom te repareren was twintig jaar geleden. De volgende beste tijd is nu. En het gezegde luidt: als je snel wilt gaan, ga dan alleen. Als je ver wilt komen, ga dan samen. Het probleem is dat we beide moeten doen.
Drie splitsingen in de weg
Dus wat doen we eigenlijk? Er zijn drie manieren waarop dit zich afspeelt, afhankelijk van hoeveel van dit probleem je denkt dat iemand anders moet oplossen, en hoe lang het duurt voordat we erachter komen dat niemand ons komt redden en de zaken daadwerkelijk op orde krijgt.
De naïeve: je doet niets en hoopt. Glasswing herstelt alles stroomopwaarts, uw leverancier sandboxt op magische wijze elke werklast zodat niets kan ontsnappen, uw team herschrijft uw bestaande implementatiepijplijn zodat deze elke zestig seconden wordt verzonden, en uw CISO slaapt voor het eerst sinds 2014 de hele nacht door. Elke onderhouder reageert binnen 24 uur op elke openbaarmaking. Elk bedrijf werkt elke afhankelijkheid bij op de dag dat er een patch verschijnt. Niemand introduceert een regressie. Niemand installeert malware vermomd als patch. Ik wil in deze wereld leven. Wij leven niet in deze wereld.
De chaotische: niemand centraliseert. Elke grote cloudprovider hanteert zijn eigen versies van kritische bibliotheken, elk met zijn eigen patchsets. Drie verschillende beveiligingsleveranciers leveren concurrerende forks van hetzelfde logframework. Jouw team probeert erachter te komen welke versie van welke fork welke CVE’s heeft opgelost, en of een van deze nieuwe heeft geïntroduceerd. Dit is de standaard als we niets doen.
De harde vork: een doelbewuste, gecoördineerde, pijnlijke beslissing om een nieuwe vertrouwensinfrastructuur op te bouwen voor open source-consumptie. Eén openbaarmakingspijplijn die op schaal werkt. Eén vertrouwd adres voor onderhouden vorken. Moeilijke vragen over welke projecten worden gevorkt en welke vorken overleven. Dit is de moeilijkste optie, en het is de enige echte.
Open source heeft hier altijd een mechanisme voor gehad. Wanneer een project zich niet kan of wil aanpassen, splitst u het op. Jij neemt het rentmeesterschap op je, jij doet het werk en je gaat vooruit. Dat is de afspraak. Het is altijd de afspraak geweest.
Wat nu anders is, is de schaal. We hebben het niet over het afsplitsen van één project. We hebben het over het bouwen van de infrastructuur om duizenden ervan te splitsen, te onderhouden en te distribueren. Onder tijdsdruk, met echte tegenstanders aan de andere kant. Dat is de moeilijkste vork die iemand van ons ooit heeft moeten maken.
Dezelfde AI-capaciteiten die deze crisis hebben veroorzaakt, zijn degenen die dit mogelijk maken. Software gaat veranderen op manieren die een jaar geleden ondenkbaar waren, en ik denk dat er aan de andere kant een mooiere toekomst ligt.
Gaat dit allemaal echt werken? Ik heb eerlijk gezegd geen idee. Maar we moeten beginnen, en zoals het Credo van de Programmeur zegt: “We doen dit niet omdat het gemakkelijk is, maar omdat we dachten dat het gemakkelijk zou zijn toen we begonnen.” Deze voelt in het begin niet eens gemakkelijk aan.
Ontvang het laatste nieuws op de Chainguard-blog.
Opmerking: Dit artikel is vakkundig geschreven en bijgedragen door Dan Lorenc, CEO en medeoprichter van Chainguard.
