Zararlı yazılım paketlerinin üretim ortamına erişmesini engelleyin.

---

Bir geliştirici, tek bir şüpheli satır yazmadan projeye kötü amaçlı kod enjekte edebilir. Sadece bir paket yüklemek bile yeterli olabilir. Bağımlılık meşru görünebilir, tanıdık bir isme sahip olabilir, ancak kurulum sırasında istenmeyen kod çalıştırabilir.

Bu durum, uygulamanın üretime geçmesinden çok önce paket güvenliğini bir sorun haline getiriyor. İlk ciddi olay, bir Windows geliştiricisinin iş makinesinde , bir CI çalıştırıcı ortamında veya otomatik bir derleme işlemi sırasında meydana gelebilir. Kontrolleri yalnızca dağıtım aşamasına yakın bir yere yerleştirmek, bu yolun büyük bir kısmını açıkta bırakır.

Tehlike, geliştiricinin cihazından başlar.

Modern projeler, devasa bağımlılık ağaçlarına dayanır. Bir geliştirici kasıtlı olarak on paket kurabilirken, paket yöneticisi otomatik olarak yüzlerce dolaylı bağımlılığı da indirir. Bu zincirdeki her paketi tek tek inceleyen çok az kişi vardır ve bunu manuel olarak yapmak, normal geliştirme sürecini yavaş ve sıkıcı hale getirir.

Saldırganlar bu güveni istismar eder. Bazı kötü amaçlı paketler ortam değişkenlerini, kimlik bilgilerini, tarayıcı verilerini veya kimlik doğrulama belirteçlerini çalmaya çalışır. Diğer paketler ise geliştirici paketi açmadan önce ek bir zararlı yazılım indirir veya kurulum komut dosyaları aracılığıyla kod çalıştırır.

Windows sistemlerinde etkilenen ortam, PowerShell oturumlarını, paket yöneticisi kimlik bilgilerini, SSH anahtarlarını, bulut araçlarını ve mevcut kullanıcı hesabına ait dosyaları içerebilir. WSL, altta yatan tedarik zinciri risklerini ortadan kaldırmak yerine, aynı makineye ek bir geliştirme ortamı ekler.

Zararlı bağımlılık her zaman kötü görünmez.

Paket saldırıları, kötü amaçlı bileşen geliştiricilerin görmeyi beklediği bir şeye benzediğinde tespit edilmesi zordur. Bu giriş noktaları çeşitlilik gösterir:

• Yazım hatasıyla ele geçirme: Bu paket, yaygın olarak kullanılan bir bağımlılıktan yalnızca bir veya iki harf farklı olan bir isim kullanır;
• Bağımlılık karmaşası: Genel bir paket, dahili bir bağımlılıkla çakışabilir ve otomatik bir derleme işlemi tarafından seçilebilir;
• Yönetici hesapları ele geçirildi: Güvenilir bir paket, saldırganın dağıtım ayrıcalıklarını elde etmesinin ardından kötü amaçlı bir sürümle karşılaşır;
• Kötü amaçlı güncellemeler: Daha önce güvenli olan bir proje, daha sonraki bir sürümde davranışını değiştirir ve bu durum şunlara yol açabilir: Bazı işler durdu.؛
• Gizli, geçici sonuçlar: Geliştirici tarafından seçilen paketin altında birden fazla seviyede tehlikeli kod yerleştirilmiştir.

Popülerlik, güvenliğin garantisi değildir. Tehlikeye atılmış bir proje, önceki temiz sürümlerinden yıllarca iyi bir itibar kazanabilirken, yeni bir kötü amaçlı paket, şüpheli davranışlar fark edilmeden önce çok sayıda indirme sayısına ulaşabilir.

Geciken bir sınav çok geç kalmış olabilir.

Birçok ekip zaten bağımlılık kontrolleri yapıyor ve bunlar hâlâ çok önemli. Yazılım bileşen analizi, bilinen güvenlik açıklarını belirleyebilir. Depo tarama araçları, açığa çıkan sırları veya tehlikeli kodları ortaya çıkarabilir. Sürekli Bütünlük Güvenliği (CI) kontrolleri, sorunlu sürümlerin dağıtımını engeller.

Ancak bu kontrollerin neleri önleyebileceğini belirlemede zamanlama çok önemli bir rol oynar.

Bir geliştirici Windows Terminal'de bir kurulum komutu çalıştırdığında ve istenen paket kötü amaçlı bir kurulum betiği içeriyorsa, ilk ciddi Sürekli Bütünlük (CI) kontrolü yapılmadan önce kod yerel olarak çalıştırılabilir. Temiz bir üretim ortamına sahip olmak, derlemenin başladığı makineden kimlik bilgilerinin çalınması olasılığını ortadan kaldırmaz.

Bilinen güvenlik açıklarını taramak tamamen farklı bir soruyu yanıtlar. Bilinen güvenlik sorunlarıyla ilişkili sürümleri bulmada etkilidir , ancak yeni yayınlanan kötü amaçlı bir paketin henüz bir CVE'si veya belgelenmiş bir güvenlik açığı kaydı olmayabilir.

