Güvenlik açıkları için paket bağımlılıklarını denetleme

Güvenlik denetimleri hakkında

NuGet gibi paket yöneticileri için güvenlik denetimi, bir yazılım projesine dahil edilen paketlerin güvenliğini analiz etmeyi içeren bir işlemdir. Bu, güvenlik açıklarını tanımlamayı, riskleri değerlendirmeyi ve güvenliği geliştirmeye yönelik önerilerde bulunmayı içerir. Denetim, paketlerin gözden geçirilmesinin yanı sıra bağımlılıkları ve bunların ilişkili risklerini içerebilir. Denetimin amacı, kod ekleme veya siteler arası betik saldırıları gibi saldırganlar tarafından kötüye kullanılabilecek güvenlik açıklarını belirlemek ve azaltmaktır.

Özellik kullanılabilirliği

NuGet .NET SDK Visual Studio Özellik
5.9 .NET 5 SDK (5.0.200) Yok dotnet list package --vulnerable
6.8 .NET 8 SDK (8.0.100) Visual Studio 2022 17.8 PackageReference için NuGetAudit
6.10 Yok Visual Studio 2022 17.10 packages.config için NuGetAudit
6.11 .NET 8 SDK (8.0.400) Visual Studio 2022 17.11 PackageReference için NuGetAuditSuppress
6.12 .NET 9 SDK (9.0.100) Visual Studio 2022 17.12 Denetim kaynakları. packages.config için NuGetAuditSuppress .
7.0 .NET 10 SDK (10.0.100) Visual Studio 2026 .NET 10 için NuGetAuditMode varsayılan değişiklikleri. dotnet package update --vulnerable

Güvenlik denetimini restore ile çalıştırma

Projeyi restore ilk kez yükleme, yeni paket ekleme, paket sürümünü güncelleştirme veya sık kullandığınız IDE'de projenizden paket kaldırma gibi ortak bir paket işlemi yaptığınızda komut otomatik olarak çalıştırılır. Bağımlılıklarınız, denetim kaynaklarınız tarafından sağlanan bilinen güvenlik açıkları listesine göre denetleniyor.

  1. Komut satırında projenize veya çözüm dizininize gidin.
  2. Tercih ettiğiniz araçları (dotnet, MSBuild, NuGet.exe, VisualStudio vb.) kullanarak çalıştırın restore .
  3. Uyarıları gözden geçirin ve bilinen güvenlik açıklarını giderin.

NuGet Denetimini Yapılandırma

Denetim, projenizin bir parçası olarak değerlendirilen bir .csproj veya MSBuild dosyasındaki MSBuild özellikleri aracılığıyla yapılandırılabilir. Denetimin depo düzeyinde yapılandırılması önerilir.

MSBuild Özelliği Varsayılan Olası değerler Notlar
NuGetAuditMode Aşağıdaki 1'e bakın direct ve all Yalnızca üst düzey bağımlılıkları denetlemek istiyorsanız, değerini olarak directayarlayabilirsiniz. NuGetAuditMode packages.config projeleri için geçerli değildir.
NuGetAuditLevel Düşük low, moderate, high ve critical Rapor edilecek minimum ciddiyet seviyesi. Eğer moderate, high ve critical uyarılarını görmek istiyorsanız (ancak low hariç), değeri moderate olarak ayarlayın.
NuGetAudit doğru true ve false Güvenlik denetimi raporlarını almak istemiyorsanız, değerini olarak ayarlayarak deneyimi tamamen geri çevirebilirsiniz false
  1. NuGetAuditMode, bir proje all veya daha yüksek bir hedef belirlediğinde varsayılan olarak net10.0 olur. Aksi takdirde NuGetAuditMode varsayılan olarak olarak gösterilir direct. Bir proje birden çok hedefli olduğunda, herhangi bir hedef çerçeve seçerse all, denetim tüm hedef çerçeveler için bu değeri kullanır.

Denetim Kaynakları

