npm Kurulumu Güvenli mi? Paket Çalışmaya Başlayınca Neler Oluyor?

Yazılım geliştirme süreçlerinde bağımlılıkların yönetimi, npm gibi paket yöneticileri sayesinde kolaylaşsa da, npm paket güvenliği katmanları her zaman beklendiği kadar sağlam olmayabiliyor. Yıllarca, kötü niyetli npm paketlerinin en bilinen giriş noktalarından biri, paketlerin kurulum öncesi veya sonrası çalıştırdığı betiklerdi. Bu yaşam döngüsü betiklerinin engellenmesi, geliştiriciler için makul bir savunma mekanizması oluşturmuş, belirli türdeki tehditleri ortadan kaldırmıştı. Ancak bir paketin sistemde var olması ile uygulamanın onu kullanması arasındaki fark, güvenlik analizlerinde sıkça göz ardı edilen kritik bir boşluk bırakıyor. Yakın zamanda ortaya çıkan `indexed-btree` kampanyası, bu boşluğun ne denli tehlikeli olabileceğini somut bir biçimde gözler önüne serdi.

npm Kurulum Betikleri ve Yanıltıcı Güvenlik Algısı

Geliştiriciler arasında yaygın bir inanış, `package.json` dosyasında tanımlanan `pre-install` veya `postinstall` gibi yaşam döngüsü betiklerinin kontrol altında tutulmasıyla npm bağımlılıklarının güvende olacağı yönündeydi. Bu betikler, bir geliştirici bağımlılığı kullanmak için tek bir kod satırı yazmadan önce bile çalışabilir ve potansiyel olarak sisteme zarar verebilirdi. Bu nedenle, npm’in `ignore-scripts` ayarı gibi mekanizmalar, kurulum sırasında bu betiklerin çalışmasını engelleyerek belirli bir güvenlik seviyesi sunmuştur. Kuşkusuz, kurulum anında zararlı kod çalıştırılmasını engellemek mantıklı bir savunma stratejisidir.

Bu yaklaşım, paketlerin sırf kurulduğu için kötü amaçlı davranış sergilemesinin önüne geçer. Fakat bir paketin bir uygulamadaki ömrü yalnızca kurulumla başlamaz; uygulamanın başlatılmasıyla ve paketin işlevlerinin çağrılmasıyla gerçek riskler ortaya çıkar. Kurulum anında kusursuz görünen bir paket, uygulamanın onu kullanmaya başlamasıyla birlikte son derece tehlikeli hale gelebilir. Buradaki temel ayrım, yazılım tedarik zinciri güvenliğinin karmaşıklığını ve çok katmanlılığını anlamanın anahtarıdır.

Çalışma Zamanı Enjeksiyonlarının Gizli Mekanizması

Checkmarx Zero tarafından yakın zamanda tespit edilen `indexed-btree` adlı kötü amaçlı npm paketi, bu yeni nesil tehdidin işleyişini detaylandırıyor. Meşru `sorted-btree` kütüphanesini taklit eden bu paket, kurulum anında herhangi bir kötü niyetli betik çalıştırmadı. Zararlı yükleyici kodu, uygulamanın normal kullanımı sırasında çağıracağı bir yöntem olan `BTree.prototype.set` içine yerleştirilmişti. Raporlanan tetikleyici mekanizma, belirli bir anahtar değerini kontrol ediyor ve ardından ayrı bir Node sürecinde şifrelenmiş bir dosyayı başlatıyordu.

Bu durum, paketin sadece kurulmasının veya sadece içeri aktarılmasının kötü amaçlı davranışı tetiklemediğini gösteriyor. Uygulamanın, paketin ilgili yöntemine ulaşması ve belirlenen koşulun sağlanması gerekiyordu. Bu tür bir tasarım, güvenlik taramalarını ve manuel kod incelemelerini çok daha zorlu hale getirir. Zararlı kodun işlevsel bir metodun içine gizlenmesi ve belirli bir çalışma zamanı koşuluna bağlanması, geleneksel güvenlik kontrollerinin ötesine geçmeyi gerektiren yeni bir meydan okumadır. Özellikle anahtar değerinin veya ikinci aşama mekanizmasının detayları, olay müdahale ekipleri için kritik öneme sahiptir.

Uygulama İzinlerinin Kötüye Kullanımı ve Gizli Veri İhlalleri

