Paket Bağımlılıklarını Güvenlik Açıkları İçin Denetleme: NuGet ve npm ile Uçtan Uca Rehber

Modern yazılım projeleri, yüzlerce hatta binlerce açık kaynak pakete dayanıyor. Bu paketlerden birindeki küçük bir güvenlik açığı bile veri sızıntısı, yetkisiz erişim veya servis kesintisi gibi ciddi sonuçlara yol açabiliyor. Bu yazıda, .NET (NuGet) ve JavaScript/Node.js (npm) projelerinde paket bağımlılıklarını güvenlik açıkları için nasıl denetleyeceğinizi, hangi araçları kullanmanız gerektiğini ve sonuçları nasıl yorumlayıp aksiyona dönüştüreceğinizi adım adım ele alacağız. Teknik detaylara girerken, teknik olmayan karar vericilerin de anlayabileceği açıklamalar sunacağız.

Güvenlik Denetimi (Security Audit) Nedir ve Neden Önemlidir?

Güvenlik denetimi, projenizde kullandığınız paketlerin ve bu paketlerin bağımlılıklarının bilinen güvenlik açıkları açısından taranmasıdır. Amaç sadece zafiyetleri bulmak değil, risk seviyesini anlamak ve uygulanabilir çözüm yollarını belirlemektir.

Bir güvenlik denetimi ile:

• Hangi pakette hangi güvenlik açığının bulunduğunu,
• Açığın şiddet seviyesini (low, moderate, high, critical),
• Hangi paket zinciri (transitive dependency) üzerinden projeye girdiğini,
• Hangi sürüme güncelleyerek veya hangi değişikliği yaparak sorunu çözebileceğinizi

görebilirsiniz.

Kompanse Yazılım gibi profesyonel yazılım ekipleri, bu denetimleri sadece ilk geliştirme aşamasında değil, CI/CD süreçlerinin ayrılmaz bir parçası olarak sürekli çalıştırır. Çünkü güvenlik açıkları, paket yayınlandıktan aylar hatta yıllar sonra bile keşfedilebilir.

NuGet ile Paket Güvenlik Denetimi (Auditing) – .NET Ekosistemi

NuGet Audit Nasıl Çalışır?

NuGet, .NET projelerinde paket güvenlik denetimi için yerleşik bir audit mekanizması sunar. Temel mantık şudur:

• dotnet restore veya IDE üzerinden paket geri yükleme (restore) yapıldığında,
• Projede kullanılan paketler, tanımlı audit sources üzerinden bilinen zafiyet veritabanı ile karşılaştırılır,
• Bulunan güvenlik açıkları için NU1900-NU1905 gibi uyarı kodları üretilir.

NuGet, varsayılan olarak GitHub Advisory Database gibi kaynaklardan beslenen bir zafiyet veritabanı kullanır. Bu sayede, paket yazarları veya güvenlik araştırmacıları yeni bir açık raporladığında, denetimleriniz bunu kısa sürede yakalayabilir.

Audit Sources (Denetim Kaynakları) Tanımlama

Güvenlik denetiminde kullanılacak kaynakları NuGet.Config dosyasındaki <auditSources> elemanı ile tanımlayabilirsiniz. Örneğin sadece nuget.org'un zafiyet veritabanını kullanmak için:

<configuration>
  <auditSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </auditSources>
</configuration>

Bu yapılandırma, paketlerinizi başka bir iç kurumsal feed'den indirseniz bile, zafiyet kontrolünü nuget.org üzerinden yapmanıza olanak tanır. Böylece paket kaynağını tekilleştirip, güvenlik denetimini esnek bırakabilirsiniz.

MSBuild ile NuGet Audit Davranışını Yapılandırma

Audit davranışını proje veya depo (repository) seviyesinde MSBuild özellikleri ile özelleştirebilirsiniz. Örneğin .csproj veya Directory.Build.props dosyanıza şu ayarları ekleyebilirsiniz:

<Project>
  <PropertyGroup>
    <!-- Audit'i tamamen aç/kapat -->
    <NuGetAudit>true</NuGetAudit>

    <!-- Hangi bağımlılıkların denetleneceği: direct (sadece doğrudan), all (tüm zincir) -->
    <NuGetAuditMode>all</NuGetAuditMode>

    <!-- Minimum raporlanacak seviye: low, moderate, high, critical -->
    <NuGetAuditLevel>moderate</NuGetAuditLevel>
  </PropertyGroup>
</Project>

Önemli nokta: .NET 10 ve üzerini hedefleyen projelerde NuGetAuditMode varsayılan olarak all gelir; yani doğrudan ve transitif tüm bağımlılıklar denetlenir.

Uyarı Kodları (NU1900–NU1905) ve Anlamları

NuGet denetimi sırasında aşağıdaki uyarı kodları ile karşılaşabilirsiniz:

