Yazılım tedarik zinciri güvenliği: bağımlılıklar şirketinizi nasıl riske atar?

Yazılım tedarik zinciri güvenliği, kendi yazdığınız kodu değil, o kodun içine aldığınız başkalarının kodunu korumakla ilgilidir. Modern bir uygulamada üretimde çalışan satırların büyük çoğunluğu sizin ekibinizden değil; açık kaynak kütüphanelerden, çerçevelerden ve bunların bağımlılıklarından gelir. npm install ya da pip install yazdığınızda aslında hiç tanımadığınız onlarca, çoğu zaman yüzlerce geliştiricinin koduna güveniyorsunuz. Tedarik zinciri saldırısı da tam bu güveni hedef alır: saldırgan sisteminize doğrudan girmek yerine, sizin zaten kullandığınız bir bileşene bulaşır ve siz onu güncellediğinizde zararlı kod kapıdan davetli olarak girer. Korunmanın özü üç alışkanlıktır: neye bağımlı olduğunuzu bilmek, bu bağımlılıkları sürekli denetlemek ve derleme hattınızı kilitlemek.

Bu tehdit artık teorik değil. OWASP, en çok başvurulan web uygulaması risk listesi olan Top 10'un 2025 sürümünde "Yazılım Tedarik Zinciri Hataları"nı doğrudan üçüncü sıraya (A03) yerleştirdi. Önceki listede "güncel olmayan bileşenler" başlığıyla daha dar tanımlanan bu risk, artık yalnızca eski kütüphaneleri değil; derleme sistemlerini, paket depolarını ve dağıtım altyapısını da kapsayacak biçimde genişletildi. Listeyi hazırlayan topluluk anketinde katılımcıların yarısı bu riski bir numaralı endişe olarak işaretledi. Sebebi basit: paylaşılan tek bir bileşendeki tek bir zafiyet, binlerce şirkete aynı anda ulaşabiliyor.

En bilinen örnek 2020'deki SolarWinds olayı. Saldırganlar, kurumların ağ izleme için kullandığı Orion yazılımının güncelleme paketine sessizce zararlı kod yerleştirdi. Sonuç: yaklaşık 18.000 kurum, resmi ve imzalı görünen bu güncellemeyi kendi elleriyle kurdu. Kod, şirketlerin kendi güvenilir çeperlerinin içinden geldiği için hiçbir güvenlik duvarı onu durduramadı. Buradaki ders akılda kaldı: güvendiğiniz bir satıcının imzalı güncellemesi bile artık sorgusuz kabul edilecek bir şey değil.

İkinci örnek, tek bir kütüphanenin ne kadar yaygın olabileceğini gösteriyor. Aralık 2021'de Java dünyasında neredeyse her yerde kullanılan log4j adlı günlükleme kütüphanesinde Log4Shell (CVE-2021-44228) açığı ortaya çıktı. CVSS puanı, alınabilecek en yüksek değer olan 10'du. Sömürülmesi o kadar kolaydı ki bir metin kutusuna yapıştırılan tek bir satır, uzaktan kod çalıştırmaya yetebiliyordu. Etkilenen sistem sayısının yüz milyonları bulabileceği tahmin edildi. Çoğu şirket o kütüphaneyi kullandığını bile bilmiyordu, çünkü log4j satın aldıkları başka bir ürünün bağımlılığının bağımlılığıydı.

Üçüncü örnek işin ne kadar sabırlı ve planlı olabileceğini gösteriyor. Mart 2024'te, Linux dağıtımlarının çoğunda bulunan xz-utils sıkıştırma aracına arka kapı (CVE-2024-3094) yerleştirildiği ortaya çıktı. Saldırgan doğrudan hiçbir şeyi hacklemedi; "Jia Tan" takma adıyla yaklaşık iki yıl boyunca projeye gönüllü katkı sundu, güven kazandı, sonunda bakım yetkisi aldı ve arka kapıyı yavaşça kodun içine sızdırdı. Kapı, sunuculara SSH ile uzaktan erişim sağlıyordu. Neredeyse tesadüfen yakalandı: bir Microsoft mühendisi, SSH bağlantılarının normalden birkaç saniye yavaş açıldığını fark etti ve arka kapı, yaygın dağıtımların kararlı sürümlerine ulaşmadan günler önce durduruldu.

