İçeriğe geç
← Bloga dön
güvenliktedarik zincirihomebrewkurumsal

Kurumsalda Homebrew Güvenliği: macOS Geliştirici Tedarik Zincirini Güvence Altına Almak

Yönetilmeyen brew kurulumları BT için görünmezdir: Denetim izi yok, CVE kontrolü yok, politika yok. Bu açıklığın pratikte nasıl göründüğüne ve geliştiricileri yavaşlatmadan nasıl kapatılacağına yakından bakıyoruz.

EnterpriseBrew Team··8 dk okuma

2024 yılında XZ Utils arka kapısı (CVE-2024-3094), açık kaynak ekosisteminde büyük bir sarsıntıya neden oldu. Kötü niyetli bir aktör, iki yıl boyunca bir bakımcı olarak güven inşa etti; ardından yaygın olarak dağıtılan bir sıkıştırma kütüphanesine özenle gizlenmiş bir arka kapı yerleştirdi. Bu olay temel bir gerçeği gözler önüne serdi: yazılım tedarik zinciri, yalnızca en zayıf ve en az izlenen halkası kadar güvenlidir.

macOS filolarını yöneten kurumsal BT ve güvenlik ekipleri için Homebrew, tam olarak bu tür izlenmeyen bir halkayı temsil eder. Geliştiriciler yüzlerce paket kurar — derleyiciler, çalışma zamanları, CLI araçları, veritabanı istemcileri — ve çoğu kuruluşun nelerin, ne zaman kurulduğuna ya da bu paketlerin herhangi birinin bilinen güvenlik açıkları içerip içermediğine dair hiçbir görünürlüğü yoktur.

Bu rehber, yönetilmeyen Homebrew'un oluşturduğu saldırı yüzeyini inceler ve bunu ortadan kaldırmaya yönelik mimari kalıpları açıklar.

Kurumsal Ortamda Homebrew'un Gizli Risk Yüzeyi

Homebrew'un kolaylığı aynı zamanda güvenlik yüküdür. Tasarımı gereği, bir kurumun denetleyebileceği herhangi bir ara doğrulama adımı olmaksızın doğrudan internetten geliştiricinin makinesine kurulum yapar. Bunun pratikte ne anlama geldiğini düşünün:

Kurulu paketler hakkında kurumsal farkındalık yok. brew install ffmpeg komutunu çalıştıran bir geliştirici, Homebrew'un CDN'inden bir ikili dosya indirir. BT güvenlik ekibinin bu kurulum hakkında hiçbir kaydı yoktur; bunu bir yazılım envanterine göre kontrol etmenin yolu yoktur ve söz konusu paket daha sonra tehlikeye girmiş bulunursa bir uyarı alma mekanizması da bulunmamaktadır.

Düzeltici tetikleyici olmadan CVE maruziyeti. Homebrew paketleri genellikle kurumsal güvenlik açığı yönetimi iş akışlarına dahil edilmez. Qualys, Tenable veya Microsoft Defender for Endpoint gibi araçlar sistem düzeyindeki güvenlik açıklarını tarayabilir, ancak kullanıcı tarafından kurulan Homebrew paketlerini büyük ölçüde gözden kaçırır. openssl, curl veya libssh2 için kritik bir CVE yayımlandığında, "CVE yayımlandı"dan "etkilenen geliştirici bildirildi ve paket güncellendi"ye uzanan otomatik bir yol yoktur.

Filoda tutarsız ortamlar. Farklı geliştiriciler aynı araçların farklı sürümlerini kurar. Bir makinede node@18, diğerinde node@20. Bu durum, derlemeler için yeniden üretilebilirlik sorunları yaratır ve güvenlik yamalamasını karmaşık hale getirir — envanterini çıkaramadığınız şeyi yamalayamazsınız.

Politika uygulaması yok. Bazı paketler düzenlenmiş bir ortam için uygun değildir. Bir geliştirici, uzak erişim aracı, paket koklayıcı veya kimlik bilgilerini düz metin olarak saklayan bir yardımcı program kurabilir. Bir politika katmanı olmadan, bunu önlemenin hatta tespit etmenin herhangi bir mekanizması yoktur.

"Homebrew'u Güvence Altına Almak" Gerçekte Ne Gerektirir?

Kuruluşlar bu risklere genellikle iki yoldan biriyle yanıt verir; her ikisi de yetersizdir:

Homebrew'u tamamen engellemek yaygın ama üretkenliği olumsuz etkileyen bir yanıttır. Geliştiriciler bu araçlara ihtiyaç duyar. Homebrew'u engellemek, kurulumları gölge yöntemlere — manuel tarball çıkarma, pip install --user, Nix veya özel kabuk betikleri — iter; bunlar Homebrew'dan çok daha az görünürdür ve yönetilmesi daha zordur. Geliştirici verimliliği düşer, güvenlik durumu ise anlamlı biçimde iyileşmez.

