Det borde inte finnas något att skörda

Igår skördade en komprometterad version av Bitwardens CLI SSH-nycklar, AWS-uppgifter, npm-token, miljövariabler, shell-historik och Git-hemligheter från 334 utvecklarmaskiner.

Idag var det Bitwarden. Förra månaden var det Axios. Innan dess Checkmarx. Imorgon blir det ett VS Code-tillägg, eller Acrobat, eller ett Homebrew-formelpaket, eller en Docker-image. Vektorn ändras varje vecka. Utfallet är alltid detsamma.

Skadeprogrammet landar. Det läser ~/.ssh/. Det läser ~/.aws/credentials. Det läser ~/.npmrc. Det läser ~/.git-credentials. Det läser shell-historik, miljövariabler, webbläsarens lösenordslager. Det packar ihop allt och skickar till en C2-server.

Och det fungerar. Varje gång.

Skörden

Bitwarden-nyttolasten — en maskerad fil på 10 MB som hette bw1.js — försökte inte knäcka någon kryptering. Det behövdes inte. Här är vad den samlade in, enligt Socket och Aikido:

• SSH-nycklar och fingeravtryck för värdmaskiner
• AWS-, GCP- och Azure-molnuppgifter
• npm-autentiseringstoken
• Git-uppgifter och fjärr-URL:er
• Miljövariabler
• Shell-historik
• Claude Code-autentisering och MCP-konfigurationer

Därefter använde den de stulna npm-tokenen för att återpublicera andra paket som offret underhöll, och spred sig vidare. Offer blev vektorer.

Inget av detta krävde att någon kryptering knäcktes. Var och en av dessa hemligheter var en fil på filsystemet, läsbar av vilken process som helst som kördes som användaren.

Det här är inte en Bitwarden-historia

Bitwardens valvkryptering bröts inte. Deras zero-knowledge-arkitektur höll. Skadeprogrammet rörde aldrig valvet.

Det behövde den inte.

Valvet skyddar det som finns i det. Men SSH-nycklar fanns aldrig i valvet. AWS-uppgifter fanns aldrig i valvet. npm-token, Git-uppgifter, API-nycklar i .env-filer — inget av detta lever i lösenordshanterare. Det lever i dotfiles, i klartext, på varje utvecklarmaskin.

Angriparen förstod detta. Valvet är ett låst kassaskåp i ett hus där varje låda är öppen.

Den verkliga attackytan

Öppna en terminal just nu. Titta på vad du har på din maskin.

~/.ssh/id_ed25519 — din privata nyckel. Klartextfil.

~/.aws/credentials — din molnåtkomst. Klartextfil.

~/.npmrc — ditt publiceringstoken. Klartextfil.

~/.git-credentials — din repo-åtkomst. Klartextfil.

~/.env i ett dussin projektkataloger — API-nycklar, databaslösenord, signeringshemligheter. Allt klartextfiler.

Vilken process som helst som kör som din användare kan läsa allt detta. Ingen privilegiehöjning behövs. Inget sårbarhetsutnyttjande krävs. Bara cat.

Det här är standarduppsättningen för utvecklare 2026. Vi lägger våra lösenord i ett krypterat valv och lämnar allt annat öppet.

Den felaktiga frågan

Efter varje supply chain-attack ställer branschen samma fråga: hur förhindrar vi att skadeprogram tar sig in?

Bättre CI/CD-säkerhet. Kodsignering. Beroendescanning. Körningsmiljöer i sandlåda. Allt detta är bra. Inget av det räcker. Attackytan är för bred. Det finns för många vektorer — pakethanterare, webbläsartillägg, IDE-plugins, OAuth-appar, komprometterade byggverktyg. Du kan inte täppa till varje inträdespunkt.

Den rätta frågan är: när skadeprogram oundvikligen får exekvering på en utvecklarmaskin, vad hittar det?

Om svaret är "hundratals klartextuppgifter på förutsägbara platser i filsystemet" spelar det ingen roll hur mycket man härdar supply chain. Du spelar försvar på en plan där målet står helt öppet bakom dig.

Det borde inte finnas något att skörda

Lösningen är inte bättre detektering av skadeprogram. Lösningen är inte att köra npm install i sandlåda. Lösningen är inte en snabbare incidentrespons.

Lösningen är: hemligheter ska inte existera som filer på disk.

SSH-nycklar härledda från hårdvara i autentiseringsögonblicket — inte lagrade i ~/.ssh/. Molnuppgifter som utfärdas per session från en hårdvarubunden identitet — inte skrivna till ~/.aws/. API-token med begränsad räckvidd, tillfälliga och hårdvarustyrda — inte liggande i .env-filer.

När en uppgift bara finns i en hårdvarusäkerhetsmodul och i tillfälligt processminne under användning finns det inget för skadeprogram att läsa. Ingen fil att exfiltrera. Ingen dotfile att skrapa. Processen kör, hittar inget, går vidare.

Det här är inte teoretiskt. Hårdvarubundna uppgifter finns idag. WebAuthn PRF kan härleda kryptografiska nycklar från en fysisk tryckning på autentiseraren — nycklar som aldrig kommer i kontakt med filsystemet. Tekniken finns här. Branschen har bara inte antagit den som standard.

Vad du gör nu

Om du påverkades av Bitwarden CLI-kompromissen:

• Rotera varje uppgift på maskinen — SSH-nycklar, molntoken, npm-token, API-nycklar, allt i dotfiles och miljövariabler
• Kontrollera om några npm-paket som du underhåller har återpublicerats
• Granska GitHub-aktivitet och CI/CD-workflöar för obehöriga ändringar

Om du inte påverkades är åtgärden densamma. Titta på din maskin. Räkna klartexthemligheterna. Fråga dig vad som händer när — inte om — något skadligt körs som din användare.

Svaret bör vara: inget. Det borde inte finnas något att skörda.