Gå til indhold
← Tilbage til bloggen
sikkerhedforsyningskædehomebrewvirksomhed

Homebrew-Sikkerhed i Virksomheden: Sikring af macOS-Udviklerens Forsyningskæde

Uadministrerede brew-installationer er usynlige for IT: intet revisionsspor, ingen CVE-tjek, ingen politik. Her er, hvordan den eksponering ser ud i praksis — og hvordan du lukker den uden at bremse udviklerne.

EnterpriseBrew Team··8 min læsning

I 2024 sendte bagdøren i XZ Utils (CVE-2024-3094) chokbølger gennem open source-økosystemet. En ondsindet aktør brugte to år på at opbygge tillid som vedligeholder og injicerede derefter en omhyggeligt obfuskeret bagdør i et bredt distribueret komprimeringsbibliotek. Hændelsen afslørede en grundlæggende sandhed: softwareforsyningskæden er kun så sikker som dens svageste, mindst overvågede led.

For virksomhedens IT- og sikkerhedsteams, der administrerer macOS-flåder, repræsenterer Homebrew præcis den slags uovervåget led. Udviklere installerer hundredvis af pakker — compilere, kørselstider, CLI-værktøjer, databaseklienter — og de fleste organisationer har ingen synlighed over, hvad der er installeret, hvornår, eller om nogen af disse pakker har kendte sårbarheder.

Denne guide undersøger den angrebsflade, som uhåndteret Homebrew skaber, og beskriver arkitektoniske mønstre til at eliminere den.

Homebrews Skjulte Risikoflade i Virksomheden

Homebrews bekvemmelighed er også dets sikkerhedsansvar. Det er designet til at installere direkte fra internettet til en udviklers maskine uden noget mellemliggende verifikationstrin, som en virksomhed kan kontrollere. Overvej hvad det betyder i praksis:

Ingen organisatorisk bevidsthed om installerede pakker. En udvikler, der kører brew install ffmpeg, henter en binær fil fra Homebrews CDN. IT-sikkerhedsteamet har ingen registrering af denne installation, ingen mulighed for at kontrollere den mod en softwarefortegnelse og ingen mekanisme til at modtage en advarsel, hvis den pågældende pakke efterfølgende viser sig at være kompromitteret.

CVE-eksponering uden afhjælpningstrigger. Homebrew-pakker er typisk ikke inkluderet i virksomhedens arbejdsgange for sårbarhedshåndtering. Værktøjer som Qualys, Tenable eller Microsoft Defender for Endpoint kan scanne for sårbarheder på systemniveau, men overser i vid udstrækning brugerinstallerede Homebrew-pakker. Når et kritisk CVE offentliggøres for openssl, curl eller libssh2, er der ingen automatiseret vej fra "CVE offentliggjort" til "berørt udvikler underrettet og pakke opdateret".

Inkonsistente miljøer på tværs af flåden. Forskellige udviklere installerer forskellige versioner af de samme værktøjer. node@18 på én maskine, node@20 på en anden. Dette skaber reproducerbarhedsproblemer for builds og komplicerer sikkerhedspatching — man kan ikke patche det, man ikke kan inventere.

Ingen politikhåndhævelse. Nogle pakker er upassende i et reguleret miljø. En udvikler kan installere et fjernadgangsværktøj, en pakke-sniffer eller et hjælpeprogram, der gemmer legitimationsoplysninger i klartekst. Uden et politiklag er der ingen mekanisme til at forhindre eller endog opdage dette.

Hvad "Sikring af Homebrew" Faktisk Kræver

Organisationer reagerer typisk på disse risici på én af to måder, begge utilstrækkelige:

At blokere Homebrew helt er en almindelig, men kontraproduktiv reaktion. Udviklere har brug for disse værktøjer. Blokering af Homebrew skubber installationer over i skygge-metoder — manuel tarball-ekstraktion, pip install --user, Nix eller brugerdefinerede shell-scripts — der er endnu mindre synlige end Homebrew og sværere at håndtere. Udviklerproduktiviteten lider, og sikkerhedsposituren forbedres ikke meningsfuldt.

At stole på, at udviklere selvforvalter er den modsatte fejlmode. At håbe, at udviklere regelmæssigt kører brew upgrade og selv tjekker CVE-databaser, kan ikke skaleres og er ikke reviderbart.

