Det bør ikke finnes noe å høste

I går høstet en kompromittert versjon av Bitwardens CLI SSH-nøkler, AWS-tilgang, npm-tokens, miljøvariabler, shell-historikk og Git-hemmeligheter fra 334 utviklermaskiner.

I dag var det Bitwarden. I fjor var det Axios. Før det, Checkmarx. I morgen blir det en VS Code-utvidelse, eller Acrobat, eller en Homebrew-formel, eller et Docker-image. Vektoren endrer seg fra uke til uke. Resultatet er alltid det samme.

Skadevaren lander. Den leser ~/.ssh/. Den leser ~/.aws/credentials. Den leser ~/.npmrc. Den leser ~/.git-credentials. Den leser shell-historikk, miljøvariabler, nettleserens passordlager. Den pakker alt sammen og sender det til en C2-server.

Og det virker. Hver gang.

Høstingen

Bitwarden-nyttelasten — en 10 MB obfuskert fil kalt bw1.js — forsøkte ikke å knekke noen kryptering. Det trengte den ikke. Her er hva den samlet inn, dokumentert av Socket og Aikido:

• SSH-nøkler og verts-fingeravtrykk
• Skytilgang for AWS, GCP og Azure
• npm-autentiseringstokens
• Git-tilgang og eksterne URL-er
• Miljøvariabler
• Shell-historikk
• Claude Code-autentisering og MCP-konfigurasjoner

Deretter brukte den de stjålne npm-tokensene til å publisere på nytt andre pakker offeret vedlikeholdt, og spredte seg videre. Ofrene ble vektorer.

Ingenting av dette krevde at kryptering ble brutt. Hver eneste av disse hemmelighetene var en fil i filsystemet, lesbar av hvilken som helst prosess som kjører som brukeren.

Dette er ikke en Bitwarden-historie

Bitwardens hvelvkryptering ble ikke brutt. Deres zero-knowledge-arkitektur holdt. Skadevaren rørte aldri hvelvet.

Det trengte den ikke.

Hvelvet beskytter det som er inni det. Men SSH-nøklene var aldri i hvelvet. AWS-tilgangen var aldri i hvelvet. npm-tokens, Git-tilgang, API-nøkler i .env-filer — ingenting av dette bor i passordlagere. Det bor i dotfiles, i klartekst, på hver eneste utviklermaskin.

Angriperen forsto dette. Hvelvet er en låst safe i et hus der hver skuff er åpen.

Det virkelige angrepsflatenet

Åpne en terminal akkurat nå. Se hva som ligger på maskinen din.

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

~/.aws/credentials — skytilgangen din. Fil i klartekst.

~/.npmrc — publiseringstokenet ditt. Fil i klartekst.

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

~/.env i et dusin prosjektmapper — API-nøkler, databasepassord, signaturhemmeligheter. Alt er filer i klartekst.

Enhver prosess som kjører som brukeren din kan lese alt dette. Ingen eskalering av privilegier nødvendig. Ingen exploit påkrevd. Bare cat.

Dette er standardoppsettet for utviklere i 2026. Vi legger passordene i et kryptert hvelv og lar alt annet ligge åpent.

Feil spørsmål

Etter hvert forsyningskjedeangrep stiller bransjen det samme spørsmålet: hvordan hindrer vi skadevare i å komme inn?

Bedre CI/CD-sikkerhet. Kodesignering. Avhengighetsskanning. Sandboxed kjøremiljøer. Alt dette er bra. Ingenting av det er nok. Angrepsflaten er for bred. Det er for mange vektorer — pakkebehandlere, nettleserutvidelser, IDE-plugins, OAuth-apper, kompromitterte byggverktøy. Du kan ikke tette hvert eneste inngangspunkt.

Det riktige spørsmålet er: når skadevare uunngåelig får kjøring på en utviklermaskin, hva finner den?

Hvis svaret er «hundrevis av påloggingsdetaljer i klartekst på forutsigbare steder i filsystemet», spiller det ingen rolle hvor mye du hardner forsyningskjeden. Du forsvarer deg på en bane der målet står åpent bak deg.

Det bør ikke finnes noe å høste

Løsningen er ikke bedre deteksjon av skadevare. Løsningen er ikke å sandboxe npm install. Løsningen er ikke raskere respons på hendelser.

Løsningen er: hemmeligheter skal ikke eksistere som filer på disk.

SSH-nøkler avledet fra maskinvare i det øyeblikket autentiseringen skjer — ikke lagret i ~/.ssh/. Skytilgang utstedt per økt fra en maskinvarebundet identitet — ikke skrevet til ~/.aws/. API-tokens som er avgrensede, kortlivede og maskinvarestyrt — ikke liggende i .env-filer.

Når en legitimasjon bare eksisterer inne i en maskinvaresikkerhetsmodul og i kortlivet prosessminne under bruk, finnes det ikke noe for skadevare å lese. Ingen fil å eksfiltrere. Ingen dotfile å skrape. Prosessen kjører, finner ingenting, og går videre.

Dette er ikke teoretisk. Maskinvarebundet legitimasjon finnes i dag. WebAuthn PRF kan avlede kryptografiske nøkler fra et fysisk autentisator-tap — nøkler som aldri berører filsystemet. Teknologien er her. Bransjen har bare ikke tatt den i bruk som standard.

Hva du gjør nå

Hvis du ble berørt av kompromitteringen av Bitwarden CLI:

• Roter hver legitimasjon på maskinen — SSH-nøkler, skytokens, npm-tokens, API-nøkler, alt i dotfiles og miljøvariabler
• Sjekk om noen npm-pakker du vedlikeholder ble publisert på nytt
• Gå gjennom GitHub-aktivitet og CI/CD-arbeidsflyter for uautoriserte endringer

Hvis du ikke ble berørt, er tiltaket det samme. Se på maskinen din. Tell hemmelighetene i klartekst. Spør deg selv hva som skjer når — ikke hvis — noe ondsinnet kjører som brukeren din.

Svaret bør være: ingenting. Det bør ikke finnes noe å høste.