De malware was ondertekend door Red Hat
Deze week bereikte code die inloggegevens steelt ontwikkelaars, verpakt onder de naam van Red Hat. De dreiging kwam niet van buiten jouw vertrouwenscirkel — maar van binnenuit. Daar kun je je niet uit screenen. Je kunt je inloggegevens wél uit de buurt houden.
Deze week probeerde door Red Hat ondertekende code jouw inloggegevens te stelen.
Aanvallers kwamen binnen op het account van een Red Hat-ontwikkelaar en publiceerden gemanipuleerde versies van officiële Red Hat-pakketten. Zodra een machine er één installeerde, draaide verborgen code automatisch en greep naar alles waardevols dat ze kon vinden — cloudkeys, tokens, logins, alles wat een deur opent. Vervolgens gebruikte ze wat ze buitmaakte om zich verder te verspreiden.
Let op de vorm hiervan. Red Hat was niet het doelwit — jij was dat. Hun naam, hun vertrouwde account, de installatiepipeline die je al duizend keer gedachteloos hebt gebruikt: dat was niet de schade. Dat was het wapen. De aanval sloop niet voorbij je vertrouwenscirkel. Die liep gewoon de voordeur binnen met een pasje dat je zelf had uitgegeven. Dat is wat supply-chain-aanvallen anders maakt dan al de rest — het gevaar is geen vreemdeling die je kunt blokkeren, het is de leverancier die je al had besloten te vertrouwen, die de payload voor je aflevert. En dit was Red Hat: een van de meest security-volwassen bedrijven die er bestaan, met echte review en een echt budget. De slechte code ging alsnog onder hun naam de deur uit.
Dus hier is de conclusie die je niet kunt ontwijken: als Red Hat niet kan garanderen dat wat je van hen installeert schoon is, dan kan niemand dat. Niet je framework, niet je CI-leverancier, niet die dependency drie niveaus dieper die je nooit hebt gelezen. Je draait uiteindelijk code die je niet hebt geschreven en niet volledig hebt kunnen controleren. Dat is geen procesfout — dat is nou eenmaal wat het betekent om te bouwen op software van anderen.
Blijf scannen. Blijf versies vastpinnen. Blijf controleren. Het is het allemaal waard — maar ga er niet vanafhangen, want deze week had het niks geholpen: de malware arriveerde al voorvertrouwd. De echte vraag is niet hoe je de slechte code buiten houdt. De vraag is deze: als slechte code op je machine draait, heb je je geheimen beschermd?
Bijna iedereen moet eerlijk "nee" antwoorden. Kijk wat deze aanval meenam — environment variables, tokens die in bestanden stonden, en daarna liep de code naar de cloud secret managers en vroeg ze hun inhoud af te staan. Zo leven inloggegevens in 2026: op één hoop, binnen handbereik van wat er toevallig draait. Eén verkeerde installatie pakt niet één geheim. Die pakt ze allemaal, en verspreidt zich daarna.
De oplossing is om je inloggegevens niet meer te bewaren waar je code ze kan grijpen. Houd ze op armlengte.
Dat is het hele idee achter hoe Clavitor werkt. Je geheimen leven niet in je omgeving; er ligt niks in een .env-bestand te wachten om gelezen te worden. Een programma — of een AI-agent — houdt nooit de inloggegevens vast. Het krijgt de mogelijkheid om er een te gebruiken, vers opgehaald op het moment dat die nodig is — nooit opgeslagen, nooit gecached — vanuit een van onze 21 locaties op zes continenten, zodat de dichtstbijzijnde kopie altijd milliseconden weg is, begrensd tot het ene geheim waarvoor het rechten kreeg, met elke toegang gelogd. Als een kwaadaardig installatiescript rondtast naar sleutels, treft het een lege kamer.
En we gaan ervan uit dat een inloggegeven uiteindelijk toch wordt buitgemaakt, dus wat een agent meedraagt is gestolen nauwelijks nog iets waard. Het werkt alleen vanaf de machine waarvoor het is uitgegeven — neem het mee en gebruik het vanaf de servers van de aanvaller zelf, en het wordt geweigerd. Het is begrensd en bewaakt: een paar geheimen per minuut, zodat het je kluis niet kan leegzuigen, en zodra het voorbij zijn gebruikelijke handvol gaat, springt er een alarm af en gaat het op slot. De hele strategie van een worm — snel alles grijpen, overal gebruiken — loopt tegen een muur.
Geen belofte van immuniteit: als een inloggegeven op hetzelfde moment actief in gebruik is als waarop de malware draait, kan die ene worden onderschept — geen architectuur herschrijft de natuurkunde. Maar dat is precies het punt. De Red Hat-aanval was zo verwoestend omdat één installatie een hele secret store kon leegtrekken en als wapen kon inzetten. Armlengte, plus een inloggegeven die aan één machine is vastgeprikt en tot een straaltje is begrensd, verandert "ze namen alles en verspreidden zich" in "ze hebben misschien één sleutel onderweg onderschept, en die werkte nergens anders." Dat is het verschil tussen een catastrofe en een voetnoot.
De malware was ondertekend door Red Hat. Daar kun je je niet uit screenen. Ga ervan uit dat de code binnenkomt — en zorg dat, als dat gebeurt, je geheimen niet zitten te wachten.
(Publiek bijgehouden als "Miasma", een variant van de Shai-Hulud-familie van zichzelf verspreidende npm-worms. De technische write-ups zijn je tijd waard; deze post gaat over het onderdeel dat van de ene op de andere keer niet verandert.)
Bronnen: