Açık kaynaklı güvenlik açıkları: Artık her işletme için bir sorun

Yapay zeka alanında yaşanan patlama ve açık kaynak bileşenlere olan bağımlılığın artması, şirketlerin güvenlik yükünü nasıl artırıyor ve bu konuda neler yapabilirsiniz?

Eskiden açık kaynaklı güvenlik açıkları ve tedarik zinciri saldırıları konusunda sadece uzman yazılım şirketleri ve teknoloji devleri endişelenmek zorunda kalırdı. Ama zaman değişti. Günümüzde küçük işletmeler bile kendi yazılım geliştirme birimlerini işletiyor; bu da bu sorunun herkes için önem arz ettiğini gösteriyor. Her iki şirketten birinin iç BT ekipleri, ana faaliyet alanı yazılımla ilgili olmasa bile; kod yazmak, entegrasyonları yapılandırmak ve iş akışlarını otomatikleştirmekle meşgul zira modern iş dünyasının verimliliği bunu gerektiriyor. Ancak bunun bir sonucu olarak, yeni bir tür yazılım güvenlik açığı ortaya çıkıyor ve bu tür güvenlik açıklarını gidermek, sadece en son Windows güncellemesini yüklemekten çok daha karmaşık bir iş.

Modern yazılım geliştirme, açık kaynaklı bileşenlerden ayrı düşünülemez. Ancak, son yıllarda bu konuyla ilgili riskler, hem çeşitlilik hem de karmaşıklık açısından, hızla artmıştır: Popüler depolara kötü amaçlı kodların yerleştirildiğini, güvenlik açığı verilerinin dağınık ve hatalı olduğunu, güncel olmayan ve güvenlik açığı bulunan bileşenlerin sistematik olarak kullanıldığını ve bağımlılık zincirlerinin giderek daha karmaşık hale geldiğini görüyoruz.

Açık kaynaklı güvenlik açığı verilerindeki eksiklik

Kuruluşunuzun üçüncü taraf ticari yazılımlar için son derece sağlam bir güvenlik açığı yönetimi süreci olsa bile, açık kaynak kodun bu sürecin tamamen yeniden düzenlenmesini gerektirdiğini göreceksiniz. Açık kaynak söz konusu olduğunda, en yaygın olarak kullanılan kamuya açık veri tabanları genellikle eksik, hatalı ya da güncellemelerin gelmesi konusunda oldukça yavaştır. Bu durum, güvenlik açıklarının önceliklendirilmesini bir tahmin oyununa dönüştürür. Temel verileriniz eksikliklerle doluysa, ne kadar otomasyon kullanırsanız kullanın bir faydası olmaz.

Sonatype’ın verilerine göre, CVE kimliği atanmış açık kaynaklı güvenlik açıklarının yaklaşık %65’inin, en yaygın olarak kullanılan güvenlik açığı bilgi tabanı olan NVD’de önem puanı (CVSS) bulunmamaktadır. Puanlanmamış bu güvenlik açıklarının yaklaşık %46’sı, doğru bir şekilde analiz edildiğinde aslında “Yüksek” olarak sınıflandırılırdı.

CVSS puanı mevcut olsa bile, farklı kaynaklar önem derecesi konusunda yalnızca yaklaşık %55 oranında aynı görüşte. Bir veri tabanı bir güvenlik açığını “Kritik” olarak işaretlerken, bir diğeri buna “Orta” derecesi verebilir. Etkilenen paket sürümleri gibi daha ayrıntılı meta veriler de genellikle hatalar ve tutarsızlıklarla doludur. Yazılım sürümlerini karşılaştıran güvenlik açığı tarayıcılarınız, hatalı pozitif sonuçlarla boş alarmlar verir ya da size haksız yere her şeyin yolunda olduğu izlenimini yaratır.

Kırılganlık verilerindeki eksiklik giderek artmakta ve raporlama süreci yavaşlamaktadır. Son beş yıl içinde CVE’lerin toplam sayısı iki katına çıkarken, önem puanı bulunmayan CVE’lerin sayısı 37 katına çıktı. Tenable’a göre, 2025 yılına kadar, bir güvenlik açığının keşfedilmesinden itibaren genellikle bir hafta içinde kamuya açık kavram kanıtı (PoC) istismar kodu ortaya çıkmaktaydı; ancak aynı güvenlik açığının NVD’ye eklenmesi ortalama 15 gün sürmekteydi. CVSS puanı atama gibi zenginleştirme süreçleri ise daha da yavaştır. Aynı araştırmada Sonatype, bir CVSS puanı atamak için gereken sürenin ortalamasının 41 gün olduğunu ve bazı kusurların bir yıla kadar derecelendirilmeden kaldığını tahmin etmektedir.