• NU1900: Zafiyet bilgisini alırken paket kaynağıyla iletişim hatası.
• NU1901: Düşük seviye (low) zafiyet içeren paket bulundu.
• NU1902: Orta seviye (moderate) zafiyet içeren paket bulundu.
• NU1903: Yüksek seviye (high) zafiyet içeren paket bulundu.
• NU1904: Kritik seviye (critical) zafiyet içeren paket bulundu.
• NU1905: Tanımlı bir audit kaynağı zafiyet veritabanı sağlamıyor.

CI ortamında, yüksek ve kritik seviyedeki zafiyetleri derleme hatasına dönüştürmek iyi bir pratiktir. Bunu MSBuild ile şu şekilde yapabilirsiniz:

<PropertyGroup>
  <!-- Sadece high ve critical seviyeleri hataya çevir -->
  <WarningsAsErrors>$(WarningsAsErrors);NU1903;NU1904</WarningsAsErrors>
</PropertyGroup>

Belirli Güvenlik Tavsiyelerini (Advisory) Bastırma

Bazen bir güvenlik tavsiyesinin sizin senaryonuz için geçerli olmadığını, riskin kabul edilebilir olduğunu veya kısa vadede çözülemeyeceğini düşünebilirsiniz. Bu durumda, ilgili advisory'yi NuGetAuditSuppress ile bastırabilirsiniz:

<ItemGroup>
  <NuGetAuditSuppress Include="https://github.com/advisories/XXXX" />
</ItemGroup>

Bu mekanizma, özellikle büyük kurumsal kod tabanlarında, bilinen ama kontrollü riskleri yönetmek için kullanışlıdır. Ancak son çare olarak değerlendirilmelidir; çünkü aynı advisory'yi paylaşan başka paketlerdeki zafiyetleri de gizleyebilir.

NuGet ile Güvenlik Açığı Bulunduğunda Ne Yapmalı?

Bir zafiyet raporlandığında, atılacak adımlar genellikle şu sırayı izler:

1. Paket güncellemesi mevcut mu? – Varsa, öncelikle ilgili paketi güvenli sürüme güncelleyin.
2. Transitif bağımlılık mı? – Zafiyet doğrudan değil, zincirdeki bir pakette olabilir.
3. En yakın üst paketi güncelleyin. – Önce top-level paketi, sonra bir üst bağımlılığı, en son doğrudan zafiyetli paketi referans alın.

Örneğin:

• Projeniz paket A'ya referans veriyor.
• A, pakete B bağımlı.
• B de pakete C bağımlı.
• C 1.0.0'da bilinen bir zafiyet var, 2.0.0'da düzeltilmiş.

Bu durumda önerilen yaklaşım:

1. Önce A'yı güncelleyin.
2. Olmazsa B'yi güncelleyin.
3. Yine çözülmezse C'yi doğrudan referans alarak güvenli sürüme sabitleyin.

Paket zincirini anlamak için dotnet nuget why komutunu kullanabilirsiniz. Bu komut, belirli bir paketin neden projeye dahil edildiğini gösterir.

CI/CD İçinde Ayrı Bir Audit Pipeline Tasarımı

Güvenlik denetimini CI/CD sürecine entegre etmek için, sadece audit odaklı ayrı bir pipeline oluşturmak akıllıca bir yaklaşımdır. Örneğin, tüm NuGet audit uyarılarını bu pipeline'da hataya çevirip, diğer pipeline'larda uyarı olarak bırakabilirsiniz:

<PropertyGroup>
  <NuGetAuditCodes>NU1900;NU1901;NU1902;NU1903;NU1904;NU1905</NuGetAuditCodes>

  <!-- Audit pipeline aktifken tüm audit uyarılarını hataya çevir -->
  <WarningsAsErrors Condition=" '$(AuditPipeline)' == 'true' ">
    $(WarningsAsErrors);$(NuGetAuditCodes)
  </WarningsAsErrors>

  <!-- Diğer durumlarda uyarı olarak bırak -->
  <WarningsNotAsErrors Condition=" '$(AuditPipeline)' != 'true' ">
    $(WarningsNotAsErrors);$(NuGetAuditCodes)
  </WarningsNotAsErrors>
</PropertyGroup>

CI tarafında ise örneğin GitHub Actions için:

- name: Restore with NuGet Auditing
  run: dotnet restore -p:AuditPipeline=true

Böylece, geliştirme ortamında geliştiriciler uyarıları görür ama bloklanmaz; audit pipeline ise güvenlik ihlallerini kırmızıya çevirir.

npm ile Paket Güvenlik Denetimi – JavaScript/Node.js Ekosistemi

npm audit ile Otomatik Güvenlik Taraması

npm ekosisteminde güvenlik denetimi için npm audit komutu kullanılır. Bu komut:

• package.json ve package-lock.json dosyalarınızı inceler,
• Bağımlılık ağacınızı (dependency tree) npm registry'ye özet olarak gönderir,
• Bilinen güvenlik açıkları için detaylı bir rapor döner.

Komutun temel kullanımı:

cd path/to/your-project
npm audit

npm, npm install sırasında da otomatik olarak audit çalıştırabilir. Bu sayede yeni paket eklerken anında geri bildirim alırsınız.

