BLACK HAT USA – Las Vegas – 9 Ağustos Çarşamba Açık kaynak OWASP’nin bağımlılık kontrolü projesinin kurucusu ve lideri, ikili kaynak doğrulaması adı verilen yeni bir süreç kullanarak, yazılım tedarik zincirinin güvenliğini sağlama sorununa bir çözüm olduğunu düşündüğü şeyi tasarladı.
İkili kaynak doğrulama fikri, yazılımı yazılımın kaynak kodundan daha derin bir katmanda incelemeyi, kodlama sırasında oluşturulan derleme eserlerine bakmayı ve bunları meşru olarak doğrulamayı içerir, diye açıklıyor ServiceNow’da uzun süredir yazılım geliştiricisi olan Jeremy Long ve bir OSWAP gurusu. Kaynak koduna bir bakış sağlayan yazılım malzeme listelerinin (SBOM’ler) yeterli güvenlik önlemleri olmadığını belirtiyor.
İkili doğrulama fikrinin özü, Unix’in ortak yazarı Ken Thompson tarafından yazılan ve bir kod derleyicisini arka kapıyla tehlikeye atma sürecini özetleyen, 1984 tarihli “Güvene Güvenme Üzerine Düşünceler” adlı iyi bilinen bir makalede yatmaktadır. arka kapı yayınlanan kaynak kodunda görünmüyor. Yine de bir geliştirici, güvenliği ihlal edilmiş derleyiciyi yazılımın bir sonraki sürümünü oluşturmak için kullanırsa, bu derleyiciye arka kapı enjekte eder. Daha sonra, bir geliştirici işletim sistemini derleyici ile derlerse, arka kapı da işletim sistemine enjekte edilir. Bu senaryo, Thompson’ın Unix’in derinliklerine nasıl bir arka kapı bıraktığını, makalesinde açıkladı.
“[The backdoor] asla kaynak kodunda değildir, yalnızca derleyicinin ikili çıktısındadır,” diye açıklıyor Long. Bu nedenle, kaynak koddaki çalışma zamanı bağımlılıklarını doğrulayabilen geliştirici araçları, geliştiricilerin arka kapıyı tespit etmelerine yardımcı olmayacaktır — veya bu konuda herhangi bir kötü amaçlı kod — genel yazılım yapılarında, diyor.
“Yazılımı nasıl oluşturduğumuza yeterince derinlemesine bakmıyoruz” diyor.
Long, bugün Las Vegas’ta düzenlenen Black Hat USA 2023 konferansında “Yazılım Tedarik Zincirinde Güven Üzerine Düşünceler” adlı bir oturumda yazılım tedarik zincirinin güvenliğini sağlamanın neden bu kadar zor olduğunun temelindeki çözümünü ve diğer sorunları ana hatlarıyla açıklayacak.
Yazılım Tedarik Zinciri Saldırılarına Olası Bir Çözüm
Long, araştırmasında ikili kaynak doğrulamasının bir gösterimi için Java ve .NET gibi bazı üst düzey programlama dillerine odaklandı. Şimdiye kadar öngördüğü çözüme en yakın çözüm, yine Thompson’ın makalesinden çıkan ve projenin web sitesine göre yazılım için “anlamsal olarak anlamlı bir parmak izi” sağlamayı amaçlayan IBM’in Code Genome projesi.
İkili kaynak doğrulaması, geliştiricilerin eseri doğrulaması için bir yol sağlar – örneğin, Java ile yazılmış yazılım geliştirirken üretilen JAR dosyası — kodun bir yazılım doğrulama yolu olarak “tekrarlanabilir yapı” denilen şeyi üretip üretmediğini kontrol etmek yerine bağımsız olarak, diyor.
Long, “Bu, yapınızın tehlikeye atılmadığına dair güvencenizi gerçekten artırmanın bir yolu,” diye açıklıyor. “İkili dosyadaki talimat setine bakabilir ve bunun kaynak kod tarafından üretilip üretilemeyeceğini doğrulayabilirsiniz.”
SBOM’lar Yazılım Oluşturma Güvenliği İçin Yeterli Değil
SBOM’ların genellikle kuruluşlara yazılımlarında neler olduğu konusunda daha fazla görünürlük sağladığı söyleniyor, ancak Long bunun yeterli olmadığını açıklıyor.
SBOM’lar, dağıtılmadan önce bilinen bir güvenlik açığı içermediğinden emin olmaya yardımcı olabilecek bir yazılım parçasıyla birlikte gelen bileşenlerin ve çalışma zamanı bağımlılıklarının bir envanteridir. Ancak yalnızca bilinen güvenlik açıklarıyla ilgilendikleri gerçeği, SBOM’ları tedarik zinciri güvenliğiyle başa çıkmak için eksik bir yol haline getiriyor.
Bu sorunun üstesinden gelmek için yeni ortaya çıkan bir çaba, formülasyon malzeme listesi veya FBOM olarak adlandırılan şeydir. CycloneDX adlı açık kaynaklı bir SBOM aracının yeni bir sürümüne eklenen FBOM, yalnızca yazılımın çalışması için gereken bağımlılıklara ilişkin görünürlük sağlamakla kalmaz, aynı zamanda yazılımın derleme platformu, eklenti açısından nasıl oluşturulduğuna ilişkin ayrıntılar da sağlar. ins, kitaplıklar ve diğer bileşenler, diye açıklıyor Long. Bu şekilde, bu öğelerden herhangi birinin bilinen güvenlik açıkları varsa, dağıtımdan önce tanımlanabilirler.
Long, “FBOM kesinlikle doğru yönde atılmış bir adımdır” diyor. Bununla birlikte, yine de, kuruluşların savunmasız bir yazılım parçası kullanıp kullanmadıklarını öğrenmek için kullanabilecekleri, yazılımın sıfırdan kötü amaçlı kod olmadan oluşturulmasını sağlamadığını, ihlal sonrası büyük ölçüde adli veri sağladığını belirtiyor.
Long, “Hâlâ sıfır gün tipi sorunlarıyla ilgilenmiyor” diyor. “Kimsede alet yok [for this].”
Long, ikili kaynak doğrulamasını yazılım tedarik zincirinin karşı karşıya olduğu güvenlik sorunlarını çözmeye yardımcı olacak potansiyel bir yol olarak görüyor, ancak meyve vermesinin zaman alacağını kabul ediyor.
Araştırma dramatik bir arka plana dayanıyor: Son birkaç yılda aralarında SolarWinds ve Log4j’nin de bulunduğu bir dizi yüksek etkili yazılım tedarik zinciri saldırısı, saldırganların başarılı bir şekilde saldırmak için yazılımları nasıl hedefleyeceklerine dair kodu kelimenin tam anlamıyla kırdıklarını gösteriyor. yazılım bağımlılıkları yoluyla milyonlarca sisteme ulaşabilir. Geliştiricilerin bir uygulamanın bir bileşeninde bulunan kötü amaçlı kodu sayısız sisteme dağıtılmadan önce belirlemesinin kolay bir yolu olmadığından, bu sorunla mücadele etmenin zor olduğu kanıtlanmıştır. Ayrıca, Log4j’de görüldüğü gibi, halihazırda kullanımda olan yazılımdaki güvenlik açığı bulunan bileşenlerin izlenmesi – kusurlar belirlendikten sonra bile – son derece zor bir iştir.
Saldırganlar bu karmaşıklıklardan giderek daha fazla yararlanıyor ve yaklaşımlarını yazılıma daha geliştirilmeden saldıracak bir düzeye getirdiler. Açık kaynak kodu kitaplıklarına ve diğer programlama platformlarına ve geliştiricilerin uygulama yazmak için kullandıkları araçlara (son zamanlarda popüler bir hedef olan Python gibi) yönelik saldırılar daha yaygın hale geliyor. Bunu yapmak, kötü niyetli aktörlere yazılım tedarik zinciri boyunca birden çok sisteme tek seferde saldırmak için dolaylı ama etkili bir kanal sağlar.