GitHub'da bulunan enfekte depo sayısı 100 bini aştı

 (apiiro.com)
1 puan yazan GN⁺ 2024-03-01 | 1 yorum | WhatsApp'ta paylaş
  • 2023 ortasında başlayan depo karışıklığı (repo confusion) kampanyası yeniden yayılırken, GitHub'da benzer kötü amaçlı yükler içeren 100 binden fazla depo tespit edildi
  • Saldırganlar, meşru depolara benzeyen kötü amaçlı kopyalar oluşturarak geliştiricilerin hata yapmasını hedefliyor; klonlama, yükleyici ekleme, yeniden yükleme, toplu fork ve gizli tanıtımı birleştiriyor
  • Kötü amaçlı depo çalıştırıldığında 7 aşamalı obfuscation sonrasında Python kodu ve ikili dosyalar indiriliyor, oturum açma bilgileri, tarayıcı parolaları, çerezler ve diğer hassas veriler çalınıyor
  • GitHub fork'ların çoğunu otomatik silse de tespitten kaçan depolar ve elle yüklenen kopyalar kalıyor; toplamın yalnızca %1'i hayatta kalsa bile binlerce kötü amaçlı depo varlığını sürdürüyor
  • Saldırı akışı, PyPI kötü amaçlı paketlerinden GitHub depolarına kayarken, paket yöneticilerinin dışındaki yazılım tedarik zinciri de doğrudan saldırı yüzeyi haline geliyor

Depo karışıklığı saldırısı nasıl işliyor

  • Depo karışıklığı, kullanıcının meşru depo yerine kötü amaçlı bir depoyu indirmesini sağlaması bakımından dependency confusion'a benziyor
  • Fark, istismar noktasında ortaya çıkıyor
    • dependency confusion, paket yöneticisinin çalışma biçimini kullanır
    • depo karışıklığı, insanın benzer görünen depoyu yanlış seçmesine dayanır
  • Bu kampanya, GitHub'a çok sayıda kötü amaçlı depo yayarak enfeksiyon olasılığını artırıyor
    • TwitterFollowBot, WhatsappBOT, discord-boost-tool, Twitch-Follow-Bot gibi mevcut depoları kopyalıyor
    • Kopyalara malware loader ekliyor
    • Aynı adla GitHub'a yeniden yüklüyor
    • Her depoyu otomatik olarak binlerce kez fork'luyor
    • Forumlar ve Discord gibi yerlerde gizlice tanıtıyor

Kötü amaçlı depo çalıştırıldıktan sonraki akış

  • Kullanıcı kötü amaçlı depoyu kullandığında gizli yük 7 aşamalı obfuscation çözme sürecinden geçiyor
  • Ardından kötü amaçlı Python kodu ve ikili yürütülebilir dosyalar getiriliyor
  • Kötü amaçlı kod, büyük ölçüde BlackCap-Grabber'ın değiştirilmiş bir sürümüne dayanıyor
  • Toplanan veriler arasında çeşitli uygulamaların oturum açma bilgileri, tarayıcı parolaları ve çerezleri ile diğer gizli veriler bulunuyor
  • Çalınan veriler saldırganın C&C (command-and-control) sunucusuna gönderiliyor ve ek kötü amaçlı faaliyetler devam ediyor
  • İlgili kod analizi Trend Micro'nun technical analysis yazısında görülebilir

GitHub'ın otomatik silmeleri ve geride kalan depolar

  • GitHub otomasyonu tespit ederek fork'lanan depoların çoğunu hızla kaldırıyor
  • Ancak otomasyon tespiti birçok depoyu kaçırıyor ve elle yüklenen depolar yaşamaya devam ediyor
  • Saldırı zinciri büyük ölçüde otomatikleştirildiği için yalnızca %1'i kalsa bile bu, binlerce kötü amaçlı depo anlamına geliyor
  • GitHub'da 🔥 2024 language:python araması yaparak şu anda yayılan bazı depolar görülebilir
  • Silinmiş depolar da dahil edildiğinde toplam ölçek milyonlara ulaşıyor
    • Silme işlemi genellikle yüklemeden birkaç saat sonra gerçekleştiği için belgelemesi zor oluyor
    • Birçok özgün depo yerinde kalıyor ve silmeler esas olarak fork bomb örneklerini hedef alıyor
    • Örneğin Mattia69 depo listesi özet bölümünde binlerce fork gösterirken, fork ayrıntıları kısmında bunlar görünmüyor
  • Bazı kullanıcılar kötü amaçlı depoları bilmeden fork'layarak ikincil sosyal mühendislik ağ etkisi de yaratıyor

