Tienduizend sterren en één commit

Op 14 juli publiceerde xAI de broncode van Grok Build onder Apache 2.0, en vanochtend stond de repository op ruim tienduizend sterren. De release volgde op een test op netwerkniveau waaruit bleek dat versie 0.2.93 van de tool een getrackte repository uploadde, samen met de volledige git-historie als bundle, naar cloudopslag die xAI beheert. Daar zat ook een repository bij die de assistent juist niet mocht lezen. Wij schreven over die bevinding op 14 juli, en de instructie luidde toen: roteer elk geheim dat de tool ooit heeft gezien. Die instructie staat nog steeds.

De code publiceren oogt als het sterkst denkbare antwoord op zo'n bevinding. Het is de zet die een engineeringorganisatie doet wanneer zij ervan overtuigd is dat het dossier haar vrijpleit, en zo wordt het ook gelezen. De nuttige vraag is dus niet of xAI er goed aan deed om te publiceren. Die vraag is nauwer en praktischer: als u nu naar die repository zou gaan om vast te stellen wat de tool op uw machines heeft gedaan, wat zou u dan feitelijk kunnen aantonen?

Bitter weinig, zo blijkt, en de redenen zijn eerder structureel dan sinister. De repository bevat één commit, op 16 juli om 05:46 UTC aangemaakt door een bot, met als bericht dat hiermee de harness en de TUI open source worden gemaakt. Één commit betekent geen historie. Er is geen ervoor, geen diff, geen opeenvolging van wijzigingen, niets om mee te vergelijken. Tienduizend sterren op een repository zonder historie zijn tienduizend mensen die een gebaar onderschrijven.

Wat de repository u niet kan vertellen

Begin met de ene vraag die de bevinding werkelijk opwierp: waar ging de code naartoe? De uploads gingen naar een Google Cloud Storage-bucket die in de uitgeleverde binary staat genoemd. In de gepubliceerde broncode komt die naam niet voor. Hij wordt gelezen uit een omgevingsvariabele die bij het compileren wordt ingevuld en die bij de build wordt opgelost. Wie de release compileert, levert de bestemming aan, en de broncode zwijgt over waar de uitgeleverde build op gericht was. De gepubliceerde code kan de vraag niet beantwoorden, in geen van beide richtingen.

Kijk vervolgens naar de functie die het uploaden deed. Die staat er nog, in de shell-crate, en doet niets meer. De functie neemt haar parameters aan, markeert ze als ongebruikt, wacht op het kanaal, gooit het resultaat weg en geeft een foutmelding terug die vermeldt dat het uploaden van de sessiestatus niet beschikbaar is. De body is verwijderd terwijl de omgeving is blijven staan: de aanroepen zijn intact, het manifest noemt de dependencies nog steeds, de storage-helpers worden nog altijd meegecompileerd. Wat u kunt lezen, is het skelet van het mechanisme met het mechanisme eruit gehaald.

Dit is bovendien de tweede keer dat de fix is aangebracht op een plek die u niet kunt inspecteren. De oorspronkelijke uploads werden op 13 juli gestopt met een server-side flag, niet met een clientrelease, en dat was het scherpste deel van het eerste verhaal: de binary die uw team beoordeelde en pinde, was nooit het onderdeel dat bepaalde wat de machine verliet. Nu is de code openbaar, en nog steeds is de bestemming een build-time-invoer en zit de schakelaar op de server. De laag die te auditen valt en de laag die beslist, zijn niet dichter bij elkaar gebracht.

Vier bestanden verhuisden, één kwam niet aan

Er is nog één detail, en dat vraagt om een zorgvuldige formulering, want het laat zich makkelijk overinterpreteren. De strings in de uitgeleverde 0.2.93-binary noemen een crate met de naam xai-data-collector, met daarin vijf bronbestanden: de storage client, de laag voor cloudopslag, de queue, een circuit-breaker-observer en een file access tracker. De gepubliceerde repository bevat geen crate met die naam. Dezelfde verzameling bestanden zit in een crate die xai-file-utils heet, en vier van de vijf komen overeen. De vijfde, de file access tracker, zit helemaal niet in de gepubliceerde broncode.

Wat dat wel en niet aantoont, is precies waar het om draait. Het toont geen opzet aan. Een crate hernoemen van een naam die het verzamelen van data beschrijft naar een naam die het verwerken van bestanden beschrijft, is exact wat een team doet tijdens het opruimen rond een release, en een module laten vallen die nergens meer aan gekoppeld is, is doodgewoon onderhoud. Er is hier geen bewijs van verhulling en wij stellen dat ook niet. Het is bovendien de moeite waard om de asymmetrie in het bewijsmateriaal zelf te noemen: de binary-kant steunt op de string-extractie van een derde partij, terwijl de broncode-kant te verifiëren is door iedereen die de repository kloont.

