Der burde ikke være noget at høste

I går høstede en kompromitteret version af Bitwardens CLI SSH-nøgler, AWS-legitimationsoplysninger, npm-tokens, miljøvariabler, shell-historik og Git-hemmeligheder fra 334 udviklermaskiner.

I dag var det Bitwarden. I sidste måned var det Axios. Før det Checkmarx. I morgen bliver det en VS Code-udvidelse, eller Acrobat, eller en Homebrew-formel, eller et Docker-image. Vektoren ændrer sig hver uge. Resultatet er altid det samme.

Malwaren lander. Den læser ~/.ssh/. Den læser ~/.aws/credentials. Den læser ~/.npmrc. Den læser ~/.git-credentials. Den læser shell-historik, miljøvariabler, browserens password-lagre. Den pakker det hele sammen og sender det til en C2-server.

Og det virker. Hver gang.

Høsten

Bitwarden-payloaden — en 10 MB obfuscateret fil kaldet bw1.js — forsøgte ikke at bryde nogen kryptering. Det var der ikke brug for. Her er, hvad den indsamlede, som dokumenteret af Socket og Aikido:

• SSH-nøgler og værts-fingerprints
• AWS-, GCP- og Azure-cloud-legitimationsoplysninger
• npm-godkendelsestokens
• Git-legitimationsoplysninger og remote-URL'er
• Miljøvariabler
• Shell-historik
• Claude Code-godkendelse og MCP-konfigurationer

Derefter brugte den de stjålne npm-tokens til at genudgive andre pakker, som ofret vedligeholdt, og spredte sig selv yderligere. Ofre blev til vektorer.

Intet af dette krævede, at kryptering blev brudt. Hver eneste af disse hemmeligheder var en fil på filsystemet, læsbar af enhver proces der kører som brugeren.

Dette er ikke en Bitwarden-historie

Bitwardens vault-kryptering blev ikke brudt. Deres zero-knowledge-arkitektur holdt. Malwaren rørte aldrig vaulten.

Det var der heller ikke brug for.

Vaulten beskytter det, der er indeni den. Men SSH-nøgler var aldrig i vaulten. AWS-legitimationsoplysninger var aldrig i vaulten. npm-tokens, Git-legitimationsoplysninger, API-nøgler i .env-filer — intet af dette ligger i password managers. Det ligger i dotfiles, i klartekst, på hver eneste udviklermaskine.

Angriberen forstod dette. Vaulten er en aflåst boks i et hus, hvor hver eneste skuffe står åben.

Det egentlige angrebsfelt

Åbn en terminal lige nu. Se, hvad der ligger på din maskine.

~/.ssh/id_ed25519 — din private nøgle. Fil i klartekst.

~/.aws/credentials — din cloud-adgang. Fil i klartekst.

~/.npmrc — dit publish-token. Fil i klartekst.

~/.git-credentials — din repo-adgang. Fil i klartekst.

~/.env i et dusin projektmapper — API-nøgler, databaseadgangskoder, signeringshemmeligheder. Alle sammen filer i klartekst.

Enhver proces der kører som din bruger, kan læse alt dette. Ingen privilege escalation nødvendig. Ingen exploit påkrævet. Bare cat.

Det er standardopsætningen for udviklere i 2026. Vi lægger vores adgangskoder i en krypteret boks og lader alt andet ligge frit fremme.

Det forkerte spørgsmål

Efter hvert supply chain-angreb stiller branchen det samme spørgsmål: hvordan forhindrer vi malware i at komme ind?

Bedre CI/CD-sikkerhed. Kodesignering. Dependency-scanning. Sandboxede runtime-miljøer. Det er alt sammen godt. Men intet af det er tilstrækkeligt. Angrebsfeltet er for bredt. Der er for mange vektorer — pakkehåndteringsværktøjer, browserudvidelser, IDE-plugins, OAuth-apps, kompromitterede build-værktøjer. Du kan ikke forsegle hvert eneste indgangspunkt.

Det rigtige spørgsmål er: når malware uundgåeligt får eksekvering på en udviklers maskine, hvad finder den?

Hvis svaret er "hundredevis af legitimationsoplysninger i klartekst på forudsigelige placeringer i filsystemet", så hjælper ingen mængde supply chain-hardening. Du forsvarer dig på en bane, hvor målet står helt åbent bag dig.

Der burde ikke være noget at høste

Løsningen er ikke bedre malware-detektion. Løsningen er ikke at sandboxe npm install. Løsningen er ikke en hurtigere incident response-tid.

Løsningen er: hemmeligheder skal ikke eksistere som filer på disken.

SSH-nøgler udledt fra hardware på tidspunktet for godkendelsen — ikke gemt i ~/.ssh/. Cloud-legitimationsoplysninger udstedt pr. session fra en hardwarebundet identitet — ikke skrevet til ~/.aws/. API-tokens med begrænset scope, ephemeral og hardware-gated — ikke liggende i .env-filer.

Når en legitimationsoplysning kun eksisterer inde i en hardware security module og i ephemeral proceshukommelse under brug, er der intet for malware at læse. Ingen fil at exfiltrere. Ingen dotfile at skrabe. Processen kører, finder ingenting og går videre.

Det her er ikke teoretisk. Hardwarebundne legitimationsoplysninger findes allerede i dag. WebAuthn PRF kan udlede kryptografiske nøgler fra et fysisk authenticator-tap — nøgler der aldrig rører filsystemet. Teknologien er her. Branchen har bare ikke indført den som standard.

Hvad du gør nu

Hvis du blev berørt af kompromitteringen af Bitwarden CLI:

• Rotér alle legitimationsoplysninger på maskinen — SSH-nøgler, cloud-tokens, npm-tokens, API-nøgler, alt i dotfiles og miljøvariabler
• Tjek om nogen af de npm-pakker, du vedligeholder, er blevet genudgivet
• Gennemgå GitHub-aktivitet og CI/CD-workflows for uautoriserede ændringer

Hvis du ikke blev berørt, er handlingen den samme. Se på din maskine. Tæl hemmelighederne i klartekst. Spørg dig selv, hvad der sker, når — ikke hvis — noget ondsindet kører som din bruger.

Svaret burde være: ingenting. Der burde ikke være noget at høste.