Help Net Security röportajında, Endor Labs güvenlik araştırmacısı CISSP Henrik Plate, AppSec ekiplerinin yazılım bağımlılıklarındaki güvenlik açıklarını belirlemede karşılaştıkları karmaşıklıkları ele alıyor.
Plate ayrıca geleneksel yazılım kompozisyon analizi (SCA) çözümlerinin sınırlamalarını ve etkili güvenlik yönetimini sağlamak için sağlam güvenlik açığı veri tabanlarına olan ihtiyacı da ele alıyor.
AppSec ekiplerinin yazılım bağımlılıklarındaki güvenlik açıklarını tespit ederken karşılaştıkları temel zorluklar nelerdir?
Görünüşte basit ama aslında oldukça karmaşık olan zorluk, bağımlılıklar içindeki savunmasız kodun varlığını doğru bir şekilde tespit etmek ve ardından hangi bulguların uygulamaları bağlamında istismar edilebilir olduğunu bulmaktır. Başka bir deyişle, hangi güvenlik açıklarının (hangi işlevlerde ve hangi bağımlılıklarda) aslında düzeltme için önceliklendirilmesi gerektiğini bulmaktır.
Bunun zor olmasının birçok nedeni var, ancak öne çıkanlar şunlardır:
Konuyla ilgili olarak savunmasız kodun tespiti: Birçok projenin birden fazla paket üretmesi – bazıları etkilenmiş, diğerleri etkilenmemiş – kodun bir açık kaynak projesinden diğerine yeniden paketlenmesi veya yeniden paketlenmesi – projelerin yeniden adlandırılması ve çatallanması – ve açık kaynak proje bakımcılarının genellikle belirli bir güvenlik açığının eski, bakımı yapılmayan sürümleri etkileyip etkilemediğini kontrol etmemesi. Bu zorluklar nedeniyle, elle düzenlenen güvenlik açığı veritabanlarının yanlış bilgiler içermesi şaşırtıcı değildir.
İlgili olarak sömürülebilirlik: Doğrulanmış güvenlik açığı olan kodun belirli bir alt uygulama bağlamında istismar edilip edilemeyeceğini manuel olarak belirlemek zordur ve uygulamaya özgü etkisi de bir diğer önemli zorluktur.
Bu araştırmayı gerçekleştirebilmek, yapılandırılmış, makine tarafından okunabilir bir biçimde kolayca erişilemeyen bağlam bilgilerine bağlıdır; özellikle de birçok SCA çözümünün çalıştığı geliştirme veya derleme zamanında. Bu bilgilerin bir kısmı, uygulama tarafından işlenen ve depolanan bilgilerin niteliği veya uygulamaya özgü güvenlik önlemleri gibi, örneğin gereksinim ve tasarım belgelerinde veya yalnızca geliştiricilerin zihninde yakalanır. Dağıtım ortamı veya yapılandırma gibi diğer bağlam bilgileri de SCA çözümlerine sunulmaz.
Sömürülebilirliği belirlemek zor olduğundan, kod merkezli SCA çözümleri, geliştirme ve derleme zamanında mevcut kod temelinde yapılabilen bilinen güvenlik açığı olan işlevlerin erişilebilirliğini belirlemeyi amaçlar. Ancak erişilebilirliğin yalnızca sömürülebilirlik için bir ön koşul olduğunu anlamak önemlidir; erişilebilir işlevlerin tümü çalışma zamanı ortamlarında gerçekten sömürülemez.
Hayalet bağımlılıkların ne olduğunu ve neden risk oluşturduğunu açıklayabilir misiniz?
“Hayalet bağımlılık”, kodunuzda kullanılan ve manifestte bildirilmeyen bir paketi ifade eder. Bu kavram herhangi bir dile özgü değildir (JavaScript, NodeJS ve Python’da yaygındır). Bu sorunludur çünkü göremediğiniz şeyi güvence altına alamazsınız.
Geleneksel SCA çözümleri, tüm uygulama bağımlılıklarını tanımlamak için bildirim dosyalarına odaklanır; ancak bunların her ikisi de uygulama tarafından gerçekten kullanılan bağımlılıkları yetersiz veya aşırı temsil edebilir.
Analiz yalnızca bağımlılıkların bir alt kümesini içeren bir bildirim dosyasından başlarsa, örneğin ek bağımlılıklar manuel, betikli veya dinamik bir şekilde yüklendiğinde, yetersiz temsil edici olabilirler. Bu, örneğin, paket ve sürüm seçiminin genellikle işletim sistemlerine veya donanım mimarilerine bağlı olduğu ve bildirim dosyalarındaki bağımlılık kısıtlamalarıyla tam olarak ifade edilemeyen Python ML/AI uygulamalarında olabilir.
Ve aslında kullanılmayan bağımlılıklar içeriyorlarsa aşırı temsil edici olurlar. Bu, örneğin şişkin bir çalışma zamanı ortamında bulunan tüm bileşenlerin adlarını bir bildirim dosyasına döktüğünüzde olur (örneğin “pip freeze” düşünün). Örneğin, belirli bir Python ortamı, aslında kullanılmayan paketler içerebilir, örneğin, bir Python monorepo’sunda birden fazla hizmet geliştirildiğinde ve hem bildirim dosyaları hem de ortamlar tüm hizmetlerin bağımlılıklarının üst kümesini içerdiğinde. Bu en iyi uygulamalara aykırı olabilir, ancak gerçek dünya ortamlarının talihsiz gerçeğidir.
Bu sorunların üstesinden gelmek için kuruluşlar, hem birinci taraf uygulamasının hem de tüm bağımlılıklarının koduna bakarak içe aktarma ifadelerini izlemelerine olanak tanıyan teknolojiyi uygulamalıdır; böylece belirli bir uygulama bağlamında gerçekten önemli olan tüm paketleri bulabilirler.
Kamusal tavsiyeler genellikle daha fazla kod düzeyinde bilgiye ihtiyaç duyar. Bu, yazılım bağımlılıklarını yöneten kuruluşlar için ne gibi etkilere sahiptir?
Kod merkezli SCA çözümleri, savunmasız işlevler veya düzeltme taahhütleri hakkında kod düzeyinde bilgi gerektirir. Bu tür bilgilerin kamu veritabanlarında bulunmaması, ilgili sağlayıcıların kamusal uyarıları zenginleştirmek için tamamlayıcı bir veritabanı bulundurmasını zorunlu kılar ve bu da maliyetli bir uygulamadır.
Kod merkezli SCA çözümlerinin kalitesi, ilgili güvenlik açığı veritabanlarının kalitesine bağlıdır. SCA çözümlerinin kullanıcıları, satıcılara güvenlik açığı veritabanını sürdürme ve kalitesini sağlama konusundaki özel yaklaşımlarının ne olduğunu sormalıdır.
Açık kaynak topluluğunun bakış açısından, kod düzeyinde güvenlik açığı veritabanlarının eksikliği (veya bunların sınırlı kapsamı), rekabetçi açık kaynak çözümlerinin geliştirilmesini zorlaştırmaktadır.
Çoğu sürüm yükseltmesi en azından bir bozucu değişiklik içerir. Kuruluşlar, güvenliği korurken kesintiyi en aza indirmek için bu yükseltmelere nasıl yaklaşmalıdır?
Pek çok sürüm yükseltmesinin, Semver sürümleme kuralına göre geriye dönük uyumlu olması gereken, küçük veya yama sürümleri de dahil olmak üzere, bozucu değişiklikler içerdiği doğrudur.
Ancak, bu bileşenlerin genel kod tabanına göre, bu bozucu değişiklikler genellikle seyrektir, yani müşteriler bunlarla karşılaşmazlar.
Yine de, yalnızca birkaç API’de bile yıkıcı değişiklikler yaşansa, geliştiriciler genellikle yalnızca yükseltme yapıp en iyisini umma riskini göze alamazlar. Ve deneme yanılma yoluyla yükseltme yapmak geliştiriciler için maliyetli, etkisiz ve sinir bozucudur.
Geliştiriciler, bir kütüphanedeki tüm kesinti değişikliklerini bulmalarına ve bunlardan herhangi birinin kendi özel uygulamaları için önemli olup olmadığını kontrol etmelerine olanak tanıyan araçlar uygulamalıdır. Bilinen savunmasız bileşenlerin değerlendirmesini de destekleyen aynı tür çağrı grafiği tabanlı erişilebilirlik analizinden yararlanmalıdırlar.
Teknoloji, bu API’lere herhangi bir çağrı yapılıp yapılmadığını belirleyebilir ve geliştiricilerin alternatif yükseltme yolları aramasına olanak sağlamak için bu tür güncellemeleri “yüksek riskli” olarak işaretleyebilir.
Kuruluşlar, yapay zeka ve makine öğrenimi yazılım proje bağımlılıklarıyla ilişkili riskleri nasıl azaltabilir?
Endor Labs, TensorFlow gibi ML/AI bileşenleri için farklı güvenlik açığı veritabanlarında bildirilen güvenlik açığı sayıları arasında önemli tutarsızlıklar buldu. Ancak bu tutarsızlıklar yalnızca ML/AI bileşenlerini ilgilendirmiyor, bu da bizi yüksek kaliteli güvenlik açığı veritabanları sorununa geri getiriyor.
SCA çözümlerini kullananlar, tedarikçilerine güvenlik açığı bilgilerinin kaynakları ve tamamlayıcı bilgilerin kalitesini (varsa) korumaya yönelik yaklaşımları ve süreçleri hakkında soru sormalıdır.