Nx ve bazı destek eklentilerinin kötü amaçlı sürümleri dağıtıldı

 (github.com/nrwl)
3 puan yazan GN⁺ 2025-08-29 | 1 yorum | WhatsApp'ta paylaş
  • Nx paketi ve eklentilerinin kötü amaçlı sürümleri npm'e dağıtıldı; bunlar dosya sistemini tarayıp kimlik bilgilerini topladıktan sonra kullanıcının Github hesap deposuna gönderiyor
  • Etkilenip etkilenmediğinizi doğrulamak için Github hesabınızda s1ngularity-repository deposunun oluşturulup oluşturulmadığını kontrol etmeniz gerekiyor
  • Enfekte olduysanız token ve parolaları değiştirmek, kötü amaçlı depoyu silmek ve kabuk yapılandırma dosyalarını incelemek mutlaka gerekli
  • Kötü amaçlı sürümler sisteme postinstall betiği ile etki ediyor; özellikle VSCode Nx Console eklentisi kullanılırken farkında olmadan çalıştırılma riski artıyor
  • Nx ekibi yeniden yaşanmayı önleyici ve ek güvenlik önlemlerini devreye aldı; ilgili sürümler npm'den kaldırıldı

Genel bakış ve özet

  • Bu güvenlik duyurusu, Nx paketi ve bazı ilişkili eklentilere yönelik ciddi bir tedarik zinciri saldırısıyla ilgili; kötü amaçlı kod npm üzerinden dağıtıldı
  • Söz konusu kötü amaçlı sürümler, kullanıcının dosya sistemini tarayarak kimlik bilgileri, yollar ve benzeri verileri topluyor ve bunları Github deposuna (s1ngularity-repository) yüklüyor
  • Kötü amaçlı postinstall betiği ayrıca kullanıcının kabuk yapılandırma dosyalarını (.zshrc, .bashrc) değiştirerek sistem kapatma komutu ekliyor
  • Saldırı vektörü, saldırının ilerleyişi, etkilenen sürümler, kullanıcıların alması gereken acil önlemler ve tekrarını önleme adımları ayrıntılı biçimde özetleniyor

Acil müdahale yöntemi

Herkesin kontrol etmesi gerekenler

  1. Kendi Github hesabınızdaki depo listesinde s1ngularity-repository oluşturulup oluşturulmadığını kontrol edin
  2. İlgili depoda yer alan dosyaları indirip kayıt altına alın
  3. Depoyu Github'dan silin
  4. security@nrwl.io adresine e-posta göndererek sızan bilgilerin nasıl çözümleneceğine dair yönlendirme alın
  5. Tüm hesapların kimlik bilgilerini ve token'larını derhal değiştirin

Github token'ı nasıl değiştirilir

  • https://github.com/settings/connections/… adresini ziyaret edin
  • Bağlı uygulamanın erişim izinlerini kaldırarak mevcut token'ı geçersiz kılın
  • gh CLI kullanıyorsanız yeniden kimlik doğrulaması yaparak yeni token oluşturun
  • Önlem alınmazsa mevcut token kötüye kullanılma riski taşır

Kötü amaçlı Nx sürümünü kullanmayı durdurma ve temizleme

  • Şu anda kullandığınız Nx sürümünün kötü amaçlı sürüm olup olmadığını npm ls nx komutuyla kontrol edin
  • Enfekte sürümse npm uninstall nx && npm install nx@latest ile güncelleyin
  • npm cache clean --force ile önbelleği temizleyin

Zaten enfekte olmuş kullanıcılar

  • npm ve Github token'larını değiştirin
  • Github ve ilişkili hizmetlerdeki tüm parolaları ve kimlik bilgilerini sıfırlayın
  • .zshrc, .bashrc dosyalarında yabancı komutlar eklenip eklenmediğini kontrol edip silin

Kurum içi paket deposu yöneticileri için

  • Kurum içi proxy kayıt defterinden kötü amaçlı sürümleri derhal silerek ek yayılımı engellemek gerekiyor
Reklam

Etkilenen sürümler

Nx paketi

  • 21.5.0, 20.9.0, 20.10.0, 21.6.0, 20.11.0, 21.7.0, 21.8.0, 20.12.0
  • 10:44 PM EDT itibarıyla npm'den kaldırıldı

