Meteora Web

GitHub package firewall, npm için zararlı yazılım filtresi önizlemede

GitHub, npm için package firewall'u genel önizlemeye açtı. Paketleri ve meta verileri kurulumdan önce denetler. Nasıl çalıştığını ve sınırlarını öğren.

Ing. Calogero Bono 8 dk okuma
GitHub package firewall, npm için zararlı yazılım filtresi önizlemede

GitHub, 20 Ekim 2026'da package firewall'u tanıttı. Bu filtre, paketleri kuran bilgisayarlar ile bunları indirdikleri genel kayıtlar arasına yerleşir. Özellik bugün GitHub Enterprise Cloud müşterilerinin tamamı için genel önizlemede ve yalnızca npm'i destekliyor. Amaç, kurulum anında etkili olan kötü amaçlı yazılımı durdurmak. Bu risk, kimsenin denetlemediği bağımlılıkları kuran yapay zeka ajanları ve build sistemleri için daha büyük. Yazılım geliştiriyorsan ya da geliştirenleri yönetiyorsan, yazılım tedarik zincirinin güvenliğinin nereye gittiğine dair bir işaret.

Olayların ayrıntısına girmeden önce birkaç terim. Bir kayıt (registry), paketlerin indirildiği çevrim içi depodur. JavaScript için npm bunun bir örneğidir. Bir bağımlılık, projenin kullandığı başkasına ait kod parçasıdır. CI/CD, yazılımı derleyip yayımlayan otomatik süreçlerdir. Bir SLSA attestation, bir paketin nasıl ve kim tarafından üretildiğine dair doğrulanabilir bir beyandır. Meta veriler ise pakete ait bilgilerdir, örneğin mevcut sürümlerin listesi.

Zenithby Meteora Web İşletmenin işletim sistemi. Sosyal medya, müşteriler, rezervasyonlar ve faturalar tek bir platformda. Spor salonları, berberler, profesyoneller. Zenith’i keşfet → Ücretsiz demo · kart gerekmez

GitHub package firewall nedir?

GitHub'ın resmi changelog'una göre, son dönemde paketlerin kurulduğu anı hedef alan kötü amaçlı yazılım saldırıları ciddi bir dalga oluşturdu. Görevini ya da build'ini tamamlamak için bağımlılıkları kuran ajanlar ve CI runner'lar özellikle hedef oluyor, çünkü işlemin ortasında kimse yok.

Firewall, uç noktalar ile ya da iç kayıtlar ile yukarı akıştaki paket depoları arasında çalışır. The Hacker News'un aktardığına göre GitHub bunu şöyle tarif ediyor. «The firewall inspects both metadata requests and package downloads for signs of malicious activity, acting as an install-time policy gate,» yani kurulum anında uygulanan bir kural kapısı.

Konu teorik değil. The Register, saldırganların GitHub issue'larını bir saatten kısa sürede 61 genel depoya karşı bir tedarik zinciri kampanyasına dönüştürdüğünü yazdı. Elimizdeki sayfada başka ayrıntı yok, bu yüzden iki haberin birbiriyle bağlantılı olup olmadığını söyleyemeyiz.

Nasıl çalışır ve hangi denetimleri sunar?

Süreç iki adımdan oluşuyor. Önce yöneticiler kendi enterprise'ları için kuralları belirler. Sonra kodlama ajanları ve CI/CD host'ları doğrudan genel kayıtlara değil firewall'a yönelir. Hem meta veri istekleri hem de indirmeler firewall'dan geçer ve politikaya göre değerlendirilir.

Mevcut denetimler

The Hacker News'in listesine göre şu denetimler var.

  • GitHub Advisory Database içindeki aktif uyarılara bakarak bilinen kötü amaçlı yazılımı engelleme.
  • Aynı veritabanı üzerinden güvenlik açıklarını ciddiyetine göre engelleme. Varsayılan ayar yalnızca «Critical only» seviyesini engeller, ama «High or higher», «Medium or higher» ya da «Any severity» seçilebilir.
  • Attestation düşürmelerini engelleme. Firewall, istenen sürümün attestation'larını önceki sürümlerle karşılaştırır ve SLSA attestation'ı yoksa indirmeyi durdurur.
  • Yeni kurulum script'lerini engelleme. Bunlar preinstall ya da postinstall hook'larıyla çalışır ve hassas verileri çalmak için kullanılabilir.
  • Yapılandırılan minimum yaştan daha yeni sürümlerin kurulmasını engelleyen bekleme süresi (cooldown).

Cooldown 1 ile 365 gün arasında ayarlanabilir. Varsayılan değer 1 gündür ve 0 yapılarak kapatılır.

