Bağımlılık Zinciri Saldırıları: Paketleri Güvenle Kullanmak

Bağımlılık zinciri saldırıları, son yılların en hızlı büyüyen tehdit sınıfı. Sebebi basit: modern bir web uygulamasında çalışan kodun büyük kısmını o uygulamanın geliştiricileri yazmaz. Küçük bir projede bile bağımlılık ağacı yüzlerce pakete ulaşır ve bunların çoğu, doğrudan seçmediğiniz alt bağımlılıklardır. Saldırgan için bu, tek tek uygulamaları hedeflemek yerine hepsinin ortak kullandığı bir paketi ele geçirmenin çok daha verimli olduğu anlamına gelir.

Saldırı biçimleri

Yazım hatası avcılığı (typosquatting)

Popüler bir paketin adına çok benzeyen bir isimle kötü niyetli paket yayınlanır. Geliştirici bir harf yanlış yazdığında veya adı yanlış hatırladığında zararlı paket kurulur. Bu paketler genellikle gerçek paketin işlevini de yerine getirir, böylece fark edilmeleri gecikir.

Ele geçirilmiş bakımcı hesabı

Meşru ve yaygın kullanılan bir paketin bakımcısının hesabı ele geçirilir; ardından zararlı kod içeren yeni bir sürüm yayınlanır. Paket adı doğrudur, kaynağı doğrudur, imzası doğrudur — yalnızca içeriği değişmiştir. Bu, tespiti en zor biçimdir.

Bağımlılık karışıklığı (dependency confusion)

Şirket içi özel bir paket adıyla aynı isimde, daha yüksek sürüm numaralı bir paket genel kayıt defterine yüklenir. Paket yöneticisi yapılandırması gevşekse, iç paket yerine dışarıdaki sahtesini indirir.

Kurulum betikleri

Birçok paket yöneticisi, kurulum sırasında paketin kendi betiklerini çalıştırmasına izin verir. Bu, zararlı kodun sizin kodunuz hiç çalışmadan, sadece install komutuyla çalışabilmesi demektir — üstelik çoğu zaman geliştiricinin makinesinde, kimlik bilgilerine erişimi olan bir bağlamda.

Somut önlemler

1. Kilit dosyasını ciddiye alın

Kilit dosyası (composer.lock, package-lock.json), her paketin tam sürümünü ve içerik özetini (hash) kaydeder. Bu dosya sürüm kontrolünde olmalı ve üretim kurulumları kilit dosyasından yapılmalıdır. Kilit dosyası yoksa, aynı komut farklı zamanlarda farklı kod kurar — ve bu, ele geçirilmiş bir sürümün sessizce sisteme girmesinin en kolay yoludur.

Üretim kurulumlarında composer install (kilit dosyasına sadık) kullanılmalı, composer update (sürümleri tazeleyen) asla dağıtım sırasında çalıştırılmamalıdır.

2. Otomatik güncellemeyi doğru ayarlayın

Burada bir ödünleşim vardır: güncelleme yapmamak bilinen açıklara maruz kalmak, körü körüne güncellemek ise ele geçirilmiş sürümü hemen almak demektir. Dengeli yaklaşım şudur: güvenlik yamalarını hızlı uygulayın, ana sürüm geçişlerini gözden geçirerek yapın ve yeni yayınlanan sürümler için kısa bir bekleme süresi tanımlayın. Kötü niyetli sürümlerin çoğu, yayınlandıktan sonraki ilk gün içinde fark edilip kaldırılır; birkaç günlük gecikme bu riskin önemli kısmını eler. Güncellemeleri ertelemenin öbür yöndeki maliyeti için sürüm yükseltme yazımıza bakabilirsiniz.

3. Kurulum betiklerini kısıtlayın

Sürekli entegrasyon ortamında ve mümkünse geliştirici makinelerinde kurulum betiklerini varsayılan olarak kapatın, yalnızca gerçekten ihtiyaç duyan paketler için açın. Bu tek ayar, en yaygın saldırı yüzeyini büyük ölçüde kapatır.

4. Taramayı hatta ekleyin

Bilinen açıkları tarayan araçları (composer audit, npm audit veya bağımsız tarayıcılar) sürekli entegrasyon hattına ekleyin. Kritik seviyedeki bir bulgunun birleştirmeyi durdurması makul bir kuraldır. Bu hattın kendisinin de güvenliğinin sağlanması gerektiğini unutmayın; pipeline güvenliği yazımız bu konuyu ele alıyor.

5. Bağımlılık sayısını azaltın

En etkili önlem, teknik değil kültürel: her yeni bağımlılık kalıcı bir yükümlülüktür. Birkaç satırla yazılabilecek bir işlev için paket eklemek, kendi kod tabanınıza tanımadığınız bir bakımcı eklemek anlamına gelir. Yeni bir paketi eklemeden önce sorulacak sorular için bağımlılık değerlendirme kontrol listemiz pratik bir çerçeve sunuyor.

Ne kullandığınızı bilmek: yazılım malzeme listesi

Bir açık duyurulduğunda sorulacak ilk soru şudur: "Biz bu paketi kullanıyor muyuz?" Bu soruyu dakikalar içinde cevaplayamayan ekipler, saatlerini bağımlılık ağacında arama yaparak geçirir. Yazılım malzeme listesi (SBOM), tam olarak bu sorunu çözer: hangi sürümde neyin kurulu olduğunun makine tarafından okunabilir bir dökümüdür. Her yayında otomatik üretilip saklanması, olay anında büyük hız kazandırır.

Geliştirici makinesi de bir üretim ortamıdır

Bağımlılık saldırılarının hedefi çoğu zaman sunucunuz değil, geliştiricinin dizüstü bilgisayarıdır. Orada bulut anahtarları, veritabanı erişim bilgileri, imzalama anahtarları ve sürüm kontrol jetonları vardır. Bu yüzden kimlik bilgilerini ortam değişkeni dosyalarında düz metin tutmamak, kısa ömürlü jetonlar kullanmak ve geliştirme ortamında üretim erişimini varsayılan olarak kapalı tutmak, bağımlılık güvenliğinin ayrılmaz parçasıdır. Uygulama katmanındaki diğer yaygın açıklar için güvenlik açıkları yazımıza bakabilirsiniz. Konunun kapsamlı çerçevesi için OWASP Top Ten güncel bir başvuru kaynağıdır.

Sonuç

Bağımlılık zinciri saldırıları, kendi kodunuzu ne kadar dikkatli yazdığınızdan bağımsız olarak sizi etkileyebilen bir risk sınıfıdır — çünkü saldırı yüzeyi sizin yazmadığınız koddadır. Korunmanın yolu paranoyaklık değil, birkaç yapısal alışkanlıktır: kilit dosyasına sadık kurulum, kurulum betiklerinin kısıtlanması, hatta entegre edilmiş açık taraması, ölçülü bir güncelleme politikası ve en önemlisi, gerçekten ihtiyaç duyulmayan paketlerin hiç eklenmemesi. Bugün projenizde tek bir komut çalıştırın ve kaç paketin kurulu olduğuna bakın; çoğu ekip bu sayıyı ilk kez gördüğünde riski de ilk kez somut olarak fark eder.