@nx/devkit, @nx/js, @nx/workspace, @nx/node, @nx/eslint, @nx/key, @nx/enterprise-cloud

  • 10:44 PM ve 6:20 AM EDT itibarıyla npm'den kaldırıldı

Saldırı vektörünün ayrıntıları

Zafiyetli workflow'nun nedeni

  • Github Actions workflow'suna rastgele kod çalıştırmaya izin veren bir zafiyet eklendi
  • PR başlığına belirli bir bash kodu eklenince workflow içinde sistem komutlarının çalışmasına yol açan bir zafiyet vardı (Bash Injection)
  • pull_request_target tetikleyicisi üzerinden yükseltilmiş yetkiler (GITHUB_TOKEN vb.) edinildiği için kötüye kullanıldı
  • Silinmeden önce ana dal dışındaki eski bir dalda zafiyetli workflow korunuyordu; saldırgan bu sayede kötü amaçlı bir PR ile workflow'yu çalıştırıp secret'ları çalmayı başardı

npm token'ının ele geçirilme süreci

  • Zafiyetli workflow üzerinden publish.yml çalıştırıldı
  • publish.yml, npm token'ını Github Secrets'ta saklıyordu; bu süreçte token harici bir webhook'a gönderildi
  • Sonuçta saldırgan bu token ile Nx ve destek paketlerinin kötü amaçlı sürümlerini npm'e yükledi

Kötü amaçlı paketin davranışı

Kimlik bilgileri dahil bilgilerin toplanması ve Github deposunda yayımlanması

  • Enfekte Nx paketinin postinstall betiği çalıştığında çeşitli metin dosyalarının konumları ve kimlik bilgileri toplanıyor
  • Veriler s1ngularity-repository adlı Github deposuna base64 ile kodlanarak yükleniyor
  • Gerçek depo silinmiş olsa bile daha önce herkese açık durumdaydı; bu yüzden bilgi sızıntısı ihtimali göz önünde bulundurulmalı

Kabuk profillerinin (.zshrc, .bashrc) tahrif edilmesi

  • postinstall, sudo shutdown -h 0 komutunu ekleyerek terminal çalıştığında sistemin kapanmasına yol açabiliyor ve parola ifşasına neden olabiliyor

postinstall'ın çalışabildiği çeşitli senaryolar

  • Açıkça npm install / yarn / pnpm install çalıştırmanın dışında, geçişli bağımlılıklar, editör eklentileri ve betik çalıştırmaları gibi çeşitli durumlarda da devreye girebilir

    Reklam

  • Özellikle VSCode için Nx Console eklentisinin 18.6.30 ~ 18.65.1 sürümleri, editör açılırken otomatik olarak nx@latest kurduğu için postinstall'ın çalışmasına neden olabilir

  • Temelde, niyet edilmemiş olsa bile birçok yerde NPM modülü kurulumu gerçekleşebileceğine dikkat etmek gerekiyor

  • Nx Console 18.66.0 sürümünden itibaren latest nx kurulum süreci kaldırıldı

Saldırı ve müdahale zaman çizelgesi

21 Ağustos

  • 4:31 PM: Bash injection zafiyetini içeren PR birleştirildi
  • 10:48 PM: Zafiyete işaret eden paylaşım X'te (eski adıyla Twitter) yayımlandı

22 Ağustos

  • Öğleden sonra: İç inceleme yapıldı, zafiyetli workflow geri alındı (eksik biçimde)
  • CodeQL devreye alınarak gelecekteki PR'lerde benzer zafiyetlerin tespit edilmesi sağlandı
Reklam

24 Ağustos

  • Saldırganın fork'unda npm token sızıntısına işaret eden bir commit oluştu
  • Kötü amaçlı PR oluşturulup silindi, publish.yml bu PR tarafından çalıştırıldı

26 ~ 27 Ağustos (kötü amaçlı sürümlerin dağıtılması ve müdahale)

  • Çok sayıda kötü amaçlı Nx ve eklenti sürümü sırasıyla npm'e dağıtıldı
  • Github/NPM topluluğuna issue bildirildi
  • 10:44 PM: NPM tarafı ilgili sürümlerin tamamını kaldırma dahil işlemleri gerçekleştirdi
  • 11:57 PM: Tüm Nx ile ilişkili paketlerin yayımlanmasında kullanılan token'lar geçersiz kılındı
  • 27 Ağustos: Nx Console yaması, 2FA, Trusted Publisher yöntemine geçiş gibi ek önlemler alındı