EAUDITNOPJSON ve EAUDITNOLOCK Hatalarını Çözmek

npm audit çalıştırırken şu hatalarla karşılaşabilirsiniz:

• EAUDITNOPJSON: Projede package.json yok.
• EAUDITNOLOCK: Projede package-lock.json yok.

Çözüm adımları:

• EAUDITNOPJSON için: npm init ile bir package.json oluşturun.
• EAUDITNOLOCK için: npm i --package-lock-only komutu ile sadece lock dosyasını üretin.

npm audit fix ile Otomatik Düzeltme

Audit raporu, zafiyetler için önerilen güncellemeleri de içerir. Eğer uyumlu (semver uyumlu) güncellemeler mevcutsa, aşağıdaki komutla otomatik düzeltme yapabilirsiniz:

npm audit fix

Bu komut, mevcut sürüm aralığınız içinde kalan güvenli sürümlere güncelleme yapar. Eğer önerilen güncelleme major bir sürüm değişikliği gerektiriyorsa, raporda SEMVER WARNING ile belirtilir. Bu durumda API değişiklikleri nedeniyle kodunuzda da düzenleme yapmanız gerekebilir.

Manuel İnceleme Gerektiren Zafiyetler

Bazı durumlarda, zafiyet için henüz bir yama (patch) veya güvenli sürüm yayınlanmamış olabilir. Bu durumda npm audit raporu; zafiyetin açıklamasını, etkilenen paket yolunu ve "More info" alanında detaylı bir güvenlik danışma (advisory) bağlantısını içerir.

Bu senaryoda izlenebilecek yollar:

• Azaltıcı faktörleri kontrol edin – Zafiyet sadece belirli işletim sistemlerinde veya belirli fonksiyonlar çağrıldığında aktif olabilir.
• Bağımlı paketleri güncelleyin – Zafiyetli pakete bağlı olan üst paketin yeni bir sürümü varsa ona geçin.
• Doğrudan zafiyeti düzeltin – Açık kaynak projelerde pull/merge request ile düzeltme önerebilirsiniz.
• Issue açın – Paketin issue tracker'ında zafiyetle ilgili detaylı bir kayıt oluşturun.

CI/CD'de npm audit Entegrasyonu

npm projelerinde de audit'i CI sürecine entegre etmek önemlidir. Örneğin bir CI job'ında:

npm ci
npm audit --audit-level=high

--audit-level parametresi ile en az hangi seviye zafiyette job'ın başarısız olacağını belirleyebilirsiniz (low, moderate, high, critical). Böylece, örneğin sadece high ve critical zafiyetlerde pipeline'ı kırabilirsiniz.

Teknik Olmayan Karar Vericiler İçin Özet: Neye Dikkat Etmelisiniz?

Teknik detaylara girmeden, yönetici veya ürün sahibi perspektifinden bakıldığında şu noktalar kritik:

• Süreklilik: Güvenlik denetimi bir kerelik değil, sürekli bir süreç olmalı. CI/CD'ye entegre edilmeli.
• Risk seviyeleri: Tüm zafiyetler eşit önemde değildir. Yüksek ve kritik seviyeler için otomatik bloklama stratejisi belirlenmeli.
• Görünürlük: Audit sonuçları dashboard'larda, raporlarda görünür olmalı; teknik ekipler kadar yönetim de erişebilmelidir.
• Politikalar: Hangi seviyedeki zafiyetin ne kadar sürede kapatılması gerektiği (SLA) yazılı hale getirilmelidir.

Kompanse Yazılım gibi ekipler, bu prensipleri kurumsal güvenlik politikalarıyla uyumlu olacak şekilde süreçlere gömerek, teknik risklerin iş riskine dönüşmesini en aza indirir.

Sonuç: Güvenlik Denetimini Geliştirme Kültürünüzün Parçası Yapın

Paket yöneticileri sayesinde hızla geliştirme yapabiliyoruz; ancak bu hızın bedeli, üçüncü parti kodlara duyulan yüksek bağımlılık. NuGet ve npm'in sunduğu security audit mekanizmaları, bu bağımlılığın getirdiği riskleri yönetmek için güçlü araçlar sunuyor.

Özetle:

• .NET projelerinde NuGet Audit ve dotnet restore çıktılarınızı düzenli kontrol edin, uyarıları CI'da hataya çevirin.
• JavaScript/Node.js projelerinde npm audit ve npm audit fix komutlarını hem lokal hem CI ortamında çalıştırın.
• Audit kaynaklarınızı (auditSources, registry vb.) doğru yapılandırın ve güncel tutun.
• Transitif bağımlılık zincirlerini anlamak için dotnet nuget why gibi araçlardan yararlanın.
• Zafiyetleri, seviyelerine göre önceliklendiren net bir iç süreç tanımlayın.

Böylece, paket ekosistemlerinin hız avantajından faydalanırken, güvenlikten ödün vermeden sürdürülebilir ve güvenli bir yazılım geliştirme kültürü oluşturabilirsiniz.