Geri yükleme, her projenin kullandığı paket listesini denetlemek için bir sunucunun VulnerabilityInfo kaynağını indirir. Kaynak listesi NuGet.ConfigauditSources tanımlanır ve denetim kaynaklarından herhangi biri güvenlik açığı bilgisi sağlamazsa NU1905 uyarısı oluşturulur. Tanımlanmamışsa veya herhangi bir kaynak eklemeden temizlenmişse auditSources kullanılır packageSources ve NU1905 uyarısı gösterilmez.

Paket değiştirme saldırılarına karşı yaygın bir önlem, nuget.org'dan yukarıya akış yapan tek bir paket kaynağı kullanmak olduğundan, NuGet'in nuget.org'u paket kaynağı olarak kullanacak şekilde yapılandırılmadığı durumlarda, denetim kaynakları, nuget.org'u (veya güvenlik açığı bilgilerini sağlayan başka bir kaynağı) paket kaynağı olarak kullanmadan kullanmanıza olanak tanır.

nuget.org'un güvenlik açığı veritabanı için veri kaynağı GitHub Danışmanlık Veritabanı'dır. V2 protokolünüzün kullanım dışı bırakıldığını unutmayın; dolayısıyla nuget.config'iniz hala V2 uç noktasını kullanıyorsa V3 uç noktasına geçmeniz gerekir.

nuget.org, denetim kaynağı olarak kullanılabilecek iki hizmet dizini uç noktası sağlar:

  • https://api.nuget.org/v3/index.json — Tüm NuGet kaynaklarını (paket indirme, arama, güvenlik açığı verileri ve daha fazlası) içeren tam nuget.org hizmet dizini.
  • https://data.nuget.org/v3/index.json — Paket içeriğini veya diğer kaynakları içermeyen yalnızca güvenlik açığı verisi hizmet dizini.

Ağ düzeyinde data.nuget.org erişimini engelleyen kuruluşlar için api.nuget.org endpoint kullanışlıdır. Bu uç nokta, yalnızca güvenlik açığı verilerine hizmet ettiğinden ve paketlere hizmet etmediğinden, paket indirmelerini engellemek için api.nuget.org'yi engelleyen ağ yöneticileri istenirse data.nuget.org'e izin vermeyi düşünebilirler.

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

Not: Aşağıdaki tabloda Denetim Kaynaklarını destekleyen özellikler listelenmiştir.

Tanıtılmış Denetim Kaynaklarını Destekleyen Özellik
NuGet 6.12, .NET 9.0.100 SDK ve Visual Studio 2022 17.12 Restore
NuGet 6.14, .NET 9.0.300 SDK dotnet package list --vulnerable
NuGet 7.0 ve Visual Studio 2026 Visual Studio Paket Yöneticisi kullanıcı arabiriminde NuGet AuditSources desteği

Uyarı kodları

Uyarı Kodu Nedeni
NU1900 Hata, güvenlik açığı bilgisi alınırken paket kaynağıyla iletişim kurarken oluştu.
NU1901 Düşük önem derecesi algılanan paket
NU1902 Orta şiddette bir paket tespit edildi
NU1903 Yüksek önem derecesi tespit edilen paket
NU1904 Kritik önem derecesi algılanan paket
NU1905 Denetim kaynağı güvenlik açığı veritabanı sağlamaz