Ya iyi bir paketi engellerse?

Bir paket yanlışlıkla engellenirse kullanıcı istisna talep edebilir. GitHub için bu akış, GitHub Advanced Security'nin diğer özelliklerindekine benzer. The Hacker News'e göre talebi enterprise yöneticileri ve güvenlik sorumluları onaylayabilir.

Ne kadara mal olur ve kimler kullanabilir?

Hizmet, residency sürümü dahil tüm GitHub Enterprise Cloud müşterileri için genel önizlemede. Önizleme sırasında ücretsiz. Genel kullanılabilirlik geldiğinde ise GitHub'ın açıklamasına göre ölçülen kullanıma göre ücretlendirilecek, Actions faturalandırmasına benzer bir modelle.

GitHub, önizlemenin altyapıyı büyütmek ve müşteri taleplerine göre yeni işlevler eklemek için olduğunu söylüyor. Kurulum talimatları için Protecting endpoints with package firewall belgesine yönlendiriyor.

Bekleme süreleri neden bu kadar konuşuluyor?

Cooldown en basit ve belki de en yaygın kuraldır. The Hacker News, son bir yılda npm, Python, Visual Studio Code, Ruby, Bun, pnpm ve Yarn'a benzer beklemelerin eklendiğini hatırlatıyor. Temel fikir, yeni yayımlanmış ve henüz incelenmemiş bir sürümün hemen bir build'e girme olasılığını azaltmak.

Özellikle popüler bir paketin bakımcısının hesabını ele geçirip zehirli bir sürüm yayımlayan saldırganlara karşı işe yarar. Bekleme, hem elle hem otomatik yapılan hızlı yayılmayı yavaşlatır.

Aynı yazı, 12 Kasım 2026'da çıkması beklenen Rust 1.100'ün crate'ler için yapılandırılabilir bir minimum yayımlanma yaşı ekleyeceğini belirtiyor. Seçenek «global-min-publish-age» adını taşıyor ve cargo/config.toml dosyasında yer alıyor. Belirtilmezse yedi günlük varsayılan bekleme uygulanıyor.

Madalyonun diğer yüzünü The Hacker News'in aktardığı Socket anlatıyor. «The tradeoff is that legitimate fixes have to wait, too, unless developers make an exception,» diyor şirket. Denetimlerden kaçmış bir sürümün cooldown'ı rahatlıkla atlatabileceğini de ekliyor. Socket'e göre değeri, araştırmacılara, bakımcılara ve kayıtlara müdahale için zaman tanımasında.

Bilinmesi gereken sınırlar

  • Firewall bugün yalnızca npm'i destekliyor. PHP, Python ya da başka ekosistemlerle çalışanlar kapsam dışında ve kaynaklar diğer kayıtlar için bir tarih vermiyor.
  • Yalnızca GitHub Enterprise Cloud müşterilerine ayrılmış. Kaynaklar daha küçük planlardan söz etmiyor.
  • Önizlemedeyiz. İşlevler, altyapı ve fiyatlar değişebilir, ölçülen kullanım maliyeti de henüz belli değil.
  • Etkinlik hakkında bağımsız verimiz yok. Kaynaklar GitHub'ın beyanlarını aktarıyor, gerçek kötü amaçlı yazılımlarla yapılmış testleri değil. Yanlış pozitiflerle ilgili rakamlar da yok.
  • Socket'in de belirttiği gibi cooldown, kötü amaçlı kodu zararsız hale getirmez. Tespit edilmeyen bir sürüm, bekleme süresinin ötesinde de gizli kalabilir.

Dijital alanda çalışanlar için ne değişiyor

Pratik nokta şu – güvenlik, sonradan kontrol etmekten kurulumdan önce kontrol etmeye kayıyor. Kendi kendine yazıp kuran yapay zeka ajanlarıyla geliştirme yapanlar için bu, her ajana güvenmek yerine merkezi bir kurala sahip olmak anlamına geliyor. Yapay zeka destekli geliştirme araçları kullanıyorsan, KOBİ'ler için vibe coding yazımızdaki riskleri yeniden gözden geçirmeye değer.

İtalyan şirketler için konu uyumluluğa da dokunuyor. Yazılım tedarik zinciri, NIS2 tedarikçi kaydı rehberinde ele aldığımız konunun bir parçası. Paketlerin yazılı kurallara sahip bir filtreden geçtiğini gösterebilmek somut bir argüman, ama hiçbir kaynak firewall'u NIS2 ile ilişkilendirmiyor.

