Yazılım bağımlılıkları veya bir uygulamanın çalışması için ihtiyaç duyduğu bir yazılım parçasının yönetilmesinin zor olduğu ve büyük bir yazılım tedarik zinciri riski oluşturduğu bilinmektedir. Yazılım tedarik zincirinizde ne olduğunun farkında değilseniz, bağımlılıklarınızdan birindeki yukarı akış güvenlik açığı ölümcül olabilir.
Basit bir React tabanlı Web uygulaması, 1.700’den fazla geçişli NodeJS’ye sahip olabilir “npm” bağımlılıklarıve birkaç ay sonra “npm denetimi”, bu bağımlılıkların nispeten büyük bir kısmının güvenlik açıklarına sahip olduğunu ortaya çıkaracaktır. Durum, Python, Rust ve paket yöneticisi olan diğer tüm programlama dilleri için benzerdir.
Bağımlılıkları, manavın soğutulmamış bölümünde çürüyen meyveler olarak düşünmeyi seviyorum. özellikle npm paketleri, genellikle minimum çabadan fazlasını ortaya koymak için çok az motivasyona sahip ücretsiz geliştiriciler tarafından yazılır. Genellikle kişisel kullanım için yazılırlar ve seçimle değil şans eseri açık kaynaklıdırlar. Sürmek için yazılmamışlar.
Son zamanlarda (bu makalenin yazıldığı tarihte), Python için en popüler iki makine öğrenimi kitaplığından biri olan PyTorch, “torchitron” bağımlılığı nedeniyle beş gün boyunca tehlikeye girdi. Saldırgan, sistem bilgilerini toplayabilir ve etkilenen her kullanıcının ana dizininden 1.000 dosya çalabilir. 2021’de Log4j ünlü bir şekilde ele geçirildi ve temelde her Web’e yönelik Java projesine dahil edildiğinden, DevSecOps ekipleri tam olarak nerede savunmasız olduklarını belirleme konusunda büyük bir baskı altındaydı.
20 bile kasıtlı bağımlılıklar, bir geliştirme ekibinin sürekli olarak denetlemesi için çok fazla, 2.000’den çok daha az geçişli olanlar.
Şimdiye Kadar Neler Yapıldı?
Tüm umutlar kaybolmaz. İçin bilinen (bildirilen ve kabul edilen) güvenlik açıkları, araçlar gibi var pip denetimibir geliştiricinin Python çalışma ortamını güvenlik açıklarına karşı tarar. Npm denetimi nodeJS paketleri için de aynısını yapar. Her büyük programlama dili için benzer araçlar mevcuttur ve aslında Google yakın zamanda piyasaya sürmüştür. OSV-Tarayıcı, yazılım bağımlılığı güvenlik açıkları için bir İsviçre Çakısı olmaya çalışır. Geliştiricilerin bu denetimleri düzenli olarak gerçekleştirmeleri için teşvik edilip edilmediği (veya zorlanmadığı) ve gerçekten harekete geçip geçmedikleri bu analizin kapsamı dışındadır. iyileştirmek bu bilinen güvenlik açıkları.
Ancak, neyse ki, Dependabot gibi otomatik CI/CD araçları bu düzeltmeleri mümkün olduğunca acısız hale getirmek için var. Bu araçlar, güncel olmayan paketler için kod havuzlarınızı sürekli olarak tarar ve bunları düzeltmek için otomatik olarak bir çekme isteği (PR) gönderir. “dependabot” aranıyor[bot]” veya “yenilemek[bot]” GitHub’da ve aktif PR’lara filtrelemek milyonlarca sonuç verir! Bununla birlikte, herhangi bir zamanda yüz milyonlarca aktif PR’ye karşı 3 milyon bağımlılık düzeltmesi, derinlemesine bir analizin dışında yapmaya çalışmak için imkansız bir niceliktir.
Son Teknoloji Yeterince İyi Değil
Bu denetim araçlarının, geliştiricileri bildirilen ancak henüz resmi olarak kabul edilmeyen sıfır gün istismarlarına veya N günlere karşı korumak için hiçbir şey yapmadığını unutmamalısınız. Daha önce bahsedilen PyTorch güvenlik açığı durumunda, denetim araçlarının hiçbiri bunu yakalayamazdı. sınıf Bağımlılık güvenlik açığı, çünkü istismar edilen geleneksel bir “yazılım güvenlik açığı” yoktu. Bu “bağımlılık karışıklığı” saldırıları, paket yöneticilerinin bağımlılıkların seçebileceği diğer depoları kontrol etmeden önce “varsayılan” depolarına bakmalarından yararlanır. onların bağımlılıklar. PyTorch örneğinde, “torchitron” bağımlılığı PyTorch Foundation tarafından kendi kendine barındırılıyordu. Saldırgan kendi sürümünü PyPI’ye yüklediğinde, resmi sürümden öncelikli hale geldi.
Bu ne kadar devam edecek? Sonsuza kadar. Bu güvenlik açıklarından yararlanmanın bir değeri varsa, saldırganlar bunlardan yararlanmaya devam edecektir. Şans eseri, PyTorch söz konusu olduğunda, “yalnızca” veri hırsızlığı gerçekleşti. Ancak gelecekteki kurbanlar o kadar şanslı olmayabilir. Sofistike bir saldırganın, kurbanın sisteminde (ve ağında) kalıcı kalması için yalnızca bir başarılı erişim denemesine ihtiyacı vardır.
Bu benim için ne anlama geliyor?
Paketlerinizi komut satırından mı kurdunuz? Eğer öyleyse, bunları doğru bir şekilde yazdınız mı? Artık bağımlılıklarınızı “doğru” kurduğunuza göre, her bir bağımlılığın kodunun tam olarak düşündüğünüz şeyi yaptığını doğruladınız mı? Her bir bağımlılığın beklenen paket havuzundan yüklendiğini doğruladınız mı? sen….
Muhtemelen hayır ve sorun değil! Geliştiricilerin bunu her bir bağımlılık için yapmasını beklemek insanlık dışıdır. Yazılım geliştiriciler, yazılım şirketleri ve hatta bireysel tamirciler için en iyi bahis, bir tür çalışma zamanı korumasına/algılamasına sahip olmaktır. Neyse ki hepimiz için, artık sağlıklı ve rekabetçi bir ekosistemin parçası olan, nispeten yakın zamanda oluşturulmuş tespit ve müdahale araçları var! Birçoğu, tıpkı falco, Sysdig Açık KaynakVe mezar taşı, hatta ücretsiz ve açık kaynaklı bileşenlere sahip. Çoğu, varsayılan bir dizi kural/koruma ile birlikte gelir.