Halka açık paket depoları da doğrudan hedef. Saldırganlar, popüler bir paketin adına bir harf uzaklıktaki sahte paketler yükleyip yazım hatası yapan geliştiricileri avlıyor (typosquatting). Bir başka teknik, paketin kurulumu sırasında otomatik çalışan "post-install" betiklerini kullanarak makinedeki gizli anahtarları ve token'ları çalmak. 2025'te ortaya çıkan Shai-Hulud adlı zararlı, npm ekosisteminde kendi kendine yayılan ilk solucan oldu: bulaştığı makinede bulduğu npm token'larını kullanarak başka paketlerin zararlı sürümlerini kendiliğinden yayınladı ve durdurulmadan önce 500'den fazla paket sürümüne ulaştı.

Önce neye bağımlı olduğunuzu bilin

Koruyamadığınız şeyin ilk şartı onu görebilmektir. Uygulamanızın hangi kütüphanelere hangi sürümlerle bağlı olduğunu listeleyen bir yazılım bileşen envanteri (SBOM, Software Bill of Materials) çıkarın. Log4Shell krizinde en hızlı toparlanan şirketler, "log4j'yi nerede kullanıyoruz?" sorusuna dakikalar içinde cevap verebilenlerdi; envanteri olmayanlar günlerce kör aradı. Bu listede, doğrudan yüklediğiniz paketlerin altında yatan dolaylı bağımlılıkların da yer alması gerekir, çünkü riskin çoğu tam orada saklanır.

Sürümleri sabitleyin ve sürekli tarayın

Bağımlılık sürümlerini sabitleyin ve kilit dosyalarını (package-lock.json, poetry.lock, go.sum gibi) kod deponuza dahil edin; böylece bugün derlediğiniz kod ile yarın derlediğiniz kod birebir aynı bileşenlerden oluşur. Ardından bu bağımlılıkları otomatik tarayan bir araç kurun. GitHub'ın Dependabot'u, npm audit ya da OWASP Dependency-Check gibi yazılım bileşim analizi (SCA) araçları, kullandığınız bir kütüphanede bilinen bir açık yayınlandığında sizi anında uyarır. Bu uyarıları kimsenin bakmadığı bir bilet kuyruğuna değil, düzenli bir yama sürecine bağlayın.

Derleme hattını kilitleyin, bağımlılığı azaltın

Shai-Hulud örneğinin gösterdiği gibi, saldırganların asıl istediği derleme ortamınızdaki token'lar ve gizli anahtarlardır. Sürekli entegrasyon (CI/CD) hattınıza yalnızca ihtiyaç duyduğu asgari yetkiyi verin, yayın token'larını dar kapsamlı tutun ve mümkün olduğunda betiklerin internete serbestçe çıkmasını kısıtlayın. Aynı zamanda bağımlılık sayınızı bilinçli tutun: üç satırlık bir iş için koca bir kütüphane eklemeden önce iki kez düşünün. Az sayıda, iyi bakılan ve arkasında geniş bir topluluk olan kütüphaneler, terk edilmiş ya da tek kişinin sürdürdüğü paketlerden daha güvenlidir.

Burada ince bir denge var. Bilinen açıklar için yamayı hızlı geçmek gerekir, ama xz ve Shai-Hulud örnekleri en yeni sürümün de zararlı olabileceğini gösterdi. Pratik orta yol, yeni çıkan bir sürümü üretime almadan önce ona kısa bir bekleme süresi tanımak ve otomatik güncellemeleri gözü kapalı birleştirmek yerine gözden geçirmektir.

Wedevit olarak kullandığınız yazılımın bağımlılık haritasını çıkarabilir, bir SBOM ve otomatik tarama sürecini kurabilir, derleme hattınızın yetkilerini asgariye indirebilir ve yeni bir Log4Shell çıktığında "bizde var mı?" sorusuna dakikalar içinde cevap verebileceğiniz bir düzen bırakabiliriz. Kendi kodunuz kadar, ona güvenerek eklediğiniz kodu da görünür kılmak, bugün atılabilecek en somut adımlardan biri.