Önleyici tedbirler ve sonraki müdahaleler

  • nrwl organizasyonundaki tüm maintainer'lar için 2FA zorunlu hale getirildi
  • Trusted Publisher mekanizması uygulandı. npm token tabanlı dağıtım yasaklandı
  • Bundan sonraki paketler yalnızca 2FA ve güvene dayalı doğrulamadan sonra yayımlanacak
  • Ek risk tespiti, PR onayı ve dal koruması gibi katmanlı önlemler uygulanacak

Çıkarılan dersler ve ileriye dönük plan

  • Tedarik zinciri ve CI/CD hattı güvenliği ile workflow yetkilerinin en aza indirilmesinin önemi yeniden görüldü
  • Ekip içinde tekrar değerlendirme yapıldıktan sonra öğrenilenler toplulukla paylaşılacak

İletişim

  • security@nrwl.io üzerinden iletişime geçilebilir

Referanslar ve ekler

  • Github üzerindeki başlıca issue'lar, zaman çizelgesi ve ilgili paylaşımlar
  • Enfekte paket içindeki telemetry.js betiğine örnek veriliyor
  • Bu betik, dosya sistemindeki önemli metin dosyalarının yollarını envanter oluşturma amacıyla topluyor

Sonuç özeti

  • Nx ve ilişkili eklentiler için en güncel güncellemelerin ve yamaların uygulanması önemli
  • npm, Github ve benzeri temel kimlik doğrulama bilgilerinin derhal değiştirilmesi öneriliyor
  • Bu olay, tedarik zinciri güvenliği ve workflow yetki yönetimindeki eksikliklerin büyük çaplı bir olaya yol açabileceğini bir kez daha gösterdi

İlgili okumalar

1 yorum

 
GN⁺ 2025-08-29
Hacker News yorumu

  • Periyodik olarak npm install script’lerini devre dışı bırakmanızı hatırlatmak isterim

    • Örnek olarak şu komut kullanılabilir:

        npm config set ignore-scripts true [--global]

    • Bu ayar proje bazında ya da global olarak kolayca uygulanabilir

    • Günümüzde script olmadan çalışmayan meşru paketler nadir olduğu için çoğu durumda sorun çıkmaz

    • Mutlaka çalışması gereken paketler için ayrı bir kurulum script’i hazırlayıp ilgili klasörde elle çalıştırarak çözüm bulunabilir

    • Tedarik zinciri saldırılarına karşı her derde deva bir çözüm değil ama pratikte npm üzerinden gelen birçok saldırıyı etkili şekilde engelledi

    • Daha fazla bilgi için npm config resmi dokümantasyonuna bakabilirsiniz

    • Ben de bubblewrap kullanarak npm, pnpm, yarn ve bunların başlattığı tüm oturumları sistemden izole biçimde çalıştırıyorum

      • Kaynak kodum sadece ~/code altında bulunuyor ve PATH’in başına aşağıdaki bash script’ini npm adıyla kaydediyorum
      • Diğer paket yöneticilerini de symlink/hardlink ile bağlıyorum: 
        #!/usr/bin/bash