Derlemenizi özelleştirerek bu uyarıları hata olarak değerlendirerek uyarıları hata olarak değerlendirebilir veya uyarıları hata olarak değil olarak değerlendirebilirsiniz. Örneğin, zaten tüm (C#, NuGet, MSBuild, vb.) uyarıları hata olarak işlemek için kullanıyorsanız <TreatWarningsAsErrors> , gelecekte keşfedilen güvenlik açıklarının derlemenizi bozmasını önlemek için kullanabilirsiniz <WarningsNotAsErrors>$(WarningsNotAsErrors);NU1901;NU1902;NU1903;NU1904</WarningsNotAsErrors> . Alternatif olarak, düşük ve orta düzeydeki güvenlik açıklarını uyarı olarak tutmak ve yüksek ve kritik güvenlik açıklarını hata olarak ele almak istiyorsanız, TreatWarningsAsErrors kullanmıyorsanız <WarningsAsErrors>$(WarningsAsErrors);NU1903;NU1904</WarningsAsErrors> kullanabilirsiniz.

Not

gibi NoWarnTreatWarningsAsErrors ileti önem derecelerine yönelik MSBuild özellikleri packages.config projeleri için desteklenmez.

Danışmanları dışlama

Her öneri için yeni NuGetAuditSuppress bir MSBuild öğesi ekleyerek önerileri dışlayabilirsiniz. Danışma URL'sini bastırmak istediğiniz yere ayarlanmış meta verileri olan bir NuGetAuditSuppress öğesi tanımlayın.

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

Diğer NuGet denetim yapılandırma özelliklerine benzer şekilde, NuGetAuditSuppress öğeler proje veya depo düzeyinde tanımlanabilir.

NuGetAuditSuppress, NuGet 6.11, Visual Studio 17.11 ve .NET 8.0.400 SDK'sından başlayarak PackageReference projeleri için kullanılabilir. Visual Studio 17.12 ve NuGet 6.12'den packages.config için kullanılabilir.

Danışmanlar ne zaman hariç tutulacak?

Belirli bir öneriyi analiz ettiğiniz ve bunun senaryonuz için geçerli olmadığını veya bu önerinin getirdiği risklerden memnun kaldığınızı saptadığınız senaryolarda, belirli önerileri denetim raporundan hariç tutmayı seçebilirsiniz. Bunun, projenizin parçası olmayabilecek önerileri paylaşan paketler için bile önerileri tamamen bastıracağını unutmayın. NuGetAuditSuppress danışmanları yönetmek için son çare olarak kabul edilmelidir.

Bilinen güvenlik açıklarına sahip paketler bildirildiğinde eylemler

Bilinen güvenlik açıklarına sahip paketler hakkında uyarı almak sürecin yalnızca bir parçasıdır. Keşfedildikten sonra, olası güvenlik açığını çözümünüzden kaldırmak için eylem gerçekleştirmeniz gerekir.

En kolay durum, doğrudan başvurabileceğiniz bir paketin bilinen güvenlik açığına sahip olmasıdır. Bu durumda, paket sürümünü güvenlik açığını gideren bir sürüme güncelleştirin.

Paket güvenlik açıkları hem doğrudan hem de geçişli paket başvurularında bildirilebilir. Bu yüzden çözümlemek için gerçekleştirdiğiniz eylem farklı olabilir.

Güncelleştirmelerle birlikte bulunan güvenlik açıkları

Güvenlik açıkları bulunursa ve paket için güncelleştirmeler varsa, aşağıdakilerden birini yapabilirsiniz:

  • .csproj veya diğer paket sürümü konumunu (Directory.Packages.props) güvenlik düzeltmesi içeren daha yeni bir sürümle düzenleyin.
  • Tek tek paketi güncelleştirmek için Visual Studio'daki NuGet paket yöneticisi kullanıcı arabirimini kullanın.
  • dotnet package update --vulnerable Bir projedeki veya çözümdeki tüm güvenlik açığı olan paketleri bilinen güvenlik açıkları olmadan ilk sürüme güncelleştirmek için komutunu çalıştırın.
  • En son sürüme güncelleştirmek için dotnet package update veya dotnet package add komutlarını ilgili paket kimliğiyle çalıştırın. .NET 9 veya önceki sürümleri kullanırken kullanındotnet add package.
  • Projenizdeki paketleri bilinen güvenlik açıklarını gideren sürümlerle güncelleştirme özelliğine sahip NuGet Model Bağlam Protokolü (MCP) sunucusunu kullanın. Daha fazla bilgi için bkz . Paket güvenlik açıklarını düzeltme .

Geçişli Paketler

Genellikle bir güvenlik açığı geçişli bağımlılıkta olur. Önerimiz, doğrudan referanslarınıza "en yakın" olan paketlerin güncellemelerini tercih etmenizdir. Ancak paketi bilinen güvenlik açığıyla yükseltmenin de bir yanlışlığı yoktur.

Örneğin, projenizin A paketine başvurdığını varsayalım. A Paketi'nin B paketine bağımlılığı vardır ve bu da C paketine bağımlıdır. Bu örnekte C sürüm 1.0.0 paketinin bilinen bir güvenlik açığı olduğunu ve 2.0.0 sürümünde düzeltildiğini düşüneceğiz. Önerimiz, önce A paketini yükseltmeyi denemektir. Bu, denetim uyarısını çözmezse B paketini yükseltmeyi deneyin. Bu, denetim uyarısını çözmezse C'yi doğrudan yükseltin. Bu konuda yardımcı olmak için geçişli paket yolunu bulmanız gerekir.

Özetle, bir üst düzey paketin geçişli bağımlılıklarında bilinen bir güvenlik açığı varsa şu seçeneklere sahip olursunuz:

  • Üst düzey paketin geçişli bir güvenlik açığı olmayan bir güncelleştirme içerip içermediğini denetleyin ve bunun yerine bu güncelleştirmeyi güncelleştirin.
  • Güvenlik açığı içermeyen, doğrudan referanslarınıza en yakın paketi güncelleyin.
  • Sabit paket sürümünü doğrudan paket başvurusu olarak ekleyin. Not: Yeni bir paket sürümü güncelleştirmesi kullanılabilir olduğunda bu başvuruyu kaldırdığınızdan ve beklenen davranış için tanımlı öznitelikleri koruduğunuzdan emin olun.
  • Geçişli sabitleme işleviyle Merkezi Paket Yönetimi'ni kullanın. Projenizi başkalarıyla paylaşmak üzere kendi paketinize paketlerseniz geçişli sabitlemeye sahip CPM, projeniz doğrudan bu pakette API'leri çağırmasa bile paketlerin bağımlılık haline gelmesine neden olur.
  • Çözümlenebilene kadar öneriyi gizleme.
  • Güncelleştirme istemek için üst düzey paketin izleyicisinde bir sorun oluşturun.
Geçişli paket yolunu bulma

Paket yolunu bulmanın birkaç yolu vardır. Tercih ettiğiniz yöntem, geliştirme sırasında normalde hangi araçları kullandığınıza bağlıdır.

dotnet nuget neden

Komut satırında, geçişli paketlerin dotnet nuget why projenizin paket grafiğine neden dahil edildiğini anlamak için komutunu kullanabilirsiniz.

dotnet nuget neden örnek

Visual Studio Çözüm Gezgini

SDK stilindeki projeler, projenin Bağımlılık düğümü altında tam paket grafiği de sağlar. Ayrıca aranabilir! Arama seçeneklerini genişletin ve "dış dosyaları ara" seçeneğini etkinleştirin.

Visual Studio Çözüm Gezgini Arama Seçenekleri

Paket adını aradığınızda, her projenin Bağımlılıklar düğümü altındaki tüm örnekler gösterilir.

Visual Studio Çözüm Gezgini Arama Sonuçları

Visual Studio NuGet Paket Yöneticisi Kullanıcı Arabirimi

Visual Studio'nun paket yöneticisi kullanıcı arabirimindeki Yüklü sekmesine baktığınızda, proje paket yönetimi için PackageReference kullandığında hem doğrudan hem de geçişli paketler gösterilir. Şu anda, bu yalnızca çözüm için değil, bir proje için paketleri yönettiğiniz zaman gerçekleşir.

Fareyle paket listesindeki bir paketin üzerine gelirseniz araç ipucu, geçişli paketin projeye dahil edilmesine neden olan bir doğrudan paketin adını içerir.

Visual Studio Paket Yöneticisi kullanıcı arabirimi araç ipucu

Güncelleştirme olmadan bulunan güvenlik açıkları

Güvenlik düzeltmesi olmayan bir pakette bilinen bir güvenlik açığının mevcut olması durumunda aşağıdakileri yapabilirsiniz.

  • Danışmanlık raporunda özetlenen risk azaltma faktörlerini denetleyin.
  • Paket kullanım dışı olarak işaretlendiyse veya bırakıldıysa önerilen bir paket kullanın.
  • Paket açık kaynaklıysa, bir düzeltme katkısında bulunmayı göz önünde bulundurun.
  • Paketin sorun izleyicisinde bir sorun açın.

Azaltıcı faktörleri denetleme

Güvenlik açığıyla birlikte paketi kullanmaya devam etmenizi sağlayacak tüm azaltıcı faktörler için güvenlik danışmanını gözden geçirin. Güvenlik açığı yalnızca kod belirli bir çerçevede, işletim sisteminde veya özel bir işlev çağrıldığında mevcut olabilir.

Önerilen paketi kullanma

Kullandığınız paket için bir güvenlik önerisi bildirilirse ve paket kullanım dışı olarak işaretlenirse veya kullanımdan kaldırılmış gibi görünürse, paket yazarının bildirdiği önerilen alternatif paketi veya korunan benzer işlevlerden oluşan bir paketi kullanmayı göz önünde bulundurun.

Düzeltmeye katkıda bulunma

Güvenlik önerisi için bir düzeltme yoksa, güvenlik açığını gideren değişiklikleri içeren bir çekme isteği açmayı veya NuGet.org paketinin ayrıntı sayfasındaki Contact owners bölümü aracılığıyla yazara başvurmayı düşünebilirsiniz.

Sorun açma

Güvenlik açığını düzeltmek istemiyorsanız veya paketi güncelleştiremiyor veya değiştiremiyorsanız, paketin sorun izleyicisinde veya tercih edilen iletişim yönteminde bir sorun açın. NuGet.org, paket ayrıntıları sayfasına gidebilir ve yazarla iletişim kurmanız için size yol gösterecek olan seçeneği tıklatabilirsiniz Report package .

Güvenlik açığı bulunamadı

Herhangi bir güvenlik açığı bulunmazsa, bu, denetlediğiniz şu anda paket grafiğinizde bilinen güvenlik açıklarına sahip paketlerin bulunamadığını gösterir. Danışma veritabanı herhangi bir zamanda güncellenebileceği için, sürekli tümleştirme sürecinizde dotnet restore çıktınızı düzenli olarak kontrol etmenizi öneririz.

CI'de NuGet Denetimini Çalıştırma

Ayrılmış Denetim İşlem Hattı ile Hataları Uyarılardan Ayırma

Diğer işlem hatlarında veya yerel derlemelerde denetim uyarıları hata olarak değerlendirilmeden, denetimleri çalıştırmak üzere ayrılmış bir CI işlem hattı yapılandırmak için MSBuild'in koşullu deyimlerini kullanabilirsiniz. CI sisteminize ve ekip süreçlerinize bağlı olarak, denetim işlem hattının başarısız çalıştırmaları ekibe e-posta ile bildirilebilir veya işlem hattının en son çalıştırmasının rozetini gösterebileceğiniz bir panoya sahip olabilirsiniz.

Programlamadaki birçok şey gibi, sonucu elde etmenin birden çok yolu vardır. Bir seçenek, NuGet Denetim uyarılarını yalnızca bir denetim işlem hattında hata olarak ele almaktır.

<PropertyGroup>
  <NuGetAuditCodes>NU1900;NU1901;NU1902;NU1903;NU1904;NU1905</NuGetAuditCodes>
  <WarningsAsErrors Condition=" '$(AuditPipeline)' == 'true' ">$(WarningsAsErrors);$(NuGetAuditCodes)</WarningsAsErrors>
  <WarningsNotAsErrors Condition=" '$(AuditPipeline)' != 'true' ">$(WarningsNotAsErrors);$(NuGetAuditCodes)</WarningsNotAsErrors>
</PropertyGroup>

Ardından işlem hattınızda, koşul tarafından kullanılan özelliği belirterek geri yükleme işlemini çalıştırırsınız. Örneğin, GitHub Actions söz dizimlerini kullanarak:

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

Özellik adı AuditPipeline yalnızca bir örnektir ve ad hem MSBuild koşulunda hem de komut satırında aynı olduğu sürece istediğiniz gibi özelleştirebilirsiniz. MSBuild, henüz tanımlanmamış bir özelliği okurken ortam değişkenlerini de kullanır, bu nedenle ortam değişkeni komut satırı parametresine alternatiftir.

NuGet Denetimi uyarılarının geri yüklemede seçmeli olarak başarısız olmasına neden olan koşulları kullanarak, paketleri bilinen güvenlik açıklarına karşı denetlemek için ayrılmış bir işlem hattına sahip olurken, yeni güvenlik önerilerinin uygun olmayan zamanlarda hata düzeltmelerinizi engellemesini engelleyebilirsiniz. Yerel derlemeler için NuGet Denetimi uyarılarının etkin tutulması, geliştiricilerin yeni güvenlik önerileri hakkında engelleyici olmayan bir bildirim almasına olanak tanır ve birinin denetim işlem hattı durumunu denetlemesini beklemekten daha hızlı bir şekilde güvenlik açıklarını düzeltmek için paket sürümlerini yükseltmeyi teşvik edebilir.

Denetlenen projelerin geri yüklendiğinden emin olun

MSBuild 17.13 ve .NET 9.0.200'deki NuGet, geri yükleme görevine RestoreProjectCount, RestoreSkippedCount ve RestoreProjectsAuditedCount çıktı özellikleri ekledi. Bu, geri yükleme sırasında denetim sürecinin çalıştırıldığını sağlamak için kullanılabilir. Bu çıkış özelliklerinin statik graf geri yükleme ile kullanılamadığını unutmayın.

MSBuild bir betik dili olduğundan, bu çeşitli yollarla elde edilebilir, ancak MSBuild ile aynı kısıtlamalara da sahiptir. Örneklerden biri, içeriği aşağıdakine benzer bir hedefe sahip olan çözüm dosyanızla aynı dizinde Directory.Solution.targets dosyası oluşturmaktır. Directory.Build.props'un yaygın olarak kullanıldığını ancak projeler tarafından içeri aktarıldığını unutmayın. Ancak, NuGet'in geri yükleme hedefi ve görevi çözüm düzeyinde çalışır, bu nedenle proje/derleme dosyası değil MSBuild'in çözüm genişletilebilirlik dosyasında olması gerekir.

<Project>
    <Target Name="AssertRestoreTaskOutputProperties"
            AfterTargets="Restore"
            Condition="'$(CI)' == 'true'">
        <Error
            Condition="'$(RestoreProjectsAuditedCount)' != '$(RestoreProjectCount)'"
            Text=""Restore did not audit every project in the solution. Expected: $(RestoreProjectCount) Found: $(RestoreProjectsAuditedCount)"" />
    </Target>
</Project>

Kullanım örneğine bağlı olarak, geri yükleme işleminin zaten güncel olduğu için atlanan projeleri hesaba eklemek için hata iletisinde koşul '$(RestoreProjectCount)' != '$([MSBuild::Add($(RestoreProjectsAuditedCount), $(RestoreSkippedCount))' kullanmak isteyebilirsiniz. Benzer şekilde, bu hatanın her yerde mi yoksa yalnızca CI işlem hatlarında mı gerçekleşmesini istediğinizi ve CI ortamınızda hangi ortam değişkenlerinin tanımlandığını düşünün ve bunu hedefin koşuluna dahil edin. MSBuild bir betik dili olduğundan, deponuzu istediğiniz gibi özelleştirmek için özelliklerinden herhangi birini kullanabilirsiniz. MSBuild'in metaproj ve binloglarını görüntülemek, çözüm düzeyi hedefleri geliştirmek ve sorunlarını gidermek için yararlıdır.

dotnet list package --vulnerable

dotnet list package , hangi paketlerin bilinen güvenlik açıklarına sahip olduğunu temel alarak paketleri filtrelemeye yönelik bir --vulnerable bağımsız değişkene sahiptir. --include-transitive Varsayılan olmadığını, bu nedenle eklenmesi gerektiğini unutmayın.

  • Last updated on