En moden tilgang kræver tre funktioner, der arbejder sammen:

  1. Centraliseret proxy med revisionslogning — alle brew install-, brew upgrade- og brew uninstall-operationer dirigeres gennem en proxy, der registrerer hver handling, tilknyttet en brugeridentitet og maskine.
  2. CVE-scanning integreret i pakkelivscyklussen — når en udvikler installerer en pakke, evalueres installationen mod kendte sårbarhedsdatabaser. Sårbare pakker kan blokeres, markeres eller installeres med en advarsel afhængigt af politikken.
  3. Politikmotor — en deklarativ mekanisme til at definere, hvilke pakker der er tilladt, blokeret eller kræver godkendelse inden installation.

Arkitektonisk Mønster: Den Centrale Homebrew-proxy

Det centrale arkitektoniske element er en proxy, der placeres mellem udviklernes maskiner og Homebrews upstream-CDN. Fra udviklerens perspektiv ændres intet: brew install ripgrep fungerer præcis som før. Internt dirigeres anmodningen via en virksomhedsproxy, der opsnapper, logger, evaluerer og videresender eller blokerer anmodningen.

Developer Machine
     │
     ▼
brew install ripgrep
     │
     ▼
 EnterpriseBrew Proxy (internal)
     ├── Log: user=alice, machine=mac-123, package=ripgrep@14.1.0, time=...
     ├── CVE Check: ripgrep@14.1.0 → no known CVEs ✓
     ├── Policy Check: ripgrep → in allowlist ✓
     └── Proxy to Homebrew CDN → return bottle

Denne arkitektur kræver:

  • DNS- eller HTTP-proxykonfiguration der sendes til udviklernes maskiner via MDM (Jamf, Kandji, Mosyle), og som peger Homebrews CDN-domæner mod den interne proxy.
  • TLS-terminering ved proxyen med et virksomheds-CA-certifikat, der er betroet på udviklernes maskiner — nødvendigt for HTTPS-inspektion uden at bryde certifikatvalidering.
  • En identitetsbevidst proxy, der kortlægger anmodninger til brugeridentiteter, enten via maskincertifikater, SSO-tokens eller begge.

Proxyen behøver ikke cache pakker (selvom caching forbedrer ydeevnen og muliggør air-gapped drift). Dens primære funktion er inspektion og logning.

Implementering af Politikmotoren

En veldesignet politikmotor adskiller tre kategorier af pakker:

Tilladelsesliste: Pakker der er eksplicit godkendt til installation uden restriktioner. Disse er gennemgået, er kendte for ikke at have uløste kritiske CVE'er og er passende for organisationens softwaremiljø.

Blokeringsliste: Pakker der aldrig må installeres, uanset hvem der anmoder om dem. Dette inkluderer typisk pakker, der muliggør adfærd forbudt af sikkerhedspolitikken (netværksrekognoseringsværktøjer, hjælpeprogrammer til udtrækning af legitimationsoplysninger, osv.) eller pakker fra forsyningskæder, der historisk set er blevet kompromitteret.

Standardadfærd: Pakker der hverken er tilladt eller blokeret. Mulighederne spænder fra tilladelsesorienteret (tillad med logning) til restriktiv (kræv eksplicit godkendelse inden installation). Det rigtige valg afhænger af dit regulatoriske miljø og din model for tillid til udviklere.

Politikkonfiguration bør versionstyres og være underlagt ændringshåndtering. Når en pakke flyttes fra standardpuljen til blokeringslisten — for eksempel fordi et revisionsresultat kræver det — bør denne ændring gennemgå den samme gennemgangsproces som enhver anden ændring af sikkerhedskontrol.

policy:
  defaultAction: allow  # or: block, requireApproval

  allowlist:
    - git
    - curl
    - ripgrep
    - fd
    - jq
    - node@20
    - python@3.12

  blocklist:
    - nmap
    - wireshark
    - metasploit
    - aircrack-ng

CVE-integration

CVE-integration kræver tilslutning til et eller flere sårbarhedsfeed og evaluering af hver pakkeanmodning mod dem. De relevante datakilder er:

  • NVD (National Vulnerability Database) — den autoritative amerikanske regerings CVE-database, tilgængelig via et gratis API.
  • OSV (Open Source Vulnerabilities) — Googles åbne database over sårbarheder i open source-pakker med god dækning af Homebrew-formler.
  • GitHub Advisory Database — bred dækning med god upstream-kobling.