Bir npm paketi, bir uygulamaya entegre edildiğinde, uygulamanın sahip olduğu tüm izinlerle, ortam değişkenleriyle, ağ erişimiyle ve verilerle birlikte çalışır. Bu, potansiyel bir saldırgan için kurulum ortamından çok daha değerli bir hedef haline gelir. Geliştiricinin makinesinde bulut kimlik bilgileri bulunabilirken, bir sürekli entegrasyon (CI) işi sürüm belirteçlerine sahip olabilir. Üretim hizmetleri ise müşteri kayıtlarına veya dahili API’lere erişebilir. Paketin sahip olduğu kesin erişim düzeyi, her ortamın nasıl yapılandırıldığına bağlıdır.

Fakat genel olarak paket, kendisini çağıran sürecin sahip olduğu ayrıcalıklarla çalışır. Eğer süreç bir sırrı okuyabiliyor veya bir ağ bağlantısı açabiliyorsa, güvenilmeyen bağımlılık kodu da aynı şeyleri yapabilir. Bu durum, yalnızca kurulum anındaki güvenlik kontrollerinin ne kadar yetersiz kaldığını gösterir. Kötü amaçlı bir paket, uygulamanın hassas verilerine erişebilir, bunları dışarı sızdırabilir veya iç sistemlerde daha fazla hasara yol açabilir. Bu nedenle, bağımlılıkların yalnızca kurulum anında değil, aynı zamanda uygulama yaşam döngüsünün her aşamasında dikkatle incelenmesi bir zorunluluktur.

Bağımlılık Güvenliğine Bütünsel Bir Bakış: Yalnızca Kurulum Yeterli Değil

Güvenlik ekiplerinin kurulum betiklerini devre dışı bırakması, kurulum sürecini belirli ve ölçülebilir bir şekilde daha güvenli hale getirir. npm’in `ignore-scripts` ayarı, `package.json` içinde tanımlanan betiklerin kurulum sırasında çalışmasını engellerken, npm aynı zamanda kurulum zamanı betiklerini onaylamak için başka kontroller de sunar. Ancak bu mekanizmaların hiçbiri, bir kütüphanenin çalışma zamanı kodunun her dalını incelediğini iddia etmez. Bazen sessiz bir kurulumun temiz bir bağımlılık anlamına geldiğini düşünürüz, ancak bu büyük bir yanılgıdır. Bir paket, `package.json` içinde bir “scripts” alanı içermese bile yürütülebilir koddur.

Uygulama onu başlangıçta yükleyebilir, bir istek işleyicide çağırabilir veya CI kimlik bilgilerine erişimi olan bir derleme aracında çalıştırabilir. Saldırgan, en faydalı anı seçme özgürlüğüne sahiptir. En az üç farklı anı dikkate almak gerekir: kurulum, modül yükleme ve sıradan fonksiyon çağrıları. Bu anların her biri farklı riskler taşır ve farklı testler gerektirir. Bazı kötü amaçlı paketler modül yükleme anında çalışırken, diğerleri bir fonksiyon çağrısını, belirli bir argümanı, bir ortam değişkenini veya uygulamanın ömrünün daha sonraki bir noktasını bekler. `indexed-btree` paketi, bu son gruba dahildir. Yalnızca kurulum betiklerini kontrol eden bir tarama, hikayenin sadece bir anına bakmak ve onu tüm hikaye olarak değerlendirmek demektir.

Yazılım Tedarik Zincirinde Güvenin Yeniden Tanımlanması

Bir bağımlılık genellikle, sıradan testleri atlatmak için beklenen kütüphaneye yeterince benzemeli ve öyle davranmalıdır. Kopyalanmış bir API, makul görünen bir depo ve çalışan bir “mutlu yol” (happy path), bir ikamenin rutin görünmesini sağlayabilir. Geliştiriciler ihtiyaç duydukları davranışları incelerken, kötü amaçlı davranışlar nadir bir yol üzerinde veya projenin normalde ulaşmadığı bir koşulun arkasında gizlenebilir. Bu durum, yazılım tedarik zinciri güvenliğine yönelik yaklaşımımızı kökten değiştirmemiz gerektiğini gösteriyor. Geliştiriciler ve güvenlik uzmanları, artık sadece paketin kurulumunu değil, aynı zamanda çalışma zamanı davranışlarını da derinlemesine analiz etmeli.

Bu, statik kod analizinin ötesine geçerek dinamik analiz araçlarının, davranışsal izlemenin ve runtime uygulama kendini koruma (RASP) çözümlerinin entegrasyonunu gerektirebilir. Güven, yalnızca bir paketin nasıl yüklendiğiyle değil, aynı zamanda uygulamanın onu gerçek dünya koşullarında nasıl kullandığıyla da inşa edilmelidir. Tedarik zinciri güvenliği, çok yönlü bir stratejiyle ele alınmalı ve her potansiyel saldırı vektörü için uygun savunma mekanizmaları geliştirilmelidir.