Geliştiricilerin kendi kendilerini yönetmelerine güvenmek ise tam tersi başarısızlık biçimidir. Geliştiricilerin düzenli olarak brew upgrade çalıştıracağını ve CVE veritabanlarını kendilerinin kontrol edeceğini ummak ölçeklenemez ve denetlenemez.

Olgun bir yaklaşım, birlikte çalışan üç yeteneği gerektirir:

  1. Denetim günlüğü ile merkezi proxy — tüm brew install, brew upgrade ve brew uninstall işlemleri, her eylemi bir kullanıcı kimliği ve makinesiyle ilişkilendirerek kaydeden bir proxy üzerinden yönlendirilir.
  2. Paket yaşam döngüsüne entegre CVE taraması — bir geliştirici paket kurduğunda, kurulum bilinen güvenlik açığı veritabanlarına göre değerlendirilir. Güvenlik açığı bulunan paketler, politikaya bağlı olarak engellenebilir, işaretlenebilir veya uyarıyla birlikte kurulabilir.
  3. Politika motoru — hangi paketlerin izinli, engellenmiş veya kurulumdan önce onay gerektirdiğini tanımlamaya yönelik bildirimsel bir mekanizma.

Mimari Kalıp: Merkezi Homebrew Proxy'si

Temel mimari öğe, geliştirici makineleri ile Homebrew'un yukarı akış CDN'i arasında yer alan bir proxy'dir. Geliştirici açısından hiçbir şey değişmez: brew install ripgrep tam olarak eskisi gibi çalışır. Dahili olarak istek, isteği durduran, günlüğe kaydeden, değerlendiren ve proxy yapan ya da engelleyen bir kurumsal proxy üzerinden yönlendirilir.

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

Bu mimari şunları gerektirir:

  • DNS veya HTTP proxy yapılandırması, Homebrew'un CDN etki alanlarını dahili proxy'ye yönlendirerek MDM (Jamf, Kandji, Mosyle) aracılığıyla geliştirici makinelerine dağıtılır.
  • TLS sonlandırma, geliştirici makinelerde güvenilen kurumsal bir CA sertifikasıyla proxy'de gerçekleştirilir — sertifika doğrulamasını bozmadan HTTPS denetimi için gereklidir.
  • İstekleri kullanıcı kimliklerine, makine sertifikaları, SSO belirteçleri veya her ikisi aracılığıyla eşleyen kimlik farkında bir proxy.

Proxy'nin paketleri önbelleğe alması gerekmez (önbelleğe alma performansı artırır ve hava boşluklu çalışmayı mümkün kılar). Temel işlevi inceleme ve günlük kaydıdır.

Politika Motorunu Uygulamak

İyi tasarlanmış bir politika motoru, paketleri üç kategoriye ayırır:

İzin listesi: Kısıtlama olmaksızın kurulumu açıkça onaylanmış paketler. Bunlar incelenmiş, çözümlenmemiş kritik CVE'lere sahip olmadığı bilinen ve kuruluşun yazılım ortamı için uygun olan paketlerdir.

Engelleme listesi: Kimin talep ettiğinden bağımsız olarak hiçbir zaman kurulmaması gereken paketler. Bu, genellikle güvenlik politikası tarafından yasaklanan davranışlara izin veren paketleri (ağ keşif araçları, kimlik bilgisi dökme yardımcı programları vb.) veya tarihsel olarak tehlikeye girmiş tedarik zincirlerinden gelen paketleri içerir.

Varsayılan davranış: Ne izin verilen ne de engellenen paketler. Seçenekler, izin verici (günlük kaydıyla izin ver) ile kısıtlayıcı (kurulumdan önce açık onay gerektirir) arasında değişir. Doğru seçim, düzenleyici ortamınıza ve geliştirici güven modelinize bağlıdır.

Politika yapılandırması sürüm kontrollü olmalı ve değişiklik yönetimine tabi olmalıdır. Bir paket varsayılan havuzdan engelleme listesine taşındığında — örneğin, bir denetim bulgusu bunu gerektirdiğinden — bu değişiklik, diğer güvenlik kontrolü değişiklikleriyle aynı inceleme sürecinden geçmelidir.

policy:
  defaultAction: allow  # or: block, requireApproval

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

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

CVE Entegrasyonu

CVE entegrasyonu, bir veya daha fazla güvenlik açığı akışına bağlanmayı ve her paket kurulum isteğini bunlara göre değerlendirmeyi gerektirir. İlgili veri kaynakları şunlardır:

  • NVD (Ulusal Güvenlik Açığı Veritabanı) — ücretsiz bir API aracılığıyla erişilebilen yetkili ABD hükümeti CVE veritabanı.
  • OSV (Açık Kaynak Güvenlik Açıkları) — Google'ın açık kaynak paketlerindeki güvenlik açıklarının açık veritabanı; Homebrew formülleri için iyi kapsama sahiptir.
  • GitHub Advisory Veritabanı — iyi yukarı akış bağlantısıyla geniş kapsam.