Evalueringslogikken bør fastlægge den præcise version, der installeres, og kontrollere den mod alle gældende CVE'er. Alvorlighedstærskler bør være konfigurerbare: nogle organisationer blokerer alle HIGH- og CRITICAL-CVE'er på installationstidspunktet; andre blokerer kun CRITICAL og logger HIGH til gennemgang.

Afgørende er, at CVE-evaluering skal være kontinuerlig, ikke kun på installationstidspunktet. En pakke installeret i dag uden kendte CVE'er kan få et nyt CVE offentliggjort i morgen. Proxyen bør periodisk genevaluere installerede pakker på tværs af flåden og advare, når en maskines sårbarhedsprofil ændres.

Revisionslogning for Overholdelse

For organisationer, der opererer under SOC 2, ISO 27001, HIPAA eller lignende rammer, er revisionslogning af softwareinstallationer ofte et kontrolkrav. Revisionsloggen produceret af en central proxy bør registrere:

  • Tidsstempel (UTC, millisekundpræcision)
  • Brugeridentitet (SSO-brugernavn eller certifikatsubjekt)
  • Maskinidentifikator
  • Pakkenavn og anmodet version
  • Pakkeversion der er løst og installeret
  • CVE-status på installationstidspunktet
  • Politikbeslutning (tilladt / blokeret / markeret)
  • Kilde-IP og netværkssegment

Denne log bør sendes til et SIEM (Splunk, Elastic, Datadog) i realtid. Advarsler bør udløses ved: blokerede installationsforsøg, installationer af pakker med HIGH- eller CRITICAL-CVE'er der var tilladt under politikken, og usædvanlig installationsvolumen der kan indikere automatiseret aktivitet.

Air-Gappede og Begrænsede Netværksinstallationer

Mange virksomhedsmiljøer driver netværk med begrænset eller ingen internetadgang — finansielle handelsgulve, klassificerede myndighedsnetværk, kritiske infrastrukturmiljøer. Homebrew er ikke designet til disse miljøer, men med en caching-proxy kan det fungere.

En caching-proxy downloader Homebrew-bottles til lokal lagring og serverer dem derfra. Udviklere installerer pakker fra proxyen, som aldrig foretager eksterne anmodninger. Dette kræver:

  1. En synkroniseringsproces der kører på et netværk med internetadgang, downloader opdaterede bottles for godkendte pakker og overfører dem til det air-gappede miljø.
  2. Integritetskontrol af alle cachede bottles inden de serveres, for at sikre at synkroniseringsprocessen ikke er blevet manipuleret.
  3. Tilladelseslister der afgør, hvilke pakker udviklere overhovedet må installere, så synkroniseringsprocessen kun skal overføre det, der er godkendt. Homebrew installerer altid den aktuelle version, som pakkemetadataene angiver, så metadata og bottles bør synkroniseres sammen; et team, der har brug for en bestemt hovedversion, installerer en versioneret formel som postgresql@16.

Denne arkitektur er også fordelagtig i båndbreddebegrænsede miljøer, hvor det ville være spildt, hvis flere udviklere downloader den samme store pakke (en compiler, en databaseserver) fra internettet.

Konklusion

Uhåndteret Homebrew er et af de tydeligste eksempler på et sikkerhedsgab, der er velforstået, men ofte udskudt, fordi det føles som et udviklerpro­duktivitetsproblem snarere end et sikkerhedsproblem. XZ Utils-hændelsen og lignende viser, at grænsen mellem "udviklerværktøjer" og "virksomhedens sikkerhedsinfrastruktur" er kunstig.

Organisationer, der tager sikkerhed i udviklerens forsyningskæde seriøst, har brug for en proxyarkitektur, der giver synlighed, CVE-integration og politikhåndhævelse — uden at forringe den udvikleroplevelse, der gør Homebrew værdifuldt i første omgang. Målet er ikke at gøre Homebrew sværere at bruge. Det er at gøre dets brug reviderbar, politikoverholdende og modstandsdygtig over for de forsyningskædeangreb, der nu er en standarddel af trusselsbilledet.

Relaterede indlæg