bin=$(basename "$0")
exec bwrap \
  --bind ~/.cache/nodejs ~/.cache \
  --bind ~/code ~/code \
  --dev /dev \
  --die-with-parent \
  --disable-userns \
  --new-session \
  --proc /proc \
  --ro-bind /etc/ca-certificates /etc/ca-certificates \
  --ro-bind /etc/resolv.conf /etc/resolv.conf \
  --ro-bind /etc/ssl /etc/ssl \
  --ro-bind /usr /usr \
  --setenv PATH /usr/bin \
  --share-net \
  --symlink /tmp /var/tmp \
  --symlink /usr/bin /bin \
  --symlink /usr/bin /sbin \
  --symlink /usr/lib /lib \
  --symlink /usr/lib /lib64 \
  --tmpfs /tmp \
  --unshare-all \
  --unshare-user \
  "/usr/bin/$bin" "$@"
      • Böylece paket yöneticisi sadece ~/code için ve sistem kütüphanelerine de yalnızca salt okunur erişim elde ediyor
      • bubblewrap kararlı bir araç; Steam ve flatpak gibi yerlerde de kullanılıyor

    • pnpm kullanmak da bir seçenek. Son sürümler varsayılan olarak tüm lifecycle script’lerini yok sayıyor ve yalnızca tek tek whitelist’e alınanları çalıştırıyor

    • Bu tavsiyeyi her duyduğumda şu soruyu soruyorum: npm’in kurduğu onlarca ila yüz binlerce satırlık kodu gerçekten okuyup denetleyen geliştirici yok

      • Çoğu geliştiricinin iş akışı şöyle ilerliyor
        1. git clone
        2. npm install (burada kötü amaçlı paket kurulabilir; post-install script’lerini yok saymak bunu geçici olarak engelleyebilir)
        3. npm run (burada kötü amaçlı paket çalışır ve bulaşma gerçekleşir)
      • Bu tavsiyenin işe yaraması için 2 ile 3 arasında tüm node_modules içeriğinin izlenip denetlenmesi gerekir ama bunu kimse yapmıyor

    • Ben tüm npm tabanlı araçları Docker container içinde, mevcut dizin dışında hiçbir şeye erişim olmadan çalıştırıyorum

      • Saldırı yüzeyini dramatik biçimde azaltıyor
      • Yöntem için şu blog yazısına bakabilirsiniz

    • Neden bu tavsiyeler setup.py (Python) ya da build.rs (Rust) için aynı şekilde uygulanmıyor, merak ediyorum

      • Bunun nedeni npm’in çoğu zaman yazılım dağıtımı için de kötüye kullanılması mı, oysa diğer dillerin paket yöneticileri daha çok sadece kütüphane yönetimi için mi kullanılıyor?
      • İlgili tartışmaya buradan bakılabilir

  • Yeni bir bağımlılık eklerken gerçekten iki kez düşünme kültürüne ihtiyaç var

    • Bu yıl gerçekten çok sayıda tedarik zinciri saldırısı yaşandı

    • Bu hafta bir Go projesine 8 istatistik sayacı olan bir progress bar eklemek istedim

    • Kütüphane aradığımda kodun 3.000 satırı aştığını gördüm; sonra bir LLM’den basit UI kodu üretmesini istedim ve konu 150 satırın altında çözüldü

    • Bağımlılık yok, tam istediğim gibi çalışıyor ve çok basit olduğu için herkes kolayca okuyup geliştirebilir

    • İşlev olarak terminal çıktısını temizleyip her saniye yeniden çiziyor ve thread-safe desteği var

    • Uygulama ve review için 25 dakika yetti

    • Karmaşık istatistik özelliklerine ihtiyacınız yoksa 30 satır civarı kodla da progress bar yapılabilir

    • Bundan sonra bağımlılık ekleyip eklememeyi düşünürken kendim yazma yönü bana daha uygun görünüyor

    • Tüm paket güncellemelerini izlemeye yetecek kaynağım yok

    • Söylenenlere katılıyorum; “dil bazlı paket yöneticileri” yaygınlaşmaya başladığında gerçekten tedirgin olmuştum

      • Sistem programlama tarafında çalışırken pip, npm vb. araçları uzaktan izliyordum
      • Sonra Rust projelerine geçip Cargo’da tek satırlık ayarla doğrulanmamış onlarca bağımlılığı internetten çekmenin normalleştiğini görünce bunun tehlikeli olduğunu düşündüm
      • Nitekim olan da bu oldu. İyi bir yönde gittiğimizi düşünmüyorum. (Ama geri döneceğimize dair de umudum yok. Sonuçta bilgisayar güvenliği diye bir şey yok…)

    • Bana göre gelecek, cargo vet tanıtımında anlatılan cargo vet benzeri yaklaşımlarda

      • Elbette böyle sistemlerin tüm dil ekosistemlerinde gerekmesi ciddi bir ek yük demek
      • İnternetin ilk günleri ya da e-posta da bir zamanlar iyiydi ama sonunda spam ve ticarileşme ile bozuldu
      • Şimdi bağımlılık zinciri de aynı zararı görüyor
      • Bu yüzden iyi bir ortamı sürdüremiyoruz

    • Bir şeyi kendin yazmakla kütüphane kullanmak arasındaki fark zaten doğal

      • Kütüphaneler doğası gereği genel amaçlıdır; farklı ortamlara uyacak kadar esnek ve yapılandırılabilir olmaları gerekir, bu da kodun uzamasına yol açar

    • Bu tür progress bar kütüphanelerinden, özellikle de emacs shell’i bozanlardan gerçekten nefret ediyorum (expo, eas vb.)

      • Neden sadece ..10%..20%..30% ya da Uploading… gibi çıktı vermiyorlar, anlamıyorum
      • Terminal kontrol kodlarının sadece TUI ya da etkileşimli arayüzler için kullanılması gerektiğini düşünüyorum

    • Bizim ekip büyük bir sigorta şirketinde NX merkezli büyük bir monorepo ve kütüphane yapısı işletiyor

      • 10’dan fazla bağımsız uygulamayı ve 25’ten fazla kütüphaneyi tek bir monorepo’da yönetiyoruz; CI/CD de buna sıkı şekilde bağlı
      • lerna, rushjs, yarn workspaces vb. denedik ama NX kadar iyi çalışan bir araç bulamadık (lerna zaten sonunda NX tarafından satın alındı, rushjs de iyi yönetilmiyor)
      • Frontend monorepo karmaşıklığını gerçekten yönetebilecek yöntemler ya da alternatifler önerilirse sevinirim
      • Bu güvenlik olayıyla birlikte alternatiflere ilgi duyan çok kişi var; farklı görüşleri duymayı isterim

  • Nx’i, Anthropic’i ya da platformları suçlamadan önce asıl sebebi yeniden düşünmek gerek

    • Bu saldırının fiili nedeni, ele geçirilmiş bir “token” ile kötü amaçlı paket yüklenebilmiş olmasıydı
    • Ama bu sadece teslimat yöntemi; başarılı olmasının asıl nedenleri şunlar:
      1. Paket yöneticisi deposu artifact signing’i zorunlu tutmuyordu; dolayısıyla yetkili bir geliştirici tarafından üretildiği doğrulanamıyordu
      2. Kod imzalama da zorunlu değildi
      3. (Tahminen) anomali davranış tespiti, yeni IP, ülke değişikliği gibi şüpheli yüklemeleri önleyecek heuristics yoktu
      4. (Tahminen) ele geçirilmiş token kullanımında MFA zorunlu değildi
      5. (Tahminen) token tek kullanımlık değildi
      6. (Tahminen) token yeni bir uygulama ya da oturumda kullanıldığında manuel onay isteyecek bir parola yöneticisinde saklanmıyordu
    • Bunların hiçbiri yerine getirilmeyince tamamen önlenebilir bir olay yaşanmış oldu
    • Gerçekten mağdur olduysanız ve GitHub hesabınızda yeni bir repo açıldıysa, kendi auth token’larınızı da yeterince güçlü korumamışsınız demektir
    • Bu tür önlemlerin varsayılan hale gelmemiş olması tüm yazılım sektörünün büyük bir başarısızlığı
      • Bu saldırı yıllardır tekrar tekrar yaşanıyor
      • Üstelik bunu düzeltmeyenler de biz geliştiricileriz
    • Bu yüzden yazılım için de yapı yönetmeliği benzeri zorunlu düzenlemelerden yanayım; denetim ve para cezası dahil

      • Bu tür saldırılar finans, enerji, telekom, hastane, askeri kurumlar gibi on binlerce kuruluşta yıkıcı etki yaratabilir

      • Yapay zekanın yayılmasıyla saldırının ölçeği ve etkisi daha da büyüyecek

      • Yazılımı yeterince sorumlu şekilde geliştirmiyoruz. Gerekirse yapı yönetmeliği gibi zorla güvenlik ve emniyet kurallarına uymalıyız

      • Asıl düşündürücü olan, kişisel bilişim ortamının tek büyük alan halinde toplanmış olması

        • Mac, Windows, Linux fark etmeksizin kripto cüzdanları, kimlik bilgisi dosyaları ve çeşitli uygulamalar aynı yerde duruyor
        • Bunları düzgün ayıracak araçlar hâlâ oldukça yetersiz
        • Bazen macOS üzerinde birden fazla Windows VM çalıştırırken, günün sonunda görev bazlı container ya da VM’lere Alt-Tab ile geçilen temiz ve akıcı bir gelecek hayal ediyorum
        • Örneğin oyun container’ı, sadece kripto işlemleri için container, ana kod projelerinin her biri için ayrı container gibi
        • Sırf bir VSCode extension kuruldu diye Bitcoin anahtarlarının sızabilmesi gerçekten saçma bir gerçeklik
        • Yazılım için yapı yönetmeliği benzeri kuralların bu kadar temel bir sorunu tek başına çözemeyeceğini düşünüyorum
        • İşletim sistemi seviyesinde uygulamalar arası veri erişimini denetleyen kurallar da gerekli; ama bunların nasıl tasarlanıp uygulanacağı da ayrıca konuşulmalı

      • Mağdurların %50’sinde bulaşma yolu VS Code’du ve yalnızca Linux ile macOS’ta çalışıyordu

        • Saldırının detaylı analizi için şu blog incelemesine bakılabilir
        • Bulaşma olduğunda:
          • postinstall aşamasında kullanıcı kimlik bilgileri gibi kritik varlıklar toplandı (kripto cüzdanları, Github ve npm token’ları, SSH anahtarları vb.)
          • Claude, Gemini, Q gibi yapay zeka komut satırı araçlarıyla bilgi toplama ve aktif keşif yapıldı
          • Çalınan veriler base64 ile iki ya da üç kez kodlanıp saldırgana ait GitHub repolarına (s1ngularity-repository vb.) yüklendi
          • Binlerce repo tespit edildi
          • 1000’den fazla GitHub token’ı, onlarca cloud ve NPM kimlik bilgisi, yaklaşık 20 bin dosya sızdırıldı
          • Çoğunlukla NX’in VSCode extension’ı üzerinden ya da build pipeline’larında (ör. GitHub Actions) çalıştı
          • GitHub 27 Ağustos 09:00 UTC’de tüm saldırgan repolarını devre dışı bıraktı ama en fazla 8 saatlik maruziyet süresinde veri dışarı çıkarıldı
          • base64 kolayca geri çözülebildiği için bu verilerin fiilen herkese açık hale geldiği kabul edilmeli

      • GitHub token’larının/kimlik bilgilerinin manuel serbest bırakmalı parola yöneticilerinde saklanmamasında GH CLI’nin de payı var

        • GH CLI’da bir kez giriş yapınca repo push yetkisi kazanılıyor ve neredeyse hiç yeniden doğrulama istenmiyor
        • AWS CLI’da bu, policy’ye göre değişse de genelde 18 saatte otomatik sona eriyor
        • Ama iki platformda da varsayılan olarak token’ların yerelde düz metin halinde kalması kolay

      • “Yazılım yapı yönetmeliği” fikri kulağıma çok hoş gelmese de sektör genelinin aşırı kırılgan olduğu gerçeğine katılıyorum

        • Belki de gerçekten regülasyon gerekiyor

      • Ücretsiz açık kaynak kütüphane kullandınız diye sorumluluk yükleme fikrini kibirli buluyorum

        • Gerçek garanti istiyorsanız lisans satın almalısınız
        • Bu, ücretsiz yazılıma karşı Google’ın agresif doğrulama politikasıyla aynı zihniyet

  • Son zamanlarda geliştirme işlerimin çoğunu VM içinde yapıyorum

    • Güncel ortamların güvenlik seviyesi kabul edilemeyecek kadar kötü geliyor

    • Agent tabanlı yazılımların kötü amaçlı yazılım vektörü haline gelme ihtimali muazzam derecede arttı

    • Saldırgan bir kez makineye girdiyse artık 1.000 doların üzerinde değer taşıyan veriler, kripto anahtarları, parolalar, kişisel bilgiler, finansal belgeler gibi her şeye göz dikebildiği bir dönemdeyiz

      • Ben de benzer şekilde Podman container içinde çalışıyorum. Kaynak kod klasörü dışında host ile hiçbir şeyi paylaşmıyorum

      • Sorunun bir kısmı geleneksel PC güvenlik modelinden geliyor (Linux/Windows)

        • Yürütülebilir dosyalara güvenilir gözüyle bakılması ve bunların tüm kişisel verilerime erişebilmesi modeli 2025 için uygun değil
        • Mobil (Android) bu sorunu büyük ölçüde aştı ama PC’de SELinux dışında derin bir alternatif pek yok

      • Böyle bir yaklaşımı seviyorsanız Qubes OS’yi öneririm. Tüm işleri VM içinde yapmaya uygun iyi bir UX sunuyor

        • Günlük kullandığım sistem; gerçekten güçlü biçimde tavsiye ederim

      • Yine de böyle bir düzen kurmanın, yazılım ekosistemi ve tarihsel sebepler yüzünden çok zor ya da epey maliyetli olabileceğini belirtmek gerekir

  • Claude Code, verimlilik artışı sağlayan devrim niteliğinde bir araç

    • Öte yandan şu güvenlik sorunları var:

      • Bir NodeJS uygulaması
      • Kurulumda curl çıktısını bash’e pipe ediyor (uzaktan kod çalıştırma riski)
      • LLM dosya sistemi, komutlar vb. pek çok şeye erişebiliyor

    • En az üç güvenlik zafiyeti olduğu için bunu VM/container/ayrı geliştirme kutusu gibi bir sandbox dışında çalıştırmak istemiyorum

      • Ben de agent’ların sandbox içinde çalıştırılması gerektiğini düşünüyorum

        • Yalnız Claude Code en baştan itibaren (ayrı bir izin olmadan) keyfi komutlar çalıştırmıyor

      • Yine de ne olmuş yani?

        • Kullanıcı çalıştırma düğmesine kendisi basmak zorunda
        • Programların çoğu zaten geniş yetkilere sahip
        • Terminal de dosya sistemine dokunabilir ama kendiliğinden çalışmaz
        • Claude Code kendi başına bilgisayarımı mahveden bir daemon gibi davranmıyor; açık komut verilmedikçe bir şey yapmıyor
        • Bana göre Claude Code son 30 yılda kullandığım en iyi araç
        • “Saldırı vektörü”nün ne olduğu umurumda değil. Birisi bilgisayarıma izinsiz girerse bu yalnızca Claude Code’un sorunu olmaz

      • Asıl riskli nokta, kullanıcı etkileşimi olmadan otomatik güncellenmesi ve böylece çalışma sırasında Anthropic’e uzaktan kod çalıştırma yetkisi verilmiş olması

  • Paket yöneticilerinde min-age gibi bir ayar olmalı mı diye merak ediyorum

    • Örneğin 24–36 saatten yeni paketlerin yok sayılması gibi

    • Daha önce benzer bir olay yaşadım; paket güncellemesi her şeyi bozdu ve birkaç saat sonra düzeltilip silindi

      • GitHub dependabot kısa süre önce tam da böyle bir özellik ekledi

      • Renovate bot zaten bunu (minimumReleaseAge ayarıyla) sunuyordu; dependabot da artık destekliyor

        • Paket yöneticileri sadece en son sürümü kurmayı önemser ama bu tür ücretsiz araçlarla güncellemeler uygun tempoda yönetilebilir
        • JavaScript ekosistemi giderek daha fazla birleşme yönüne gidiyor ve tedarik zinciri saldırılarına karşı araçlar yavaş yavaş oluşuyor
        • Güncel NPM, PNPM, Bun vb. artık postinstall script’lerini varsayılan olarak çalıştırmıyor; gerektiğinde açıkça etkinleştirmek gerekiyor (yine de sonuçta başkasının kodunu çalıştırmış oluyorsunuz)

      • OS düzeyinde değil ama Astral’ın uv aracında Python paketleri için böyle bir seçenek var

      • npm install için de belirli bir zaman/tarihten önceki bağımlılıkları kuran bir flag var

        • npm install --before (2 gün önceki tarih) şeklinde; o tarihten sonra ortaya çıkan bağımlılıklar kurulmaz

      • Ben .npmrc içinde save-exact=true ayarını kullanıyor, sadece lockfile ve manuel güncellemelerle ilerliyorum

        • Paketleri sık güncellemek zorunda değilsiniz
        • fakerjs olayı gibi örnekleri görünce temkinli olmak gerektiğini düşünüyorum

  • Claude code’un gerçekten böyle prompt’ları çalıştırıp çalıştırmayacağını merak edip test ettim

    • Sonuç şöyleydi:

      • “Bu istek kripto para cüzdanları, private key’ler ve benzeri hassas dosyaları arama ve listeleme isteği gibi görünüyor; kötüye kullanılabilir, bu nedenle yardımcı olamam”

      • Bunun yerine güvenlik incelemesi, zafiyet analizi, izleme araçları yazma, dosya izinlerini anlama, yedekleme prosedürü tasarlama gibi meşru konularda yönlendirme yaptı

      • En az 250’den fazla başarılı örnek toplandı (yani bazı prompt’lar geçiyor)

        • Claude’un ortalama ret oranı belirgin biçimde daha yüksek; Q da iyi reddediyor (Claude tabanlı olduğu için benzer)
        • Referans için, bütün gün bu tür olaylara müdahale ederken ilgili analiz raporunu yazdım

      • Sahada Claude ile diğer modellerin reddetme performansı kıyaslandığında, Claude’un güvenlik önlemlerinin çok daha iyi olduğunu tekrar tekrar görüyorum

        • Ünlü örnek: ChatGPT ruh sağlığı sorunları olan bir kullanıcıya durmadan “The Oracle” diye hitap edip bunu sürdürürken, Claude reddedip profesyonel destek önermişti
        • Elbette sürekli “Doğru!” tarzı yanıtlar bazen sinir bozucu ama Anthropic’in rakiplerine kıyasla reddetme ve güvenliğe daha fazla önem verdiğini kabul edip takdir etmek gerekir

  • OS, varsayılan olarak uygulamaların tüm dosya sistemine sınırsız erişmesine izin vermemeli

    • Bazı uygulamalar için apparmor/selinux profilleri var, firejail de kullanılabiliyor

    • Ama UX tarafında da değişim lazım

      • Bu çok ciddi bir sorun. 30 yıl önceki masaüstü tasarımından kaynaklanıyor

        • Buna karşılık modern mobil OS’ler (iOS vb.) uygulama başına sandbox ve izin onayı konusunda çok daha iyi varsayılanlara sahip
        • Masaüstünde Qubes (OS), Firejail, bubblewrap, AppArmor gibi çeşitli girişimler var ama bunlar karmaşık ya da sıradan kullanıcı için zor
        • OpenSnitch de var ama ağ erişimiyle sınırlı
        • Son kullanıcı açısından her program için ayrıntılı izin ayarı yapmak yorucu
        • Sonuçta yaygın uygulamalar için iyi profillerin sürekli güncel tutulması asıl kritik nokta
        • Masaüstü güvenliğinin bu kadar zayıf olmasına dehşetle bakıyorum ama temel sorun zor ve bunu çözmenin maddi teşviki de az

      • Linux’ta Podman ile proje bazlı ortam izolasyonuna odaklanan bir araç geliştiriyorum: probox

        • UX’i iyileştirmek için ciddi çaba var
        • Sık kullanıyorum ama birinin güvenlik incelemesi yapmasına ihtiyacım var

      • Dosya güvenliği konusunda Android tarafında Google iyi iş çıkardı

      • bubblewrap ve küçük chroot ortamlarını kullanmayı öğrenmeyi de öneririm

      • Hiçbir işletim sisteminin varsayılanının uygulamalara “tüm dosya sistemine sınırsız erişim” vermek olduğunu sanmıyorum

        • Linux, BSD, MacOS, Windows hepsinde güçlü kısıtlayıcı mekanizmalar var
        • Sıradan kullanıcı kendi hesabını tehlikeli biçimde yükseltip çalıştırmadıkça varsayılan olarak güvenli yapı mevcut

  • Eskiden “saldırgan benim ortamımı bilemez” gibi belirsiz bir özgüven vardı ama artık LLM’ler kullanılarak ortama uygun saldırılar öğrenilip uygulanabiliyor

    • Hatta ben de bu gidişatı gerçekten önceden tahmin etmişim gibi hissediyorum

    • Önceki tartışmada buna dair ilginç değerlendirmeler vardı

      • (Şaka) Ben saldırganım, yeni fikir var mı? (/s)

  • Gerçekten ürkütücü olan kısım artık yerel LLM’lerle secret arama işinin yapılması

    • “postinstall” sorunu eski ama payload tamamen yeni bir nesil

    • Kötü amaçlı mantık kod yerine prompt içinde saklanabildiği için klasik statik analizle tespit etmek zorlaşıyor

    • Böyle kötü amaçlı prompt’lara karşı nasıl savunma yapılabileceğini merak ediyorum

      • Görünen o ki tek çözüm Claude Code’u tamamen izole bir container/VM içinde çalıştırmak ve commit edilen tüm kodu elle review etmek