Bu, serinin üçüncü bölümü. makaleler dizisi En yaygın yazılım tedarik zinciri saldırı türü hakkında: halka açık bir kayıt defterini kötüye kullanan saldırılar. açık kaynak Yazılım bileşenleri. Önceki bölümde analiz ettikten sonra,Zararlı Paketlerin Anatomisi: Eğilimler Nelerdir?"Kötü niyetli kişilerin yeni veya mevcut yayınlanmış bileşenlere nasıl zararlı davranışlar yerleştirdiğini anladığımızda, itfaiyeci ceketlerimizi giymeye ve bu şekilde yayılan kötü amaçlı yazılımları nasıl başarıyla engelleyebileceğimizi veya yanlış bir yaklaşım sergileyerek potansiyel olarak ciddi bir siber olayla nasıl başa çıkabileceğimizi incelemeye hazırız."
Güvenlik konusunda bilinçli profesyonellerin çoğu bu tehditle nasıl başa çıkılacağına dair fikirlere sahip. Güvenlik yöneticilerinin tereddüt etmeden şunları söylediğini duyduk: SCA Araçlar zaten bir paket sürümünün kötü amaçlı yazılım olup olmadığını size bildiriyor. Ya da bilinen, yüksek puanlı yazılım bileşenlerine bağımlı olduklarını, bu sayede herhangi bir kötü amaçlı yazılımın derhal tespit edilip kaldırılacağını söylüyorlar. Güvenlik açığı düzeltmelerini otomatik olarak almak için açık kaynaklı küçük/yama sürümlerini kullanıyorlar ve bu, açık kaynak bağımlılıklarındaki riski azaltmanın doğru ve önerilen yoludur.erken yama, sık yama" prensip.
Bu bölümde, bu fikirlerin neden yanlış olduğunu ve bu tür yanlış anlamaların bu saldırı mekanizmasının popülaritesine ve kuruluşların karşı karşıya kaldığı ezici riske nasıl katkıda bulunduğunu inceleyeceğiz. Son olarak, işe yarayan yöntemleri ve bunların gerektirdiği çaba ve kaynakları ele alacağız.
Yaygın yanlış anlamalar
Yazılım güvenliği yolculuğumuz boyunca, saldırı tekniklerinin geliştiğini ve güvenlik bilincine sahip kişilerden çok çeşitli fikirler gördük. Kuruluşlar genellikle bu tehdide karşı neyin işe yaradığını yanlış anlıyor, bu nedenle öncelikle neyin işe yaramadığını inceleyeceğiz; bu, aşağıdaki, kapsamlı olmayan yanlış anlamalar listesinde özetlenmiştir.
Yanlış anlama #1: SCA Araçlar zaten zararlı bileşenleri rapor ediyor.
Aslında! Ama olaydan sonra…Eğer söz konusu unsur bir yazılım geliştirme sürecinde kullanılmışsa ve kötü niyetli kişiler bir geliştirici firmada zaten yer edinmişse, muhtemelen artık çok geçtir. CI/CD Sunucu üzerinden gizli bilgiler sızdırılmış, ek kötü amaçlı yazılımlar indirilip kurulmuş ve belki de saldırgan yatay olarak hareket ederek başka yerlere erişim sağlamış olabilir.
Yazılım Bileşimi Analizi (SCABu araçlar, potansiyel bilinen güvenlik açıklarını belirlemek için tasarlanmıştır. Modern araçlar, sinyal-gürültü oranını artırarak, güvenlik açığının gerçekten erişilebilir veya istismar edilebilir olup olmadığını belirlemede harika bir iş çıkarır. Ancak yeni kötü amaçlı yazılımlara karşı işe yaramazlar. Kötü amaçlı bir bileşeni sıfır gün güvenlik açığı olarak düşünün: Yalnızca kötü amaçlı davranışı tespit edildiğinde, bileşen kayıt defterine bildirilir ve bir güvenlik ekibi tarafından incelendikten sonra kötü amaçlı olduğu doğrulanır ve kayıt defterinden kaldırılır. [1].
O noktada dünya (dahil olmak üzere) SCAs) bileşenin (veya mevcut bir bileşenin bazı sürümlerinin) yüklenmesinin veya kullanılmasının iyi bir şey olmadığını bilir. Ancak bu, bileşenin kayıt defterinde bulunmadığı durumlarda geçerlidir.Üçüncü taraf bileşenlerde veya hatta kayıt defteri tarafından kötü amaçlı olarak sınıflandırılan bileşenlerde güvenlik açıkları olduğunu bilmek iyi bir şey, ancak ne yazık ki... SCA Ya da yaygın denetim araçları bu bağlamda yardımcı olmuyor. Tabii SCADenetim aracı, bir bileşenin kuruluşunuzda kullanılmadan önce kötü amaçlı olduğunu önceden tespit edebilir..
Unutmayın, kötü amaçlı açık kaynaklı bileşenlere karşı herhangi bir çözüm, bunları tespit etmelidir. anındaBileşenin kayıt defterinde yayınlandığı an ile bileşenin (sürümünün) kuruluşunuzda ilk kez kullanıldığı an arasındaki süre. Ve bu, geçişli bileşenleri de içerir.
Yanlış Anlama #2: Kurulum komut dosyalarını derleme zamanında kontrol etmek, açık kaynaklı bileşenlerden kaynaklanan kötü amaçlı davranışları önler.
Çeşitli paket yöneticileri, bileşen tarball'ında bulunan komut dosyalarını çalıştırma olanağı sunar. [2]), Bu dosyalar, farklı platformlarda gerekli öğeleri derlemek, kod üretmek veya test çalıştırmak gibi meşru nedenlerle kullanılır ve hepimizin bilmesi gereken şey, kötü amaçlı komut dosyalarının tarball'a dahil edilmesi veya saldırganın iyi olan yerine kötü amaçlı bir komut dosyasını çalıştırabilmesi durumunda kötü niyetli kişiler tarafından kötüye kullanılabileceğidir.
Bunu bildiğimize göre, paket yöneticisini komut dosyalarını yok sayacak şekilde yapılandırabiliriz. Örneğin, NPM ile - Komut dosyalarını yoksay bayrak (veya yapılandırma özelliği) .npmrc (dosya) kurulum sırasında komut dosyalarını atlar. Bu, birçok ekosistemde komut dosyalarının çalıştırılması yaygın olduğundan bazı sorunlara yol açabilir: Bazı paket yöneticileri komut dosyası yürütmesini devre dışı bırakmaya bile izin vermez (ipucu: "Hangi paket yöneticileri kurulum komut dosyalarının yürütülmesinin devre dışı bırakılmasına izin vermez?"En sevdiğiniz yapay zekada"). Ancak bu genel olarak koruma sağlamaz (atlama devre dışı bırakma yapılandırmasının her yerde geçerli olmasını sağlamamız gerekiyor).
Kötü amaçlı davranış kurulum komut dosyalarında değil de çalışma zamanında yürütülecek yazılımda bulunduğunda, bu seçenek tek başına bizi korumaz.
Yanlış Anlama #3: Sürüm sabitleme, kötü amaçlı bileşenlerin yüklenmesini engeller.
Sık sık ve erken yamalama ile ilgili bir denge söz konusudur. açık sürümler (Paket yöneticisinin, güvenlik düzeltmeleri için yeni güncellemeler mevcut olduğunda otomatik olarak yüklemesine izin vermek) ve sürüm sabitleme (Bir yazılımın tüm doğrudan ve dolaylı bağımlılıklarının sabit bir sürümde olması). Güvenlik ilkeleri inatçı ve bazen çelişkili olabiliyor, tıpkı "erken yamala, sık sık yamala" gibi. “Yükseltme işlemi hafife alınmamalıdır.”Bazı paket yöneticileri, sunucu aralıklarıyla otomatik güncellemeleri önerilen yöntem olarak sunar. Kötü amaçlı güncellemeleri de almak istiyorsanız harika! Evet, güvenlik açıklarını en kısa sürede kapatan güvenlik düzeltmelerini almak için bileşenlerin güncellenmesi gerekir, ancak... paket yöneticisinin bunu otomatik olarak yapmasına asla izin vermeyin.
Yanlış Anlama #4: Güvenilir bileşenler kullanmak güvenlidir. Herhangi bir kötü amaçlı sürüm derhal bulunur, ifşa edilir ve kaldırılır.
Bir bileşene neden güvenilir? Muhtemelen çok popüler olduğu için, birçok kişi güvenlik açıklarını aradığı için, bakım için çok sayıda katkıda bulunanı olduğu için ve tüm bileşenleri titizlikle inceleyen birden fazla çekirdek yöneticisi olduğu için. pull requestsGerçeklik ise oldukça farklı. Bazı temel bileşenler tek bir, ücretsiz geliştirici tarafından sürdürülüyor. Yaygın olarak kullanılan çerçeveler ise... birkaç düzenli katkıda bulunanhızla azalan sayıda commit(Popüler projelerin, bazı katkılarda bulunanların oluşturduğu uzun bir destekçi kuyruğu vardır.) commit ve bir daha asla geri dönmezler). Ve tek bir bakımcı tarafından yönetilen popüler projeler çoktur.
Kendinizi şöyle derken hayal edin: "Biz Spring Boot / Angular / React / PyTorch / resmi Docker imajlarını kullanıyoruz, bu nedenle bahsettiğiniz risk oldukça düşük." Belki de bu doğru, biz güvenlik firmaları sürekli korku yayıyoruz ve tartışmalı bir riski azaltmak için geliştirme ekiplerine müdahale etmek saçmalık. Risk kabulü paragrafına (bir sonraki bölümde) atlayıp işin bittiğini düşünebilirsiniz. Ne yazık ki, en popüler bileşenler kötü niyetli kişilerin hedefidir ve örneğin, popüler olanlar... PyTorch kütüphanesine saldırı düzenlendi. geçmişte.
"Derhal tespit edildi, bildirildi ve kaldırıldı." Yeni bir zararlı yazılımın kamuya açık kayıt defterinden kaldırılması günler sürüyor. Kayıt defterleri, zararlı yazılımın bir sürümünü kaldırma konusunda temkinli davranıyor. Deneyimlerimize göre, bizim tarafımızdan bildirildikten sonra, kayıt defterinin etkilenen sürümü kaldırması için geçen ortalama süre 39 saat, yani bir buçuk günden fazla. Bazı zararlı yazılımlar, ilk bildirimimizden bir hafta sonra bile kayıt defterinde kaldırılıyor. Ve bazı durumlarda, bileşen ancak bir mağdur veya olay müdahale şirketi bileşeni içeren bir olayı bildirdikten sonra kaldırılıyor.
Zararlı Bileşenlere Karşı Neler İşe Yaramaz?
Belirsiz herhangi bir yaklaşım feci şekilde başarısız olacaktır. Bu kesin bir gerçektir; bu tehditle ilişkili riske karşı etkili önlemler almıyorsunuz.
Geleneksel SCA Bu araçlar bilinen kötü amaçlı yazılımlar hakkında bilgi verir ancak geniş bir maruz kalma aralığına sahiptirler. Kötü amaçlı yazılımları proaktif olarak tespit edip zararlı bileşenleri zorunlu olarak engellemedikleri sürece, bu tehdide karşı etkili olmazlar.
Kurulum komut dosyalarını devre dışı bırakmak yardımcı olabilir, ancak bir bileşenin kurulması gereken her yerde uygulanması gerekir. Sürüm sabitleme için de aynı durum geçerlidir, çünkü sürümler güvenli bir başlangıç durumundan sonsuza dek sabitlenemez.
Popüler bileşenlerin, tedarik zinciri saldırılarında istenmeyen davranışlarla enfekte edilemeyecek kadar az ilgi göreceğini ve bu durumun neredeyse anında tespit edilerek herhangi bir zararın önlenebileceğini varsaymak saf ve riskli bir düşüncedir. Riskli bir hayat sürmek istemezsiniz, değil mi?
Eğer bu noktada durursanız, o zaman risk kabulü Yapabileceğiniz tek şey bu: Bu bir decisTehdit modelinizde/risk değerlendirmenizde belgelenmesi gereken bir unsur; riskin kabul edilme gerekçesi ve potansiyel etkileri de dahil olmak üzere. Bunu yönetime ve diğer ilgili taraflara ileterek farkındalığı artırın. olasılık Yazılımınıza kötü amaçlı bir bileşen yüklendiğinde veya dahil edildiğinde planlama yapılabilir, ancak saldırganların izleyebileceği birçok yol olduğu için bu zordur. Kötü amaçlı bir bileşenin kullanımına dayalı bir tedarik zinciri saldırısının ayrıntıları, olayın kamuoyuna açıklanmasını büyük ölçüde değiştirecektir; bu da muhtemelen kuruluşunuzun düzenleyici çerçevesi uyarınca zorunludur. Ayrıca şu konulara da değinebilirsiniz: telafi edici kontroller or transfer riski Örneğin sigorta ile.
Ancak, tehdidi ele alan ve risk kabulünden memnun kalmazsanız dikkate almanız gereken kontroller mevcuttur. Lütfen okumaya devam edin.
Kötü amaçlı bileşenler kullanan saldırılara karşı ne işe yarar?
Katı Sürüm İşleme
Kontrollü ve bilgilendirilmiş sürüm artışlarıyla sürüm sabitleme, güvenlik açıklarını giderme ihtiyacı ile kötü amaçlı yazılım bulaşmasını önleme ihtiyacını dengelemek için en doğru yöntemdir. Ancak 3. yanılgıyı unutmayın: Sürüm sabitleme tek başına yeni sürümlerden gelen kötü amaçlı kodu engellemek için yeterli değildir, çünkü gelecekte doğrudan veya dolaylı bağımlılıkta bulunan sürümleri güncellemeniz gerekecektir. O anda, tüm değiştirilmiş sürümlerin kötü amaçlı yazılım içermediğine dair yeterince güçlü bir kanıta ihtiyacınız vardır.
Erken uyarı
Zararlı bileşenler sorununa yönelik yaklaşımlardan biri de erken uyarı sistemidir (burada şu şekilde adlandırılmıştır): Kötü Amaçlı Yazılım Erken Uyarı Sistemi veya MEW), burada yayınlanan yeni sürümler (yeni veya mevcut bileşenler için) bir tespit motoru tarafından analiz edilir ve yeterli kanıt bulunduğunda yeni sürüm potansiyel olarak kötü amaçlı olarak sınıflandırılabilir.
Otomasyon burada çok önemlidir, çünkü mevcut yayın hızıyla tüm yeni bileşenleri manuel olarak incelemek imkansızdır. Bu nedenle, tespit motorunun statik, dinamik ve yetenek analizi, kullanıcı itibarı ve bileşen meta verileri ile tarball içeriği veya tarball ile bileşenin geldiği varsayılan kaynak deposu arasındaki tutarsızlıklardan elde edilen kanıtlar da dahil olmak üzere çeşitli teknikleri birleştirmesi gerekir.
Var karanlık bölge Yayınlama zamanı ile motorun bileşen içeriklerini analiz etme zamanı arasında geçen süre birkaç dakikayı geçmemelidir. Bu şema, örneğin yeni bileşenlerin yazılım derlemesine yüklenmesine ve kullanılmasına izin verilmeden önce analiz edilmelerini bekleyerek değiştirilebilir. pipelineveya gerektiğinde talep üzerine analiz edin. Belirli bir sürümdeki bir bileşen değiştirilemezdir. [3]Dolayısıyla sadece bir kez analiz edilmesi gerekiyor.
Tam otomasyon mümkün değildir ve potansiyel olarak kötü amaçlı bileşenler için bir güvenlik incelemesi gereklidir. Dijital her derde deva vaat edenlere karşı dikkatli olun.Yapay zeka ve makine öğrenimi, şüpheli bir bileşenin kötü amaçlı yazılım içerip içermediğini doğrulama konusunda son sözü söyleyecek kadar gelişmiş değil. Elbette, makine öğrenimi, yakalanan ham kanıtlardan girdi bileşenini sınıflandırmada tespit motorunda önemli bir rol oynuyor, ancak bileşen "karantinaya" alındıktan sonra son söz, kötü amaçlı bileşenler konusunda deneyimli bir güvenlik ekibi tarafından yapılan manuel incelemeye kalıyor. Bu, olası kötü amaçlı yazılımları doğruluyor veya güvenli olarak yeniden sınıflandırıyor. Ve bu süreç saatler sürüyor.
Kayıt defteri, kötü amaçlı sürüm/bileşen hakkında rapor verir; ardından kayıt defteri, doğrulamak için incelemesini yapar ve kamuya açıklama ve kayıt defterinden kaldırma işlemine geçer. Bazı kayıt defterleri bir güvenlik saklama paketi tutar. Buradaki zaman aralığı, yayın tarihinden itibaren geçen gün veya haftalardır.bekleme süresi'veya'pozlama penceresi'çoğu kötü amaçlı bileşen için.'
Bir bileşen sürümünün kötü amaçlı olup olmadığını anlamak mümkün mü?
Dolayısıyla erken uyarı için şu soruya tatmin edici bir cevap vermemiz gerekiyor: Bir kütüphanenin veya paketin kötü amaçlı (olmadığını) nasıl bilebilirim? Kötü amaçlı davranışa dair yeterli kanıtı nasıl toplayabilirim? Mümkün, ancak zor, çünkü saldırganlar tespit edilmekten kaçınmak için çok fazla zekâ kullanıyorlar. Her birinin avantajları ve dezavantajları olan farklı yaklaşımlar var.
Statik analiz Bileşeni çalıştırmadan tüm yürütme yollarını inceleyebilir, saldırganlar tarafından kullanılan teknikleri kontrol edebilir ve şifre çözme veya kod gizlemeyi kaldırma gibi ön işleme görevlerini gerçekleştirebilir. Saldırganlar kötü niyetlerini gizlemeye çalıştıkça, kod gizleme girişimleri gerçekten de kötü amaçlı yazılımın kanıtıdır (ancak meşru bileşenlerin fikri mülkiyeti korumak için kodu gizlediğini ve bunun "açık kaynakSadece az sayıda son derece gelişmiş ve güçlü gizleme yöntemlerine sahip saldırı için sanal alan gereklidir, ancak bu kadar güçlü gizleme, kötü niyetin açık bir işaretidir. Lütfen geleneksel yöntemlerin SAST Bu araçlar, arka kapılar gibi kötü amaçlı yazılımlar için değil, kasıtsız güvenlik açıkları için tasarlanmıştır.
Dinamik analiz Bileşeni çalıştırır ve çalışma zamanını inceleyerek, genellikle sanal bir ortam sağlayarak yanıtı değerlendirir. Belirli koşullar altında tetiklenen kötü amaçlı davranışlar tespit edilemeyebilir: lütfen kötü amaçlı yazılımların kaçınma teknikleri kullanabileceğini unutmayın. Sanallaştırma/Sandbox Evasion Yalnızca gözetim altında olmadığında etkinleşir ve aynı zamanda herhangi bir statik analiz motoru için kötü amaçlı faaliyetin açık bir işaretidir.
Yetenek analizi Bu yaklaşım, bileşenin ne yaptığını dikkate alır: nereye bağlandığı, hangi dosyalara eriştiği, hangi komutların veya programların çalıştırıldığı, terminal veya aygıt G/Ç işlemlerinin gerçekleştirildiği veya hangi sistem çağrılarının yapıldığı. Bu davranış parmak izi alma işlemi (mevcut bir bileşen için) sürümler arasında karşılaştırılabilir; böylece beklenmedik bir davranış tespit edildiğinde, bu kanıt yeni sürüme enjekte edilmiş potansiyel kötü amaçlı faaliyet şüphesini artırabilir. Bu yaklaşım, güvenlik analistlerinin potansiyel kötü amaçlı yazılımlarla karşılaştıklarında izledikleri önceliklendirme adımlarını takip eder: bir inceleme kullanılarak yapılan bir değerlendirme. dizeleri veya benzer araçlar. Bu yaklaşım, tetikleyici koşullardan bağımsız olarak kötü amaçlı davranışı tespit eder ve kaynak kod mevcut olmadığında da çalışır.
Bağlam analizi Bileşenin nasıl ve kim tarafından yayınlandığına dair bilgi toplar. Kötü niyetli kişilerin kampanyaları genellikle sıkı bir doğrulama sürecine tabi olmayan yeni kullanıcı hesapları kullanır. Geçmiş etkinliklerin izlenmesi, özellikle potansiyel bir güvenlik açığına işaret edebilecek anormallikler açısından, altta yatan kullanıcı hakkında fikir verebilir. İtibar kazanmak çok zor, kaybetmek ise çok kolay! Geçmişte hiçbir etkinliği olmayan bir kullanıcı tarafsızdır, ancak karma kötü niyetlileri takip eder. Siber aktivistler veya yayınlama kimlik bilgileri çalınan normal kullanıcılar dikkatlice izlenmelidir.
Diğer bir bağlamsal bilgi ise, bileşen tarball'ını oluşturmak için kullanıldığı varsayılan kaynak deposu ile tarball'ın içeriği arasındaki herhangi bir tutarsızlıktır. Ayrıca, kaynak deposunda, kamuya açık kayıt defterinde yayınlanan bileşen sürümleriyle eşleşen etiketler veya sürümler oluşturmak gibi iyi uygulamaları takip etmek de önemlidir. Belirli bir kaynak deposunda commit Bir sürüm "release" etiketiyle işaretlenmişse ve aniden bir sürüm bu etiketi takip etmiyorsa, bu tek başına bileşenin bozuk olabileceğine dair güçlü bir kanıttır: kötü niyetli kişi, bileşeni yayınlamak için kullanılan hesabı ele geçirmiş olabilir, ancak kaynak kod deposunda yazma izni olmayabilir. Bu kurallar kullanılarak birçok saldırı rutin olarak tespit edilir: örneğin, Defter saldırısı Bu yöntemler sayesinde kolayca tespit edilebilirlerdi. Dolayısıyla bağlam analizi, yayın sürecindeki bu tür anormallikleri belirler.
Bağımlılık Güvenlik Duvarı
Farklı bir yaklaşım ise, yazılımınızda kullanılan tüm bağımlılık grafikleri için kapsamlı bir bileşen beyaz listesine sahip olmaktır; böylece her derlemede bu liste geçerli olur. pipeline Kuruluşunuzda yalnızca onaylanmış bileşen sürümleri kurulabilir ve kullanılabilir.güvenlik duvarı"Bu kural, izin verilen bileşen sürümlerine ait tarball'ların sunulduğu (önbelleğe alınmış veya vekil sunucu üzerinden) dahili bir kayıt defteri kullanılarak uygulanır. Lütfen, herhangi bir yeni sürümü makul derecede güvenli olarak sınıflandırıp beyaz listeye ekleyebilecek teknolojiye sahip olmadığınız sürece herhangi bir beyaz listenin çalışmayacağını unutmayın."
Lütfen, erken uyarı (yeni sürüm yayınlandıktan hemen sonra hızlı tespit) yönteminin, derlemeyi etkileyen bileşeni engellemek için bu bilgiyi proaktif olarak kullanmanın bir yoluyla birleştirilmesi gerektiğini unutmayın. pipelineveya geliştiricilerin makineleri [4]Biz buna “bağımlılık güvenlik duvarı": Otomatik derlemeleri kötü amaçlı paketlerden korumak için kullanılan bir karantina mekanizması. Dahili paketler ve imaj kayıtları, kuruluşları dışarıdan gelen kötülüklerden korumak için iyidir, ancak karantinanın etkili olması için yeterince güçlü kanıt gereklidir."
Çalışma Zamanı Korumalı Alan
Yayınlama aşamasında tespit için alternatif bir yaklaşım, çalışma zamanındaki davranışı analiz etmektir. Buradaki fikir, yazılımdan beklenen davranışı yakalamak ve bulunan anormallikleri tespit etmek (veya engellemek)tir. Bu yaklaşımın sorunu, izleme veya engelleme için çalışma zamanının yapılandırılması gerekliliğidir ve kötü amaçlı bileşen zararlı yazılımlarına karşı koruma mekanizmaları cephaneliğine eklenecek umut vadeden bir fikirdir.
Kapsamlı Bir Strateji Belirlemek
Önerilen strateji, yazılım geliştirme sürecinde farklı teknikleri birleştirmeyi ve gelen kötü amaçlı bileşenleri engellemek için sürüm güncellemelerini kontrol altına almayı gerektiriyor. Önemli güvenlik açıklarına yönelik düzeltmeleri almak için güncellenen sürümlerle otomatik enfeksiyonu önlemek amacıyla sürüm sabitleme yöntemini kullanmalıyız; sürüm güncellemeleri sırasında doğrudan ve dolaylı bağımlılıkların hızlı ve verimli bir şekilde değerlendirilmesi, bunların kötü amaçlı yazılım içermediğine dair yeterli kanıt elde etmek için gereklidir. Bilinen kötü amaçlı bileşenlere bağımlı yazılım sürümleri engellenmelidir. Ve bunların tümü uygulanmalıdır.
Mümkün olduğunda sürüm sabitleme özelliğini kullanın, çünkü bu, derlemelerin daha tekrarlanabilir olmasını sağlar. Kontrollü ve manuel olarak onaylanmış sürüm yükseltmeleriyle sürüm sabitleme, ve yardımcı teknoloji tarafından desteklenmektedirGüncellemenin kötü amaçlı yazılım getirip getirmediğini veya yazılımı bozup bozmadığını değerlendirmeli ve güvenlik açıklarını gidermek için güncellemeyi kötü amaçlı yazılım bulaşmasından kaçınmakla uzlaştırmalıdır. Araçlar burada şu konularda yardımcı olabilir: (1) Gerçekten önemli olan güvenlik açıklarını önceliklendirmek (erişilebilir ve istismar edilebilir, saldırganlar tarafından hedef alınma riski yüksek olanlar), (2) mevcut bileşen kullanımlarıyla uyumlu ve yazılımı bozmayan hedef sürümleri seçmek, (3) kötü amaçlı davranış içermeyen hedef sürümleri seçmek ve (4) hızlı bir şekilde onaylanabilecek bildirim dosyalarındaki değişiklikleri önererek doğrudan ve dolaylı bağımlılıklar için sürüm güncellemesini kolaylaştırmak. (3) numaralı adım, kötü amaçlı bileşenler hakkında yayınlanma zamanlarına mümkün olduğunca yakın spesifik bilgilere ihtiyaç duyar.
Bağımlılıkların güncellenmesi süreci şu şekilde olmalıdır: zorunlu hem de Doğrulanmış Her yerde. Süreç belgelenmeli ve ilgili tüm taraflar eğitilmelidir, çünkü geliştirme ve yazılım oluşturma/dağıtım genellikle dışarıdan yaptırılır. CI/CD pipelineOtomasyonun, kötü amaçlı dolaylı bir bağımlılığın derleme sürecine sızmasına izin vermemesi için s'ler buna göre değiştirilmelidir: guardrails Bağımlılıklarda potansiyel kötü amaçlı yazılım olduğuna dair yeterli kanıt varsa, derlemeyi engellemek önerilen yöntemdir.
Eğer kuruluşunuzda izin verilen bileşen sürümlerini tutmak için bir güvenlik proxy'si görevi gören dahili bir kayıt defteri varsa, bir bileşeni izin listesine eklemeden önce (diğer kriterlerin yanı sıra) kötü amaçlı bileşenler hakkında istihbarat edinmeniz gerekir.
Açık kaynaklı yazılımları güvenli bir şekilde kullanmak kolay değildir ve kötü amaçlı yazılım faktörü tam olarak dikkate alınmalı, güvenlik açıklarıyla başa çıkmaya da benzer bir özen gösterilmelidir.
Son bir not: Kaynak menşeiBileşenin derleme zamanında oluşturulan yazılım onayları biçimindeki bu belge, bileşen tarball'ını oluşturan kaynaklar ve derleme süreciyle ilişkilendirme çabasında bir diğer önemli unsurdur. Kaynak anlık görüntüsü + derleme ortamı ile ilişkili yazılım yapısı (güvenilir derleme sistemi tarafından imzalanmış) arasındaki bu bağlantının, bileşenin kötü amaçlı davranış içermediğini doğrudan engellemediğini, ancak kötü niyetli kişilerin kötü amaçlı yazılım enjekte etmesini zorlaştırdığını unutmayın. Ve kaynak doğrulamasını açık kaynak bileşenlerinin kullanımı için yaygın bir gereklilik haline getirmek uzun zaman alacak ve ancak NPM'ye yakın zamanda eklendiGüvenilir derleme ve dağıtım sistemlerini kurcalamaya karşı korunaklı hale getirmek veya derlemedeki herhangi bir kurcalama girişimini tespit etmeyi sağlamak farklı bir konu olup, bu yazının kapsamı dışındadır.
Ek okuma
Sonraki bölüm Açık Kaynaklı Zararlı Paketler: Xygeni Yaklaşımı Xygeni'de izlediğimiz stratejiyi sunacağız. Kötü Amaçlı Yazılım Erken Uyarı Sistemi (MEW) sistemi. Genel paket ve görüntü kayıt defterlerindeki yeni paket sürümleri taranır ve statik, dinamik, yetenek ve bağlamsal analiz kombinasyonu kullanılarak kanıt elde edilir. Bu kanıt, kullanıcı itibarı ve kaynak kod depolarındaki değişiklik geçmişiyle birleştirilerek, bir bileşenin yüksek riskli ve muhtemelen kötü amaçlı kategorilere tamamen otomatik olarak sınıflandırılmasına olanak tanır. Sistem, yanlış pozitifleri en aza indirmek için paketlerden toplanan geçmiş kanıtlardan öğrenir.
Abone olan kuruluşlar, doğrudan veya dolaylı olarak kullandıkları bileşenler için kötü amaçlı bir sürüm sınıflandırıldığında bir uyarı bildirimi alırlar. Ardından analistlerimiz tarafından manuel bir analiz yapılır ve sınıflandırma onaylanır veya reddedilir. Onaylanan kötü amaçlı yazılımlar için, kamu kayıt defterine bildirim gönderilir, böylece kendi analizini yapabilir ve genellikle kötü amaçlı sürümü kaldırabilir veya söz konusu kullanıcı hesabını engelleme veya silme gibi ek önlemler alabilir.
Açık kaynak ekosistemindeki NPM, PyPI, GitHub ve diğer önemli altyapıların, yayınlanan yeni bir kötü amaçlı bileşenin kötü amaçlı yazılım olarak onaylanıp kayıt defterinden kaldırılana kadar aktif kaldığı süreyi nasıl azalttığını açıklayacağız. Ayrıca kuruluşların, açık kaynak bileşenlerini içeren yazılım tedarik zinciri saldırılarına karşı çok daha iyi bir koruma sağlamak için MEW sisteminden nasıl faydalanabileceğini de anlatacağız.
- [1] Her neyse, bu sorunu ortadan kaldırmak için bileşenin kullanıcılarının bileşen tarball dosyasının bir yerde, örneğin dahili bir kayıt defterinde önbelleğe alınmış veya kayıtlı olup olmadığını kontrol etmeleri gerekiyor.
- [2] Paketlenmiş bileşen, içeriğini ve meta verilerini, kaynak veya derlenmiş kodu, kurulum komut dosyalarını ve test paketleri gibi ek öğeleri, bir paketleme formatına göre ve genellikle sıkıştırılmış biçimde bildiren bir bildirim dosyası içerir. Buna "bileşen tarball'ı" denir.
- [3] Kötü niyetli kişi, kayıt defterindeki bir güvenlik açığı nedeniyle yayınlanmış bir bileşeni değiştirebilse bile, analiz tamamlandıktan sonra basit bir kriptografik özet, tarball'daki herhangi bir değişikliği tespit edebilir.
- [4] Unutmayın ki bazı kötü amaçlı bileşenler kurulum sırasında çalışır, bu nedenle "npm install X" komutunu kötü amaçlı bir bileşen olan X ile çalıştıran geliştirici düğümlerini etkileyebilir.