Paketlerin geçişine izin vermeden önce kontrol edilmesi.

Bir yaklaşım, geliştirici veya derleme sistemi ile paket kayıt defteri arasına bir kontrol mekanizması uygulamaktır. Her istenen paketin doğrudan ortama girmesine izin vermek yerine, kontrol mekanizması önce paketi değerlendirir ve şüpheli kriterleri karşılayan yazılımları engelleyebilir.

Bağımlılık güvenlik duvarı kavramının temel fikri budur.

Önemli olan kararın zamanlamasıdır. Bir paket, ortama girdikten sonra sorun olarak keşfedilmek yerine, kurulumdan önce değerlendirilebilir. Göstergeler arasında şüpheli dağıtım modelleri, yeni oluşturulan paketlerin mevcut paketleri taklit etmesi veya daha fazla araştırma gerektiren diğer davranışlar yer alabilir.

Ancak bu, kontrol mekanizmasını hatasız yapmaz. Yanlış pozitifler de önemlidir. Yeni yayınlanan paketler meşru olabilir ve olağandışı dağıtım etkinliği otomatik olarak kötü niyetli anlamına gelmez. Paket kontrolleri sürekli olarak meşru güncellemeleri kesintiye uğratırsa , geliştiriciler bunları atlatmanın yollarını aramaya başlayabilirler.

Windows geliştirme kendi zayıf yönlerini de beraberinde getiriyor.

Windows geliştirme ortamlarında genellikle Git, Node.js, Python, PowerShell, Visual Studio Code, Docker Desktop, WSL, bulut komut satırı araçları (CLI'lar) ve yerel olarak depolanan kimlik bilgileri tek bir iş istasyonunda bir araya getirilir. Bu durum, paket riski açısından hesap izinlerini ve yerel güvenliği kritik hale getirir.

Birkaç basit seçim, olası saldırı alanını azaltabilir:

• Rutin geliştirme faaliyetlerini mümkün olduğunca idari olmayan hesaplar altında tutun;
• Tanımadığınız kurulum komutlarını yükseltilmiş PowerShell ayrıcalıklarıyla çalıştırmaktan kaçının;
• Üretim kimlik bilgilerini yerel geliştirici kimlik bilgilerinden ayırın;
• Ani bir şekilde kurulum veya kurulum sonrası komut dosyaları ekleyen paketleri kontrol edin;
• Henüz güven kazanmamış programlar için izole ortamlar kullanın.

Windows güvenlik özellikleri işletim sistemi düzeyinde yardımcı olabilir, ancak bağımlılık ağacındaki her üçüncü taraf paketin belirli bir projeye ait olup olmadığını belirleyemezler.

Kilit dosyaları yardımcı olur, ancak neyin güvenli olduğunu belirleyemezler.

Kilit dosyaları, paket sürümlerini daha tahmin edilebilir hale getirir ve kurulumlar arasındaki beklenmedik değişiklikleri azaltır. Ancak, kilitli sürümün kendisinin zararlı olup olmadığı sorusuna cevap vermezler.

Tek başına kullanıldığında diğer kontroller için de aynı sınırlama geçerlidir. Sürüm sabitleme tutarlılık sağlar. Kod incelemesi, geliştiricilerin zaten görebildiği değişiklikleri tespit eder. Güvenlik açığı taraması bilinen zayıf noktaları bulur. Uç nokta koruması, cihazdaki etkinliği izler.

Ekipler ayrıca dahili paketleri dağıtmak, terk edilmiş bağımlılıkları kaldırmak, Kilit Dosyası değişikliklerini izlemek, gereksiz kurulum komut dosyalarını kısıtlamak ve kritik üçüncü taraf projelerinin sahipliğindeki ani değişiklikleri araştırmak için çok faktörlü kimlik doğrulama (MFA) talep edebilirler.

En sağlam yaklaşım çok katmanlı bir yaklaşımdır. Tek bir kontrol, paket kayıt defterinden geliştirici makinesine, derleme sistemine ve üretim ortamına kadar tüm yolu kapsamaz.

Paketin teslimatını mümkün olan en erken noktada durdurun.

Üretim güvenliği, üretim aşamasının kendisinden önce başlar. Zararlı bir bağımlılık yayınlanan bir sürümde ortaya çıktığında, geliştiricilerin dizüstü bilgisayarlarından, paket önbelleklerinden, derleme sistemlerinden ve sürekli entegrasyon (CI) altyapısından çoktan geçmiş olabilir.

Paket kontrollerini kurulum sürecine daha yakın bir yere taşımak, sonraki kontrollerin gerekliliğini ortadan kaldırmadan bu süreyi kısaltır. Windows tabanlı ekipler için iş istasyonu güvenliği çok önemlidir çünkü geliştirme cihazları genellikle kaynak koduna, kimlik bilgilerine, bulut araçlarına ve dahili sistemlere yakın konumdadır.

Pratik soru, tek bir aracın her paketin güvenliğini garanti edip edemeyeceği değil, geliştirme sürecinin asla çalışmasına izin verilmemesi gereken bir paketi ne kadar hızlı reddedebileceğidir.