Açık kaynak kullanımı yoğun olanlar, her bağımlılığın bir tedarikçi olduğunu hatırlamalı. Bu konuyu şirkette açık kaynak derinlemesine yazımızda işledik. Enterprise müşterisi olmayanlar da bazı paket yöneticilerinin sunduğu bekleme süreleri gibi mevcut araçlarla aynı fikri uygulayabilir.

Build ve üretim sunucularında güncellemeler ve izolasyon da önemli. Altyapının başkaları tarafından yönetilmesini istiyorsan hosting ve yönetilen sunucu hizmetimize göz atabilirsin. Özel bir proje üzerinde çalışıyorsan yolu özel yazılım geliştirme sayfamızda bulabilirsin.

Bizim değerlendirmemiz

Fikir doğru. Bir paketi bilgisayarda çalışmadan durdurmak, sonradan fark etmekten daha etkili ve bunu tek bir noktada yapmak, her geliştiricinin ya da her ajanın disiplinine güvenmekten kurtarıyor. GitHub'ın denetimsiz çalışan ajanlardan yola çıkması, sorunu dürüstçe okuduğunu gösteriyor.

Çekincelerimiz iki tane. Birincisi ticari. Bu kadar faydalı bir koruma, şimdilik Enterprise segmentine ayrılmış ve önizlemeden sonra kullanıma göre ücretlendirilecek. Bu da en çok risk altında olan küçük ekipleri dışarıda bırakma riski taşıyor. İkincisi teknik. Denetimlerin çoğu GitHub'ın veritabanına ve zamana dayanıyor, Socket'in de kabul ettiği gibi zaman bir garanti değil.

Bu yüzden bunu nihai bir kalkan olarak görmüyoruz. Bağımlılık incelemesi, sürüm kilitleme ve ajanlar için minimum yetkilerle birlikte kullanıldığında işe yarayan ek bir katman. Firewall'u açmanın yeterli olacağını düşünüyorsan, sahte bir güvenliğe kapılıyorsun demektir.

Sık sorulan sorular

GitHub package firewall ücretsiz mi?

Evet, ama yalnızca önizleme sırasında. GitHub, genel kullanılabilirlikte ölçülen kullanıma göre ücret alınacağını, Actions'a benzer bir modelle, söylüyor. Fiyatlar henüz açıklanmadı.

Yalnızca npm ile mi çalışır?

Evet, şu anda yalnızca npm paketlerini destekliyor. Kaynaklar diğer ekosistemler için bir tarih vermiyor. Başka dillerle çalışıyorsan, şimdilik başka savunma yöntemlerine bakman gerekir.

Kimler kullanabilir?

Residency sürümü dahil tüm GitHub Enterprise Cloud müşterileri. Kaynaklar başka planlardan söz etmiyor. Yöneticiler kuralları tüm enterprise için yapılandırıyor.

Meşru bir paketi engellerse ne olur?

Kullanıcı istisna talep edebilir. The Hacker News'e göre talep yöneticiler ve güvenlik sorumluları tarafından onaylanabilir. GitHub'a göre akış, Advanced Security'nin diğer özellikleriyle benzer.

Bekleme süresi kötü amaçlı yazılımı durdurmaya yeter mi?

Hayır. Yeni yayımlanmış sürümlere karşı zaman kazandırır, ama Socket, kötü amaçlı kodun yaşla zararsız hale gelmediğini hatırlatıyor. Tespit edilmeyen bir sürüm bekleme süresini atlatabilir.

Genel kullanılabilirliğe kadar nelere bakmalı

Önümüzdeki aylarda üç şeyi takip etmekte fayda var. GitHub'ın belirleyeceği kullanıma dayalı fiyatı, npm dışına çıkıp çıkmayacağını ve 12 Kasım 2026'da beklenen Rust 1.100 ile gelecek minimum bekleme özelliğini. Bu arada şunları yapabilirsin.

  • CI ve ajanların kullandığı bağımlılıkları listele, hangisini denetimsiz kurabileceklerine karar ver.
  • Yeni sürümlere bir bekleme süresi uygulamayı değerlendir, meşru düzeltmeleri de geciktireceğini bilerek.
  • İstisnalar için bir prosedür hazırla. Bir sorumlu hızlı onaylasın ama yazılı bir kayıt tutulsun.

Kaynaklar

Zenithby Meteora Web İşletmenin işletim sistemi. Sosyal medya, müşteriler, rezervasyonlar ve faturalar tek bir platformda. Spor salonları, berberler, profesyoneller. Zenith’i keşfet → Ücretsiz demo · kart gerekmez

Bunu da oku

Blogdan

Son yazılar