Kampanyanın ilerleyiş zaman çizelgesi

  • Mayıs 2023: Phylum, PyPI'ye yüklenen kötü amaçlı paketleri raporladı
    • Bu paketler mevcut yükün ilk bölümlerini içeriyordu
    • chatgpt-api gibi popüler GitHub depolarının fork'larına yerleştirilen os.system("pip install package") çağrılarıyla yayıldılar
  • Temmuz-Ağustos 2023: GitHub'a çeşitli kötü amaçlı depolar yüklendi ve PyPI paketlerini çekmek yerine yükü doğrudan dağıttılar
    • Bu değişim, PyPI'nin kötü amaçlı paketleri kaldırması ve güvenlik topluluğunun ilgisinin artmasından sonra geldi
    • Trend Micro'dan Aliakbar Zahravi ve Peter Girnus, teknik analizi yayımladı
  • Kasım 2023-günümüz: Benzer kötü amaçlı yükler içeren 100 binden fazla depo tespit edildi ve sayı artmaya devam ediyor
  • Bu yöntemin saldırganlar için neden avantajlı olduğu açık
    • GitHub'ın ölçeği çok büyük olduğu için yüksek sayıdaki örnekler bile göreli olarak küçük kalıyor ve tespit edilmesi zorlaşıyor
    • Önceki durumun aksine paket yöneticisi devrede olmadığı için açık kötü amaçlı paket adları bir gösterge olarak kalmıyor
    • Hedef depolar küçük niş alanlarda ve düşük popülerlikte olduğundan, geliştiricilerin kötü amaçlı taklit depoları yanlışlıkla klonlaması kolaylaşıyor

Paket yöneticilerinden SCM'e kayış

  • PyPI kötü amaçlı paketlerinden GitHub kötü amaçlı depolarına geçiş, çeşitli paket yöneticileri ve SCM platformlarında gözlenen eğilimle örtüşüyor
  • Güvenlik topluluğu paket yöneticilerine daha fazla odaklandıkça, saldırı yolu başka yerlere kaymış görünüyor
  • GitHub ve benzeri platformlarda hesap ve depo otomatik oluşturmak kolay; ayrıca kullanışlı API'ler ve aşılması nispeten kolay gevşek rate limit'ler sunuluyor
  • Sayısız depo arasında saklanabildiği için SCM, yazılım tedarik zincirini gizlice enfekte etmek için uygun bir hedef haline geliyor
  • dependency confusion kampanyaları, paket kayıtlarındaki kötü amaçlı kodlar ve SCM üzerinden kötü amaçlı kod yayılması; çok sayıda araç ve güvenlik mekanizmasına rağmen yazılım tedarik zinciri güvenliğinin zayıf kaldığını gösteriyor

