Er zou niets te oogsten moeten zijn

Gisteren oogste een gecompromitteerde versie van Bitwardens CLI SSH-sleutels, AWS-credentials, npm-tokens, environment variables, shell history en Git-geheimen van 334 ontwikkelaarsmachines.

Vandaag was het Bitwarden. Vorige maand was het Axios. Daarvoor was het Checkmarx. Morgen wordt het een VS Code-extensie, of Acrobat, of een Homebrew-formule, of een Docker-image. De vector verandert wekelijks. De uitkomst is altijd dezelfde.

De malware landt. Hij leest ~/.ssh/. Hij leest ~/.aws/credentials. Hij leest ~/.npmrc. Hij leest ~/.git-credentials. Hij leest shell history, environment variables, wachtwoordopslag van browsers. Hij verpakt alles en stuurt het naar een C2-server.

En het werkt. Elke keer.

De oogst

De Bitwarden-payload — een 10 MB groot geobfuskeerd bestand genaamd bw1.js — probeerde geen enkele versleuteling te kraken. Dat hoefde ook niet. Dit is wat het verzamelde, zoals gedocumenteerd door Socket en Aikido:

• SSH-sleutels en hostvingerafdrukken
• AWS-, GCP- en Azure-cloudcredentials
• npm-authenticatietokens
• Git-credentials en remote URL's
• Environment variables
• Shell history
• Claude Code-authenticatie en MCP-configuraties

Vervolgens gebruikte het de gestolen npm-tokens om andere pakketten opnieuw te publiceren die het slachtoffer onderhield, en verspreidde het zich verder. Slachtoffers werden vectoren.

Dit alles vereiste het kraken van geen enkele versleuteling. Elk van deze geheimen was een bestand op het bestandssysteem, leesbaar door elk proces dat als de gebruiker draait.

Dit is geen Bitwarden-verhaal

De kluisversleuteling van Bitwarden is niet gekraakt. Hun zero-knowledge-architectuur hield stand. De malware raakte de kluis nooit aan.

Dat hoefde ook niet.

De kluis beschermt wat erin zit. Maar SSH-sleutels zaten nooit in de kluis. AWS-credentials zaten nooit in de kluis. npm-tokens, Git-credentials, API-sleutels in .env-bestanden — geen van deze zit in een wachtwoordbeheerder. Ze staan in dotfiles, in platte tekst, op elke ontwikkelaarsmachine.

De aanvaller begreep dit. De kluis is een gesloten kluis in een huis waar elke la openstaat.

Het echte attack surface

Open nu een terminal. Kijk wat er op je machine staat.

~/.ssh/id_ed25519 — je privésleutel. Bestand in platte tekst.

~/.aws/credentials — je cloudtoegang. Bestand in platte tekst.

~/.npmrc — je publicatietoken. Bestand in platte tekst.

~/.git-credentials — je repotoegang. Bestand in platte tekst.

~/.env in een dozijn projectmappen — API-sleutels, databasewachtwoorden, signeergeheimen. Allemaal bestanden in platte tekst.

Elk proces dat als jouw gebruiker draait, kan dit allemaal lezen. Geen privilege-escalatie nodig. Geen exploit nodig. Gewoon cat.

Dit is de standaardontwikkelaarsopzet in 2026. We stoppen onze wachtwoorden in een versleutelde kluis en laten al het andere in de open liggen.

De verkeerde vraag

Na elke supplychainaanval stelt de industrie dezelfde vraag: hoe voorkomen we dat malware binnenkomt?

Betere CI/CD-security. Codesigning. Dependencies scannen. Gesandboxte runtimes. Dit is allemaal goed. Niets daarvan is voldoende. Het attack surface is te breed. Er zijn te veel vectoren — package managers, browserextensies, IDE-plugins, OAuth-apps, gecompromitteerde buildtools. Je kunt niet elk toegangspunt dichten.

De juiste vraag is: wanneer malware onvermijdelijk uitvoering krijgt op de machine van een ontwikkelaar, wat vindt die dan?

Als het antwoord "honderden credentials in platte tekst op voorspelbare locaties in het bestandssysteem" is, dan doet geen enkele hardening van de supply chain ertoe. Je verdedigt op een veld waar het doel wagenwijd open achter je staat.

Er zou niets te oogsten moeten zijn

De oplossing is geen betere malwaredetectie. De oplossing is niet het sandboxen van npm install. De oplossing is niet een snellere incidentresponstijd.

De oplossing is: geheimen mogen niet als bestanden op schijf bestaan.

SSH-sleutels die op het moment van authenticatie uit hardware worden afgeleid — niet opgeslagen in ~/.ssh/. Cloudcredentials die per sessie worden uitgegeven vanuit een hardwaregebonden identiteit — niet weggeschreven naar ~/.aws/. API-tokens die scoped, ephemeer en hardwaregegated zijn — niet in .env-bestanden.

Wanneer een credential alleen bestaat binnen een hardware security module en in ephemeer procesgeheugen tijdens gebruik, is er niets dat malware kan lezen. Geen bestand om te exfiltreren. Geen dotfile om te scrapen. Het proces draait, vindt niets, en gaat verder.

Dit is niet theoretisch. Hardwaregebonden credentials bestaan vandaag. WebAuthn PRF kan cryptografische sleutels afleiden uit een tik op een fysieke authenticator — sleutels die het bestandssysteem nooit raken. De technologie is er. De industrie heeft hem alleen niet als standaard overgenomen.

Wat je nu moet doen

Als je bent geraakt door de Bitwarden CLI-compromitteering:

• Roteer elke credential op de machine — SSH-sleutels, cloudtokens, npm-tokens, API-sleutels, alles in dotfiles en env vars
• Controleer of er npm-pakketten die je onderhoudt opnieuw zijn gepubliceerd
• Controleer GitHub-activiteit en CI/CD-workflows op ongeautoriseerde wijzigingen

Als je niet bent geraakt, is de actie hetzelfde. Kijk naar je machine. Tel de geheimen in platte tekst. Vraag jezelf af wat er gebeurt wanneer — niet als — er iets kwaadaardigs als jouw gebruiker draait.

Het antwoord zou moeten zijn: niets. Er zou niets te oogsten moeten zijn.