Değerlendirme mantığı, kurulmakta olan tam sürümü çözümlemeli ve tüm geçerli CVE'lere karşı kontrol etmelidir. Önem eşikleri yapılandırılabilir olmalıdır: bazı kuruluşlar kurulum sırasında tüm YÜKSEK ve KRİTİK CVE'leri engeller; diğerleri yalnızca KRİTİK'leri engeller ve YÜKSEK'leri inceleme için günlüğe kaydeder.

Kritik olarak, CVE değerlendirmesi sürekli olmalı, yalnızca kurulum sırasında değil. Bugün bilinen CVE'ler olmaksızın kurulan bir paketin yarın yeni bir CVE'si yayımlanabilir. Proxy, filodaki kurulu paketleri periyodik olarak yeniden değerlendirmeli ve bir makinenin güvenlik açığı durumu değiştiğinde uyarı vermelidir.

Uyumluluk için Denetim Günlüğü

SOC 2, ISO 27001, HIPAA veya benzer çerçeveler kapsamında faaliyet gösteren kuruluşlar için yazılım kurulumlarının denetim günlüğü genellikle bir kontrol gereksinimidir. Merkezi bir proxy tarafından üretilen denetim günlüğü şunları kaydetmelidir:

  • Zaman damgası (UTC, milisaniye hassasiyeti)
  • Kullanıcı kimliği (SSO kullanıcı adı veya sertifika konusu)
  • Makine tanımlayıcısı
  • İstenen paket adı ve sürümü
  • Çözümlenen ve kurulan paket sürümü
  • Kurulum sırasında CVE durumu
  • Politika kararı (izin verildi / engellendi / işaretlendi)
  • Kaynak IP ve ağ segmenti

Bu günlük gerçek zamanlı olarak bir SIEM'e (Splunk, Elastic, Datadog) gönderilmelidir. Şu durumlarda uyarılar tetiklenmelidir: engellenen kurulum girişimleri, politika kapsamında izin verilen YÜKSEK veya KRİTİK CVE'lere sahip paket kurulumları ve otomatik etkinliği gösterebilecek olağandışı kurulum hacmi.

Air-Gapped ve Kısıtlı Ağ Dağıtımları

Pek çok kurumsal ortam, kısıtlı veya hiç internet erişimi olmayan ağlarda faaliyet gösterir — finansal işlem katları, gizli devlet ağları, kritik altyapı ortamları. Homebrew bu ortamlar için tasarlanmamıştır; ancak önbelleğe alıcı bir proxy ile çalışması sağlanabilir.

Önbelleğe alıcı proxy, Homebrew bottle'larını yerel depolamaya indirir ve oradan sunar. Geliştiriciler paketleri proxy'den kurar; proxy hiçbir zaman dış istek göndermez. Bu şunları gerektirir:

  1. İnternet erişimine sahip bir ağda çalışan, onaylanmış paketler için güncellenmiş bottle'ları indiren ve bunları hava boşluklu ortama aktaran bir senkronizasyon süreci.
  2. Senkronizasyon sürecinin kurcalanmadığından emin olmak için servis edilmeden önce tüm önbelleğe alınmış bottle'ların bütünlük doğrulaması.
  3. Geliştiricilerin hangi paketleri kurabileceğini belirleyen izin listesi politikaları; böylece senkronizasyon süreci yalnızca onaylanmış paketleri taşır. Homebrew her zaman paket meta verisinde belirtilen güncel sürümü kurduğundan meta veri ile bottle'lar birlikte senkronize edilmelidir; belirli bir ana sürüme ihtiyaç duyan ekip postgresql@16 gibi sürümlü bir formül kurar.

Bu mimari aynı zamanda, birden fazla geliştiricinin internetten aynı büyük paketi (bir derleyici, bir veritabanı sunucusu) indirmesinin israf olacağı bant genişliği kısıtlı ortamlarda da faydalıdır.

Sonuç

Yönetilmeyen Homebrew, bir güvenlik sorunundan ziyade geliştirici verimliliği sorunu gibi hissettirdiği için iyi anlaşılmış ancak sıklıkla ertelenen güvenlik açığı örneklerinin en açık olanlarından biridir. XZ Utils olayı ve benzerleri, "geliştirici araçları" ile "kurumsal güvenlik altyapısı" arasındaki sınırın yapay olduğunu göstermektedir.

Geliştirici tedarik zinciri güvenliğini ciddiye alan kuruluşların, Homebrew'u en başından değerli kılan geliştirici deneyimini bozmadan görünürlük, CVE entegrasyonu ve politika uygulaması sağlayan bir proxy mimarisine ihtiyacı vardır. Amaç Homebrew'u kullanmayı zorlaştırmak değildir. Amaç, kullanımını denetlenebilir, politikaya uygun ve artık tehdit ortamının standart bir parçası haline gelen tedarik zinciri saldırılarına karşı dirençli kılmaktır.

İlgili yazılar