Enfeksiyonun doğrulanması için göstergeler

  • Python kodunda aşağıdaki kalıplar aranmalı ve eşleşen öğeler incelenmeli
    • exec(Fernet
    • exec(requests
    • exec(__import
    • exec(bytes
    • exec("""\nimport
    • exec(compile
    • __import__("builtins").exec(
  • Yerelde sosyal platform otomasyonu, bot veya oyunla ilgili depolar olup olmadığı kontrol edilmeli ve kaldırılmalı
  • Mutlaka kullanılmaları gerekiyorsa yeniden kurulmalı; ancak kaynak dikkatle doğrulanmalı veya sandbox içinde çalıştırılmalı
  • Bu tür depoları klonlamış olma ihtimali varsa aşağıdaki çerez, kimlik bilgisi ve anahtarların ele geçirildiği varsayılarak hareket edilmeli
    • Tarayıcı: finansal hizmetler, e-posta servisleri, kripto para servisleri, Amazon, eBay, AliExpress, Facebook, Instagram, Twitter, Youtube, Discord, TikTok, Telegram, Twitch, Steam, Yahoo, ExpressVPN, Spotify, yayın platformları
    • Uygulamalar: Exodus, Atomic Wallet, Guarda, Coinomi, Ethereum
  • Dosya checksum'larının tam listesi pratikte yönetilmesi zor olsa da bazı ortak öğeler VirusTotal graph üzerinde görülebilir
  • Cloudflare, bildirim aldıktan sonra tespit edilen kötü amaçlı adreslerin DNS kayıtlarını devre dışı bıraktı

Savunma ve müdahale

  • GitHub bilgilendirildi ve kötü amaçlı depoların çoğunu sildi, ancak kampanya sürüyor
  • Tedarik zincirine kötü amaçlı kod enjekte etmeye yönelik saldırılar giderek daha yaygın hale geliyor
  • Sistem ve ağ düzeyinde malware yakalayan pek çok çözüm var, ancak tedarik zinciri saldırganlar için hâlâ büyük ve kârlı bir saldırı yüzeyi
  • Kötü amaçlı bir depo tespit edilirse, bu kampanyanın parçası olup olmadığına bakılmaksızın GitHub'ın abuse or spam report kanalı üzerinden bildirilebilir
  • Apiiro, bağlı kod tabanlarını izleyen bir kötü amaçlı kod tespit sistemi kurdu
    • LLM tabanlı kod analizi
    • Kodun tam yürütme akışı grafiğine ayrıştırılması
    • Heuristik motor
    • Dinamik çözme, şifre çözme ve obfuscation kaldırma
  • Enjekte edilmiş kötü amaçlı yükler izlenmezse kurum güvenliği; geliştiricilerin neredeyse aynı görünen yanlış depoyu seçmemesine, CI/CD yapılandırmalarında hiç hata olmamasına ve üçüncü taraf kodun %100 güvenli olmasına bağımlı hale gelir
  • Yaygın zafiyet tespiti ve toplamanın ötesinde, yeni nesil yazılım tedarik zinciri ve uygulama risklerini ortaya çıkaran bir yaklaşıma ihtiyaç var

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-01
Hacker News yorumları

  • Genel olarak herkese açık depolardan veya harici kaynaklardan alınan kodlara dikkat edilmesi ve bağımlılık ağacının doğrulanması gerektiği uyarısının ötesinde, herkese açık depolarda büyük miktarda kötü amaçlı kod varsa bunun bu içeriklerle eğitilmiş LLM'ler ve otomasyon araçları üzerinde nasıl bir etkisi olacağını merak ediyorum
    Copilot gibi araçlar uzun kod yanıtları üretirken kötü amaçlı bölümlerin tesadüfen araya karışma ihtimali de var gibi görünüyor
    Basit enjeksiyon açıkları gibi şeyler zaten sıkça görülüyor

    • LLM çıktısına tesadüfen bir arka kapı girmesinden ziyade, istihbarat kurumlarının LLM çıktısına arka kapı yerleştirmesi daha çok endişe verici
      Şu an olmayabilir ama birkaç yıl içinde gayet mümkün görünüyor
    • LLM'ler yalnızca girdi verisindeki açık kodları kopyalayıp yapıştırmakla kalmayacak, kendi yeni açıklarını da üretecek gibi görünüyor
      Yapay zeka doğruluk konusunda hiçbir garanti vermiyor
    • Hugging Face'in safetensors dönüşüm botunu ele geçirmeye dair bir LLM konusunu az önce paylaştım: https://news.ycombinator.com/item?id=39549482
      Saldırganın Hugging Face Safetensors dönüşüm alanı ile bağlantılı hizmet botunu ele geçirebildiğini gösterdi; bu, ekosistem içindeki güvenli olmayan makine öğrenimi modellerini daha güvenli sürümlere dönüştüren popüler bir hizmet
    • Risk gerçek, ancak inceleme yapmadan bir iş arkadaşının PR'ını kabul ettiğinizde bir yerlerden kopyalanmış açıklı kodun içeri girmesi riskine benziyor
      LLM kullanacaksanız kod incelemesine daha fazla emek ayırmanız gerekir ve bence bu ödün buna değer
    • Bu kampanyada tespit edilen örnek sayısı o kadar fazla ki risk sanılandan daha gerçekçi
      Yine de bunun gerçek bir olaya dönüşmesi için başlıca iki engel var: üreticinin böyle kodlardan kaçınması yönünde iç talimat almış olması ve LLM'nin doğası gereği gerçek saldırganın adresini birebir tekrar etme olasılığının düşük olması
      Buna rağmen bind shell, hizmet reddi ve sahadan veri sızdırma gibi çeşitli saldırı vektörleri hâlâ mevcut

  • GitHub, Usenet'in başarısız olduğu biçime benzer şekilde başarısız oluyor
    Herkes depo oluşturabiliyor ve resmi depolarla spam depoları ayırt eden bir şey yok
    Amazon, “her şeyin mağazası” olmayı hedeflerken “her şeyin %90'ı çöp” durumuna çarpıp çoğu çöp olan bir mağazaya dönüştüğü gibi, GitHub da ürününün “herkes için depo” mu yoksa “güvenilir kod” mu olduğuna karar vermeli
    Örneğin resmi PG JDBC için bile bir spamcının taklit edemeyeceği bir unsur yok gibi görünüyor; bunun enfekte bir depo olmadığını nasıl güvenle söyleyebiliriz: https://github.com/pgjdbc

    • GitHub, şirketi 16 yıl önce ilk kurduğunda zaten herkes için depo yolunu seçmiş gibi görünüyor
    • Java kütüphaneleri söz konusuysa genelde GitHub yerine Maven Central üzerinden indirme yapılır
      Sonatype, groupId içinde kullanılan ters alan adının sahipliğinin kanıtlanmasını ister; bu örnekte org.postgresql
      Yöntem burada anlatılıyor: https://central.sonatype.org/faq/how-to-set-txt-record/
      Daha da emin olmak isterseniz Maven Central'da yayımlanan tüm çıktılar imzalandığı için GPG imzasını da doğrulayabilirsiniz, ancak bunun dezavantajı Postgres'in imzada kullandığı anahtarı Sonatype'ten bağımsız bir kanaldan edinmeniz gerekmesidir
      PG için hızlı bir aramada bile anahtarı bulamadım
    • Bu sayının ne kadar küçük olduğu tam olarak hissedilmiyor gibi
      GitHub'da yaklaşık 500 milyon depo var, yani bu oran aslında oldukça iyi
    • 100 binden fazla enfekte depo iyi değil, ama bu GitHub'ın başarısız olduğu anlamına da gelmiyor
      Böyle depoları alıp kullanacak bir geliştirici, GitHub'da bunlar olmasa bile güvensiz ürünler yapmak için pek çok başka yol bulabilir
    • Alan adı sahipliğini kanıtlarsanız organizasyon sayfasında doğrulanmış rozet alabiliyorsunuz ve bu güveni epey artırabiliyor
      Örnek verilen organizasyonun bunu yapmamış olduğu anlaşılıyor

  • Tedarik zinciri sorunu gerçekten tam bir baş belası
    npm sürümlerini doğrudan hedef almıyorlar, ancak BrowserBox adlı hafif sanallaştırılmış web tarayıcısı projesini izlemek için npm sürümleri oluşturup socket.dev kullanıyorum
    Bu proje de tüm alt bağımlılıklarıyla birlikte yaklaşık 800 paket içeriyor ve yalnızca 19 üst seviye bağımlılık kullanmasına rağmen, toplam yığın ölçeğinde bakınca nispeten hafif sayılır
    Şimdi bu 800 bağımlılığın tamamını npm'de @browserbox namespace'i altında snapshot olarak saklayıp, tespit edilen açıkları izleyerek yamamayı düşünüyorum
    Kulağa çılgınca geliyor ama durum şu anda böyle ve en azından bunu yaparsam Node/JS tarafındaki tedarik zinciri açıklarını şirketin güvenlik seviyesi içinde doğrudan garanti edebilirim
    https://socket.dev
    https://github.com/BrowserBox/BrowserBox

    • npm'de aynı işlevlerin ne kadar bulunduğunu bilmiyorum ama crates.io ve cargo tarafında, pipeline içinde bağımlılık ağacındaki CVE'leri kontrol eden cargo audit ve cargo deny gibi araçlar var
      Kilit dosyası tüm ağacın sha256 değerini tuttuğu için, depo ele geçirilse bile değişiklikleri önlemek amacıyla ayrıca mirror almaya gerek yok
      En güncel sürüm yerine birkaç ay geriden gelen bir sürüme sabitlemek, yeni CVE'lerden kaçınırken aynı anda büyük bir düzeltme yapmak zorunda kalacak kadar eski sürümlere saplanmamak arasında makul bir denge gibi görünüyor
      İndirme sayısı, benzer amaca sahip üst seviye bağımlılıklarla karşılaştırıldığında fena olmayan bir ölçü gibi duruyor, ama bu öznel bir değerlendirme
      Austral, lineer tipler ile bağımlılıklara ayrıntılı yetkiler veriyor
      Örneğin bir grafik kütüphanesinin dosya G/Ç'ye ihtiyacı yoktur ve bir ağ aktarım kütüphanesinin mikrofona erişime ihtiyacı yoktur
      Bu yalnızca bir hafifletme önlemi ama başka dillerde de görmek isterim
    • “Yaklaşık 800 bağımlılık sadece” ifadesi biraz ürkütücü
      Yaklaşık 10 yıl önce .NET'ten Java'ya geçtikten sonra bağımlılık cehennemine harcadığım zamanın ciddi biçimde arttığını fark edip şaşırmıştım; bugünlerde de hem Java hem Python projelerinde açık güncellemeleri ve bağımlılık sorunlarına giden zaman korkutucu derecede fazla
      Bunun .NET'te daha az sorun olmasının nedeni muhtemelen otomatik paket yönetiminin nispeten geç gelmesi ve NuGet'in de daha genç olmasıydı; o dönemde birçok proje bunu henüz benimsememişti ve devasa geçişli bağımlılık ağaçlarından kaçınma kültürü daha güçlüydü
      Boeing'in son sorunları da benzer görünüyor
      Son birkaç on yılda üretimin daha büyük kısmı dış tedarikçilere verildi ve maliyet optimizasyonuna odaklanıldıkça tedarik zinciri yönetimi giderek zorlaştı; büyük resimde bu, modern yazılım mühendisliğinin tedarik zinciri kültürüne benziyor
      Tedarik zinciri güvenliği nedeniyle paket yöneticilerini yasaklayan bir finans şirketinde çalıştığımda, bağımlılık yönetimi en az can sıkıcıydı ve kalite sorunları da en azdı
      Siz açıkça değiştirmediğiniz sürece asla değişmeyen kodun avantajları var
      Başkalarının paket olarak kullanacağı kısımların çoğunu da doğrudan kendimiz yazıyorduk; yalnızca ihtiyaç duyulanı yapıp daha yüksek kod standartları uygulayınca anlamak, debug etmek ve düzeltmek daha kolay oluyordu
      İlk yazım maliyeti tek seferliktir ve iyi amorti edilir, ama herkes için her şeyi yapmaya çalışan kodla uğraşmanın tekrar eden maliyeti uzun vadede daha büyüktür ve genelde birikir
      Rich Hickey'nin “Simple Made Easy” konuşması bunu iyi anlatıyordu; basit olmakla kolay olmak aynı şey değil ve basit seçenekler başlangıçta daha zor görünse de ikinci dereceden etkiler biriktikçe uzun vadede daha kolay hale geliyor

  • Benzer depoları tesadüfen görünce bunu zaten fark etmiştim
    Zaten herhangi bir deponun kodunu çalıştırmıyorum ama artık depo ve sahibi güvenilir görünse bile sandbox VM açıyorum
    Bugünün geliştiricisi için iş, hobi ve kişisel kullanımın en az üç ayrı ortamda net biçimde ayrılması gerekiyor gibi görünüyor

    • Geliştiricilerin iş, hobi ve kişisel ortamlarını ayırması gerektiği düşüncesi bile, dijital yaşamın karmaşıklığının uzun vadede sürdürülebilir olup olmayacağını sorgulatacak kadar arttığını gösteriyor
    • Her geçen yıl Qubes daha mantıklı bir seçim gibi görünüyor
    • Ben de artık bunu yalnızca potansiyel zararlı yazılımlar yüzünden yapmıyorum
      Kötü niyetli olmasa bile tasarım olarak gevşek ya da aptalca yazılmış projeler var
      Yakın zamanda çalıştırdığım bir program, ben hiçbir şey istemeden ~/.bashrc dosyama 3 satır ekledi; bunu ancak günler sonra fark ettim
      Bir geliştiricinin bunu nasıl iyi bir fikir olarak görebildiğini anlayamıyorum; bu yüzden artık dışarıdan gelen kodu her çalıştırdığımda sandbox kullanıyorum
    • Her şeyin varsayılan olarak VM içinde çalıştığı Qubes OS kullanmak için iyi bir sebep gibi geliyor
      Benim günlük kullandığım OS bu
    • İş ve kişisel ortamları karıştırmamak zaten en temel kural değil mi?
      Buna izin veren işverenler gerçekten var mı?

  • İşte bu tür sorunlardan kaçınmak için iş yerinde hangi araçları kullandıklarını ve mevcut kurulumlarından memnun olup olmadıklarını merak ediyorum
    Oldukça küçük bir ekiple haftalık indirme sayısı yüksek bir SDK geliştiriyoruz; snyk, aikido.dev, renovate tabanlı çözümler gibi seçenekleri değerlendirdik ama bunların bu tür sorunlara yardımcı olup olmadığı net değil
    Ekip hâlâ küçük olduğu için snyk gibi yanlış pozitif oranı yüksek araçlarla uğraşmak da yük

    • GitHub deposunu doğrudan kullanmak yerine NuGet, PyPI, npm gibi genel paket depolarındaki herkese açık paketleri kullanıyor ve Sonatype Repository ile Firewall'u bizimle paket depoları arasına proxy olarak koyuyoruz
      Sonatype tüm paketleri analiz edip çeşitli metadata ekliyor ve Firewall'da kullanılabilecek politikalar tanımlayarak geri kalanını filtreliyor
      Yalnızca herkese açık bağımlılıklar için geçerli ama bunu birkaç yıldır kullanıyoruz ve oldukça iyi çalışıyor
      Şimdiye kadar kötü amaçlı yazılım sorunu yaşamadık; bilinen zafiyetleri olan paketler kod tabanına giremiyor ve kullanmakta olduğumuz bir pakette zafiyet bulunursa bildirim alıyoruz
    • İş yerinde Semgrep Supply Chain kullanıyoruz ve oldukça memnunuz
      Tespit edilen tedarik zinciri zafiyetlerini ulaşılabilir, ulaşılamaz ve belirsiz diye ayırması sınıflandırmayı çok kolaylaştırdı ve yeni zafiyetleri değerlendirme süresini büyük ölçüde azalttı
    • Bu alt başlıkta kötü amaçlı yazılım ile zafiyetin sık sık karıştırıldığını düşünüyorum
      Bahsedilen satıcılar kötü amaçlı kodu değil, yalnızca zafiyetleri tespit ediyor
      Zafiyet tespitinde iyi olsalar bile, kod tabanına yerleştirilmiş kötü amaçlı yazılımlara karşı hâlâ koruma sağlamıyorlar
    • Açıkça kötü amaçlı olan paketler, sahipsiz bırakılmış paketler, typosquatting paketleri gibi riskli PyPI/NPM/Ruby/PHP/Maven/Rust paketlerini tespit eden açık kaynak araç Packj üzerinde çalışıyorum
      Statik, dinamik ve metadata analizi yapıyor; shell çalıştırma, SSH anahtarı kullanımı, ağ iletişimi, decode+eval kullanımı gibi 40'tan fazla özelliği denetleyerek riskli paketleri işaretliyor
      https://github.com/ossillate-inc/packj
    • Trivy'ye bakmaya değer
      Şimdiye kadar oldukça iyi çalıştı
      https://trivy.dev/

  • curl ile shell kurulum betiği indirip bunu sudo ile çalıştırma pratiğinin yakında sona erip ermeyeceğini merak ediyorum
    “Yazılımımızı kurmak için curl [https://somesite/install.sh](<https://somesite/install.sh>;)' | sudo sh çalıştırın” türü yöntemler, makalede bahsedilen enfekte kodla fazlasıyla uyumlu görünüyor

    • Bu araştırmanın yazarı olarak bunu doğrulayabilirim
      Sistemimiz her hafta bahsedilen kalıba uyan yaklaşık 100 örnek listeliyor ve bunların yaklaşık %3'ü kötü amaçlı
      Bu pratiğin sona erdiğini görmek isterim
    • Ne yazık ki npm i de aynı yetkilere sahip
      Şu an yaygın bağımlılık indirme araçları arasında kurulum veya derleme aşamasında düşmanca kod çalıştırmayan tek örneğin go get olduğunu biliyorum
      En azından patlamanın etkisini sınırlamak için sandbox içinde çalışmaya yönelik daha iyi araçlara ihtiyacımız var
      ChromeOS'taki “sanal makinenin ana masaüstünde Wayland pencereleri açabilmesi” yaklaşımı temiz görünüyor ama en son baktığımda o kod pek temiz ya da yeniden kullanılabilir değildi
    • Bu tür örneklerde example.com kullanmak daha iyi olur
      Bu amaç için ayrılmış bir alan adıdır: https://www.rfc-editor.org/rfc/rfc2606.html#section-3
    • Bunun, daha gerçekçi alternatifler olan “dağıtım için bir depo ekleyip ona güvenin”, “.deb/.rpm/kurulum programını indirin” ya da en kötü ihtimalle “yayıncı yerine üçüncü bir tarafın paketlediğine güvenin” seçeneklerinden belirgin biçimde daha kötü olduğu da söylenemez

  • npm'de --ignore-scripts ile kötü amaçlı kod çalıştırmayı hafifletmek mümkün
    https://blog.uirig.com/getting-rid-of-npm-scripts

    • Buna karşılık indirilen kötü amaçlı kod üretim ortamında çalıştırılabilir
      Şanslıysanız CI'da anormal davranış gösterip yakalanabilir
      Gerçek çözüm, https://github.com/crev-dev/cargo-crev gibi bir itibar sistemi, ama ne yazık ki neredeyse hiç kullanılmıyor
    • Güvenlik açısından bunun varsayılan olması gerekir
      Makefile gerektiğine dair yorum da dikkate değer

  • Bu tür haberler gelmeye devam ettikçe son birkaç aydır geliştirme ortamı güvenliğini yavaş yavaş iyileştiriyorum
    Geliştirmede VSCode dev containers kullanıyorum: https://code.visualstudio.com/docs/devcontainers/create-dev-...
    Bir kez kurduktan sonra Docker bilgisi çok fazla olmasa da kullanması kolay; web/konsol uygulamalarını çalıştırmak için iyi, ama Flutter ya da Electron gibi şeylerde zorlandım
    Küçük projelerde GitHub Codespaces'e de alıştım: https://github.com/codespaces
    Eskiden mülakatta basit bir Node projesini düzenlemeye yönelik canlı kodlama yapmıştım; bugün olsa böyle bir durumda mutlaka container ya da Codespaces kullanırdım: https://www.welivesecurity.com/en/eset-research/lazarus-luri...
    npm, Node ve Docker en iyi uygulamaları için OWASP yönergelerini düzenli okuyorum; Docker tarafında da mümkün olduğunca küçük image'lar ve açık image tag'leri kullanmak gibi pratikleri uyguluyorum: https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker...
    npm/python paketlerinde kurmadan önce socket.dev üzerinden ortam değişkeni erişimi, ağ çağrıları, tedarik zinciri saldırıları ve yakın dönemdeki kod sahipliği değişikliklerini kontrol ediyorum; ayrıca OWASP'ın önerdiği gibi postinstall script'lerini global olarak devre dışı da bırakabilirsiniz: https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_...

  • 1 yıldan bile yeni bir örnekte Truva atı virüsü içeren bir depo vardı: https://github.com/orgs/community/discussions/63603

    • Depo parola hırsızı olduğunu iddia etmişti; indirip açtığınızda kişisel verilerinizi ve dosyalarınızı çaldıysa ortada anlaşılmayacak bir durum yok
      Yani deponun iddia ettiği gibi çalışmış

  • Resmî depo olduğunu yalnızca göstermek bile belli ölçüde dikkat çekebilir

    • Sonra GitHub o mavi tiki satmaya başlayabilir
      Ne olabilir ki zaten /s
      Yine de GitHub'ın hangi deponun bir projenin resmî deposu olduğunu daha iyi göstermesi gerektiğine katılıyorum