Perplexity har lagt kildekoden til Bumblebee ud på GitHub: et read-only scanner-værktøj, der kortlægger pakker, editor- og browserudvidelser og AI-værktøjers konfigurationer på macOS og Linux. Tørt på papiret, nyttigt i praksis. De seneste uger har budt på angreb i både npm og Visual Studio Code-økosystemet, og her er et værktøj, der kan bruges nu, ikke i næste kvartal. VentureBeat beskriver, at 633 ondsindede npm-versioner den 19. maj gled gennem Sigstore-kontrollen med gyldige certifikater fra stjålne maintainer-konti. Dagen før slap en kompromitteret Nx Console-udvidelse ud i under 40 minutter og nåede cirka 6.000 aktiveringer. Det er virkeligheden.\n
Synlighed på udviklermaskinen har længe været et blindt punkt. SBOM’er og EDR dækker andre vinkler, men ikke nødvendigvis lockfiles, udvidelses-manifester og AI-agenters lokale config. MarkTechPost gennemgår, hvordan Bumblebee er målrettet netop det hul. Vi har selv siddet med kunder, hvor alt pegede mod et ubeskrevet “noget” på en laptop — og først da lokale lockfiles kom på bordet, faldt brikkerne. Det er sjældent elegant, men ofte dér nøglerne ligger.\n
Hvad værktøjet er\n
Bumblebee er en read-only inventarindsamler til udvikler-endpoints på macOS og Linux, ifølge MarkTechPost. Koden er skrevet i Go. Perplexity oplyser, at der ikke er afhængigheder ud over standardbiblioteket; det har vi ikke uafhængigt verificeret endnu. Outputtet er NDJSON (én post pr. linje), og diagnostik går til stderr. Pointen er enkel: kør en scanning, skriv et maskinlæsbart resultat, og stop igen.\n
Der er tre scan-profiler. Baseline går efter almindelige globale og bruger-specifikke pakkerødder, sprogtoolchains, editor- og browserudvidelser samt AI-konfigurationer. Project retter sig mod udviklermapper som f.eks. ~\/code eller ~\/src. Deep fejer operator-definerede rødder — typisk en hel hjemmemappe — når det brænder på. One-shot-arkitekturen betyder, at frekvensen styres af jer selv via cron, launchd, systemd eller MDM.\n
Hvorfor det rammer rigtigt nu\n
Angrebene ligger tættere på udvikleren. MarkTechPost peger direkte på pakker, editor-udvidelser og AI-konfigurationer på udviklermaskiner som mål. VentureBeat beskriver, hvordan Nx Console version 18.95.0 blev udgivet med stjålne legitimationsoplysninger og nåede brugere, selv om den kun var live i under 40 minutter. De dokumenterer også Sigstore-hændelsen 19. maj, hvor 633 ondsindede npm-pakker passerede proveniensvalidering, fordi angriberen havde gyldige certifikater via kompromitterede konti.\n
Sigstore gjorde, hvad det skulle: verificerede, at pakken var bygget i et CI-miljø og loggede. Problemet var identiteten bag nøglen, ikke kryptografien. Her giver lokalt inventar mening. Når en advisory lander med navn og version, skal man hurtigt kunne se, hvilke laptops der har spor i lockfiles eller manifestfiler. Ikke i morgen — nu.\n
Hvordan det virker i praksis\n
Bumblebee kører som en engangsproces: et binærkald med en profil og en output-sti. Planlægning sker via cron, launchd, systemd eller MDM. På macOS kan en launchd-agent med jitter dæmpe “thundering herd”, mens MDM styrer udrulning og parametre. På Linux giver systemd-timers med randomization mening under hændelser, så scanninger ikke kolliderer med builds.\n
Output er NDJSON, som kan landes lokalt og skubbes til en central logklynge. Det mest stabile i praksis er at lade klienten skrive til en lokal fil og lade en eksisterende log-forwarder sende videre. Operatørarbejdsgangen er at matche et katalog mod fund og fremhæve maskiner, hvor der er hit på navn og version i on-disk metadata. Og en vigtig note: vi ser markant færre false positives, når findings enriches med CI-udgivelseslogs og EDR-procesdata, før der træffes blokeringer.\n
Hvad det dækker som andre ikke ser\n
SBOM’er og klassiske sårbarhedsscannere ser typisk artefakter og repositories — ikke udviklerens aktuelle lokale tilstand. EDR ser processer og netværk, men ikke nødvendigvis, at en VS Code-udvidelse trak en sårbar dependency for tre dage siden og låste den i en lockfile. Bumblebee læser lokale lockfiles, installeret pakke-metadata, udvidelses-manifester og AI-agenters config-filer. Det er præcis det felt, som de seneste kampagner udnyttede.\n
Perplexity har valgt økosystemer med høj aktivitet: npm, PyPI, RubyGems, Go-moduler og Composer. MarkTechPost kobler valget til Mini Shai-Hulud-serien, der ramte bl.a. TanStack, SAP og Zapier. Det matcher vores egne observationer i år: mange spor starter ikke i build-systemet, men i udviklerens lokale miljø — fordi det er lettere at ramme.\n
Hvad der bliver scannet\n
Bumblebee kigger i sprog-økosystemers lock- og metadatafiler: f.eks. package-lock.json, pnpm-lock.yaml, go.sum og *.dist-info\/METADATA. En detalje her: bun.lockb, Bun’s binære lockfile, er ikke understøttet i v0.1 ifølge MarkTechPost — kun tekstformatet bun.lock. Det er væsentligt, hvis I er tungt på Bun.\n
For AI-agenter læses MCP JSON-konfigurationer som mcp.json, .mcp.json, claude_desktop_config.json, mcp_config.json, mcp_settings.json, cline_mcp_settings.json og ~\/.gemini\/settings.json for Gemini CLI. Ikke-JSON MCP-konfigurationer som Codex config.toml og Continue YAML bliver ikke parset i v0.1. Værktøjet opregner servere, men emitterer ikke miljøværdier eller navne på miljøvariabler fra env-blokke. For editor-udvidelser dækkes VS Code, Cursor, Windsurf og VSCodium. For browser-udvidelser dækkes Chrome-familien, Comet, Edge, Brave og Arc, plus Firefox.\n
Integration i hverdagen\n
I drift giver one-shot-tilgangen lavt CPU-aftryk og ingen langlivede processer. Til gengæld kræver det orkestrering. Vores forslag i rolige perioder: baseline dagligt, project to gange ugentligt, deep kun under hændelser. Under en aktiv hændelse kan baseline køre hver time de første 12 timer og derefter nedtrappes til hver 3. time, så transient installationer ikke smutter igennem.\n
MDM-integration er ligetil: skub binæren ud, læg en konfiguration med profil og output-sti, og opret en politik, der roterer logs. NDJSON passer godt til SIEM og OpenSearch\/ELK. Vi anbefaler et separat index med 14–30 dages retention for hurtig søgning og en månedlig eksport til billigere lager, hvis compliance kræver det. Husk anonymisering: hjemmemappestier kan hashes, og projektnavne kan mappes til interne ID’er, før data forlader maskinen.\n
Hvilket hul der lukkes\n
Det store hul handler om at kunne svare: “Hvilke maskiner har netop nu spor af pakke X i version Y?” SBOM’er svarer på, hvad I byggede. EDR svarer på, hvad der kørte. Bumblebee svarer på, hvad der ligger på disken i udviklermiljøet. Når en advisory navngiver en extension eller version, kan I straks finde de bærbare, der har et manifest-match.\n
Vi havde en sag hos en finsk fintech-kunde, hvor en sårbar sub-dependency kun stod i en ældre lockfile i en sidelomme af repoet. CI havde aldrig bygget den vej. Den lokale inventarliste gjorde forskellen. Ikke mirakuløst — bare et hurtigt datasæt, der pegede os i den rigtige retning. En halv time senere var vi videre i playbooken.\n
Begrænsninger og faldgruber\n
Read-only betyder ingen automatisk udbedring. Det er godt, fordi scanninger ikke kører postinstall-scripts eller forværrer situationen — og skidt, fordi remediation stadig skal ske via pakke-gates, PR’er og evt. rollback i editor- og browserudvidelser. Transiente tilstande er en anden udfordring: en kortlivet installation kan forsvinde, før næste scanning. Derfor er cadence afgørende under hændelser.\n
Privatliv er heller ikke trivielt. Lockfiles og manifestfiler kan røbe projektnavne og filstier. Beslut, hvilke felter der sløres eller hashes, før noget forlader maskinen. Og husk: tillid til on-disk metadata er ikke absolut. Manipulerede lockfiles kan snyde en simpel parser. Krydstjek fund mod CI-udgivelser, registry-logs og EDR-hændelser, før I trykker på den store røde knap.\n
Governance og proces\n
MarkTechPost beskriver, at Perplexity bruger et fem-trins flow: trussels-signal, system klargør et katalog-opslag med kildehenvisninger, menneskelig review, merge, scanning på endpoints og deling af fund med sikkerhed. Det er fornuftigt. Et katalog som PR’er giver disciplin og færre panik-fejlskud.\n
Vores praktiske justering: et fast review-vindue på 15 minutter med en sekundær reviewer i overlappende tidszone. Og et simpelt kvalitetskrav i PR’en: link til advisory, match-kriterier (navn, version, filsti-typer) og et eksempel på et forventet NDJSON-hit. Det hjælper dem, der sidder på vagten klokken 03.\n
Konkrete scenarier\n
MDM + SIEM: rul baseline dagligt, send NDJSON til et særskilt index, og byg dashboards for “nye matches siden i går” og “maskiner med flest risikofyldte matches”. Incident-response: ved en advisory på en VS Code-udvidelse, push en midlertidig deep-scanning i 24 timer, triagér resultater med et simpelt scorekort (nylighed, eksponeret token, sårbar version), og kontakt berørte teams med en færdig patch-vejledning.\n
False positives: kombiner fund fra Bumblebee med EDR-telemetri og CI-udgivelseslogs, før der lukkes ned. Vi har set i lab, at midlertidige lockfile-stater skaber støj. Et lille korrelationslag fjerner det meste. Datahåndtering: anonymisér brugerstier, og whitelist kun paths, I faktisk behøver, så compliance kan følge med. Dokumentér datakilderne i jeres ROPA, hvis I er under GDPR-krav.\n
Hårde kanter og mangler\n
Bumblebee kører på macOS og Linux. Ingen Windows endnu. For mange enterprise-miljøer er det en stopper — eller i hvert fald en pause. Det bør stå højt på ønskelisten. Vi har spurgt til WSL-støtte som minimum, men der er ingen udmelding i de dækninger, vi har set. Også noteret: Perplexitys påstand om nul non-stdlib afhængigheder stammer fra MarkTechPost; vi har ikke set uafhængig verifikation.\n
Vi savner også mere detaljeret standard-konfiguration: præcise paths, default excludes og retningslinjer for privatlivsfølsomme filer. Det kommer nok i repoet over tid. Og så det evige tradeoff: one-shot scanning kan misse kortlivede kompromitteringer. En always-on agent ser mere, men koster friktion. De fleste vil fornuftigt starte med one-shot.\n
Hvorfor det betyder noget for arbejdet i morgen\n
Det her er ikke en tung agent med måneders udrulning. Det er en binær, et par planlægningsjobs og en log-pipeline. Det kan implementeres hurtigt. Ja, det kræver koordinering mellem platform, sikkerhed og udvikling — men værktøjet respekterer udviklermaskinen: read-only ind, og ud igen. Det sænker barrieren.\n
Teams med mange editor-udvidelser og frontend-pakker får størst gevinst først. Det samme gælder AI\/ML-hold med lokale model- og config-filer. CI\/CD-tunge shops kan koble katalog-opdateringer direkte til pipelines, så scanninger udløses ved nye advisories. Så begynder det at ligne et sammenhængende forsvar.\n
Hvad leverandører og økosystemer må tage med\n
Efter Sigstore-eksemplet er beskeden klar: stjålne credentials er stadig kongevejen for angribere. Marketplaces og maintainere bør stramme udgivelseskæden — ikke kun kryptering og logning. Skarpere beskedflows ved mistænkelig publikationsadfærd, step-up auth ved sjældne handlinger og bedre varsling til brugere, der automatisk opdaterer udvidelser.\n
Editor-markedet bør overveje indbyggede inventory-API’er og hurtige rollback-mekanismer, så virksomhedsadmins kan styre udvidelser centralt uden at ødelægge udviklernes workflow. En smule friktion er acceptabel. 40 minutter kan være nok til at suge tokens ud, som VentureBeat beskrev for Nx Console-angrebet.\n
Vores vurdering efter at have prøvet lignende tilgange\n
Vi testede en beslægtet read-only tilgang i vores lab for et par måneder siden. Én ting var fremragende: time-to-evidence faldt markant. Én ting var dårligere: støj fra midlertidige lockfiles. Derfor anbefaler vi et let korrelationslag, før nogen blokerer builds eller frakobler en udvikler. Det er hurtigt at bygge og løfter kvaliteten.\n
Vi har også set i en kundesag — en finsk fintech — at 20 minutters målrettet deep-scanning af hjemmemapper, koblet med et fornuftigt katalog, leverede svaret, alle ledte efter. Ikke poleret, men effektivt. Og ja, der var mere rod i ~\/src, end nogen havde forestillet sig.\n
Hvad der mangler svar på\n
Der er åbne spørgsmål: Hvordan håndterer værktøjet privatlivsfølsomme filer i praksis, ud over at undlade at emitte env-navne? Hvilke standard paths skannes, og hvordan overstyres de i enterprise-opsætninger? Hvad er planen for Windows og evt. WSL? Og kan Perplexity eller en tidlig bruger dele tal for adoption og falsk-positiv-rate i et større miljø?\n
Vi vil også gerne se en uafhængig kodegennemgang, der bekræfter Go-implementeringen uden eksterne afhængigheder. Ikke fordi vi tvivler, men fordi tillid i supply-chain kræver verificerbare påstande — for alle parter.\n
Hvad ledere og udviklere bør gøre nu\n
Har I macOS eller Linux på udviklersiden, så planlæg et lille forsøg: to-tre hold, baseline dagligt, project to gange om ugen. Få NDJSON ind i jeres SIEM, og byg ét dashboard, der kan svare på det simple spørgsmål om navn og version. Sæt samtidig et mini-reviewflow op for katalog-PR’er, så I ikke improviserer under pres.\n
Har I mange Windows-klienter, så afklar omfanget og vær ærlige om hullet. I kan stadig afdække CI\/CD og servere, men vær bevidste om blindvinklen på endpoints. Og til sidst: dokumentér databehandlingen, anonymisér stier, og aftal retention. Forskellen mærkes først, når I står midt i en hændelse — og så er tiden allerede gået.