Eski açık kaynak kod sorunu

HeroDevs’e göre, artık desteklenmeyen (terk edilmiş ya da resmi kullanım ömrü (EOL) çoktan dolmuş olan) kütüphaneler, uygulamalar ve hizmetler, kurumsal projelerin %5 ila %15’inde bulunabilir. Beş popüler açık kaynak kod deposunda, bilinen güvenlik açıkları içeren ancak güncel olmayan ve desteklenmeyen sürümlere ait en az 81.000 paket bulunmaktadır. Bu paketler hiçbir zaman resmi yamalar almayacaktır. Bu “eski yük”, Maven Central ve PyPI’daki paketlerin yaklaşık %10’unu, npm’de ise şaşırtıcı bir şekilde %25’ini oluşturmaktadır.

Bu tür açık kaynak kodlarının kullanılması, standart yama yönetimi döngüsünü bozar: Artık desteklenmeyen bir bağımlılığı ne otomatik ne de manuel olarak güncelleyemezsiniz. Ayrıca, kullanım ömrü sona ermiş sürümler resmi güvenlik açığı bültenlerinde yer almadığında, güvenlik tarayıcıları bu sürümleri bir güvenlik açığından “etkilenmemiş” olarak sınıflandırabilir ve göz ardı edebilir.

Bunun en iyi örneği, 2021 yılında ortaya çıkarılan popüler Log4j kütüphanesindeki kritik (CVSS 10) güvenlik açığı olan Log4Shell‘dir. 2025 yılında gerçekleştirilen 300 milyon Log4j indiriminin 40 milyonu, güvenlik açığı bulunan sürüme aitti. Tarihin en kötü şöhretli ve en çok haberlere konu olan güvenlik açıklarından birinden bahsettiğimizi unutmayın. Bu güvenlik açığı aktif olarak istismar edildi, geliştirici tarafından yamalandı ve tüm önemli alt ürünlerde giderildi. Daha az gündeme gelen kusurlar söz konusu olduğunda durum çok daha vahimdir.

Bu sorunu daha da ağırlaştıran şey, görünürlük eksikliğidir. Birçok kuruluş, eksiksiz bir bağımlılık ağacı oluşturmak veya yazılım yığınında yerleşik olan belirli paketler ve sürümler hakkında tam bir görünürlük elde etmek için gerekli araçlara sahip değildir. Sonuç olarak, bu eski bileşenler genellikle gözden kaçar ve düzeltme kuyruğuna hiç girmezler.

Açık kaynak kayıt defterlerindeki kötü amaçlı yazılımlar

Virüs bulaşmış veya doğası gereği zararlı açık kaynaklı paketlerin kullanıldığı saldırılar, yazılım tedarik zincirine yönelik en hızlı büyüyen tehditlerden biri haline gelmiştir. Kaspersky araştırmacılarına göre, 2024 yılı sonuna kadar popüler kayıt defterlerinde yaklaşık 14.000 zararlı paket tespit edildi; bu, bir önceki yıla göre %48’lik bir artışa tekabül etmektedir. Sonatype, 2025 yılı boyunca daha da çarpıcı bir artış kaydettiğini bildirdi; 450.000’den fazla kötü amaçlı paket tespit etti.

Bu saldırıların ardındaki nedenler oldukça çeşitlidir: kripto para hırsızlığı, geliştirici kimlik bilgilerinin ele geçirilmesi, endüstriyel casusluk, CI/CD süreçleri aracılığıyla altyapıya erişim sağlanması veya spam ve kimlik avı saldırı kampanyaları yürütmek amacıyla kamuya açık sunucuların ele geçirilmesi. Bu taktikler hem casus APT grupları hem de maddi çıkar peşinde olan siber suçlular tarafından kullanılır. Son zamanlarda, açık kaynaklı bir yazılım paketinin ele geçirilmesi, çok aşamalı bir kurumsal güvenlik ihlalinin yalnızca ilk adımı haline gelmiş durumdadır.

Yaygın saldırı senaryoları arasında, yasal bir açık kaynaklı paket bakımcısının kimlik bilgilerinin ele geçirilmesi, içine yerleşik kötü amaçlı kod bulunan “kullanışlı” bir kütüphanenin yayınlanması veya popüler bir kütüphaneyle adı neredeyse aynı olan kötü amaçlı bir kütüphanenin yayınlanması sayılabilir. 2025 yılında özellikle endişe verici bir eğilim, otomatikleştirilmiş, solucan benzeri saldırıların artması olmuştur. En bilinen örnek Shai-Hulud saldırı kampanyasıdır. Bu olayda, kötü amaçlı kod GitHub ve npm belirteçlerini çalmış ve yeni paketlere bulaşmaya devam ederek, sonunda 700’den fazla npm paketine ve on binlerce depoya yayılmıştır. Bu süreçte CI/CD gizli bilgileri ve bulut erişim anahtarları kamuya açık hale gelmiştir.