Wat het wél aantoont, is dat de release niet als bewijsstuk kan dienen. De component waarvan de naam het meest rechtstreeks verwijst naar het volgen van de bestandstoegang van een gebruiker, ontbreekt, de verwanten ervan staan er wel onder een andere naam, en er is geen commithistorie waarin een van beide feiten te onderzoeken valt. Onschuldige verklaringen en schuldige verklaringen leveren een identieke repository op. Dat is het probleem met een publicatie als bewijs behandelen: het werkt alleen als het artefact onderscheid kan maken tussen die twee, en dit artefact kan dat niet.

De claim die nooit is gemaakt

Geef de onderzoeker krediet, want de discipline aan die kant van dit verhaal is de reden dat het standhoudt. De analyse op netwerkniveau werd uitgevoerd met een onderscheppende proxy tegen een gepinde binary, op een wegwerprepository die was voorzien van canary-bestanden, en zij is reproduceerbaar: er is een publieke harness, en iedereen kan die draaien. De meting was onthutsend. Een repository van twaalf gigabyte leverde 5,10 gibibyte aan uploadverkeer op tegenover 192 kilobyte aan werkelijke modelconversatie, een verhouding van bijna achtentwintigduizend tegen een. Het canary-bestand dat de assistent niet mocht lezen, kwam ongeschonden uit de vastgelegde bundle tevoorschijn.

En vervolgens schreef de onderzoeker op wat de test niet bewees. Dat uploaden geen trainen is, omdat alleen de verzending is gemeten. Dat één capture bij drie gigabyte niet bewaard is gebleven. Dat een eerdere conclusie onjuist was, omdat een netwerkmeting op procesniveau uploads miste die rechtstreeks naar Google-adressen gingen, en die conclusie is ingetrokken. Een bevinding die haar eigen grenzen en haar eigen rectificatie publiceert, is een bevinding waar u iets aan hebt.

Zet dat naast de reacties. xAI heeft gezegd dat het diep om privacy geeft, dat het de keuze van klanten respecteert en dat voor teams die zero data retention gebruiken, nooit trace- of codedata worden bewaard. Elon Musk zei dat alle gebruikersdata die tot nu toe zijn geüpload, volledig en volstrekt zullen worden verwijderd, en dat er helemaal niets van zal overblijven. Dat kan allemaal waar zijn. Geen van die uitspraken is controleerbaar, en de verwijdering is van buitenaf niet te verifiëren. Het patroon door deze hele episode heen is consistent: de claims die getoetst kunnen worden, kwamen van de persoon met de proxy, en de claims die niet getoetst kunnen worden, kwamen van de leverancier.

Drie vragen voordat u het als opgelost beschouwt

De algemene les heeft niets met xAI te maken, en zij zal binnen de maand opnieuw nodig zijn. Open source maken is een standaardreactie op een beveiligingsbevinding geworden, en het is een goede reactie wanneer het artefact bewijs draagt. Dat is het niet automatisch. Stel dus drie vragen wanneer een leverancier een bevinding over uw data beantwoordt door code te publiceren, voordat u het ticket sluit.

Kan ik de historie inzien? Een squashed eerste commit is een foto, geen dossier. Als de repository begint op de dag van publicatie, kan hij niet laten zien wat er is veranderd, en juist een verandering is het onderwerp van onderzoek. Komt het gepubliceerde artefact overeen met de uitgeleverde binary? Als gedrag dat ertoe doet bij de build wordt vastgelegd of op een server wordt bewaard, dan is de broncode een beschrijving van een mogelijkheid en niet van wat er op uw machines heeft gedraaid. Bevat de code de component die de bevinding noemde? Als het specifieke onderdeel dat is aangetroffen niet in de repository zit, is die afwezigheid geen antwoord, wat de oorzaak ervan ook is.

Niets hiervan pleit ervoor om code gesloten te houden, en niets hiervan is een beschuldiging. Het pleit voor een onderscheid dat uw inkoopproces waarschijnlijk nog niet maakt: publicatie is een daad van openbaarmaking, en een audit is een proces dat een conclusie oplevert. Het een vervangt het ander niet, ze zijn niet eens naaste verwanten, en een leverancier die het eerste heeft gedaan, heeft het tweede niet gedaan. Teams die een link naar een repository als afgesloten zaak behandelen, maken een categoriefout, en dat is het soort fout dat pas achteraf zichtbaar wordt, na de volgende bevinding.

Lees hierna: Geen AI-lab scoorde hoger dan een C+ op veiligheid  |  Prefect koopt de andere orchestrator van je lijst