Bu senaryo teknik olarak güvenlik açıklarıyla ilgili olmasa da, bunu yönetmek için gereken güvenlik araçları ve ilkeler, güvenlik açığı yönetiminde kullanılanlarla aynıdır.

Yapay zeka ajanları açık kaynak kod kullanımının risklerini nasıl artırır?

Yapay zeka araçlarının yazılım geliştirme sürecine aceleyle ve her alana yayılmak üzere entegre edilmesi, geliştiricilerin çalışma hızını önemli ölçüde artırır; ancak aynı zamanda hataların etkisini de kat kat artırır. Sıkı bir denetim ve açıkça tanımlanmış sınırlamalar olmadan, yapay zeka tarafından üretilen kod son derece savunmasızdır. Araştırmalara göre, yapay zeka tarafından üretilen kodların %45’i OWASP Top 10 listesindeki güvenlik açıklarını içerirken, kullanıma sunulan yapay zeka tabanlı uygulamaların %20’sinde tehlikeli yapılandırma hataları bulunmaktadır. Bunun nedeni, yapay zeka modellerinin, büyük miktarda güncel olmayan, örnek niteliğinde veya tamamen eğitim amaçlı kodlar içeren devasa veri kümeleriyle eğitilmiş olmasıdır. Bir yapay zeka modeli, bir projeye hangi açık kaynak bileşenlerini dahil edeceğine karar verirken bu sistemik sorunlar yeniden gündeme gelir. Model, genellikle hangi paket sürümlerinin mevcut olduğunu veya hangilerinin güvenlik açığı olduğu belirtildiğini bilmez. Bunun yerine, eğitim verilerinden alınan bir bağımlılık sürümünü önerir ki bu da neredeyse tamamen eskimiş durumdadır. Bazı durumlarda, modeller var olmayan sürümleri çağırmaya çalışır ya da tamamen hayali kütüphaneleri çağırır. Bu durum, bağımlılık karışıklığına dayalı saldırılara kapı açar.

2025 yılında, önde gelen büyük dil modelleri bile vakaların %27’sinde yanlış bağımlılık sürümleri önerdi, yani basitçe uydurma cevaplar verdi.

Yapay zeka her şeyi çözebilir mi?

Bu basit ve cazip bir fikir: Yapay zeka ajanını kod tabanınıza yönlendirin ve her türlü güvenlik açığını bulup düzeltmesine izin verin. Ne yazık ki, yapay zeka bu sorunu tamamen çözemez. Bahsettiğimiz temel engeller, yapay zeka ajanlarını da insan geliştiriciler kadar zorlamaktadır. Güvenlik açığı verileri eksik veya güvenilir değilse, bilinen güvenlik açıklarını tespit etmek yerine, bunları sıfırdan yeniden keşfetmek zorunda kalırsınız. Bu, çoğu işletme için ulaşılamaz olan özel bir uzmanlık gerektiren ve inanılmaz derecede fazla kaynak tüketen bir süreçtir.

Ayrıca, eski veya desteklenmeyen bir bileşende bir güvenlik açığı tespit edildiğinde, bir yapay zeka ajanı bunu “otomatik olarak düzeltemez”. Hâlâ özel yamalar geliştirmeniz veya karmaşık bir geçiş işlemi gerçekleştirmeniz gerekir. Bir kusur, bağımlılık zincirinin derinliklerinde gizlenmişse, yapay zeka bunu tamamen gözden kaçırabilir.

Ne yapmak gerekiyor?

Yukarıda açıklanan riskleri en aza indirmek için, güvenlik açığı yönetimi sürecini açık kaynaklı paket indirme ilkeleri, yapay zeka asistanı çalışma kuralları ve yazılım derleme sürecini de kapsayacak şekilde genişletmek gerekecektir. Örneğin:

• Kapsamlı bir bulut iş yükü güvenlik çözümünden yararlanmak;
• Yazılım geliştirme sürecinizde kullanılan açık kaynak paketlerini, açık kaynak bileşenlerine yönelik tehdit istihbaratı beslemeleriyle karşılaştırmak;
• Yapay zeka kodunu ve yapay zeka ajanlarını korumak için güvenlik önlemlerini değerlendirmek;
• Eski açık kaynaklı bileşenleri sistematik olarak kaldırmak.

Açık kaynak kodlu yazılımların güvenlik açıklarının yönetimi hakkında daha fazla bilgiyi, bu konuyu detaylı şekilde ele aldığımız blog yazımızda bulabilirsiniz.