NuGet Audit: прекратите выпускать уязвимые пакеты .NET

Приглашенный эксперт: Михаил Пожиган,

бэкенд-разработчик ASP.NET Core в Coherent Solutions

NuGet Audit в .NET 9+ — это удивительно мощный сканер безопасности, который уже работает в ваших сборках. Вот как им пользоваться.

Резюме: NuGet Audit встроен в .NET 8+ и не требует никакой настройки для начала сканирования ваших зависимостей. .NET 9 добавляет проверку транзитивных зависимостей, а .NET 10 — автоматическое исправление прямых уязвимостей. С помощью двух небольших изменений в конфигурации вы можете сделать так, чтобы критические уязвимости автоматически прерывали сборку.

Каждая зависимость, добавляемая в приложение, представляет собой потенциальную поверхность атаки. Тем не менее, большинство команд .NET полагаются на сторонние SaaS-сканеры безопасности или вообще ничего не делают. Есть решение лучше: надежный сканер безопасности NuGet Audit уже встроен в .NET SDK начиная с версии 8, и все, что вам нужно сделать, — это правильно его настроить.

Что NuGet предлагает из коробки

NuGet Audit запускается автоматически при каждом восстановлении и сборке. Он проверяет ваши зависимости по базе данных GitHub Advisory Database (тому же источнику, который используется для оповещений безопасности GitHub) и выдает предупреждения о любых обнаруженных известных уязвимостях. Вы также можете запустить его явно из CLI в любое время с помощью следующей команды:

dotnet list package --vulnerable --include-transitive

Возможности NuGet Audit, к которым вы получаете доступ, зависят от версии вашего SDK:

.NET 10 добавляет автоматическое исправление с помощью команды dotnet package update --vulnerable. При обнаружении уязвимых прямых зависимостей NuGet может автоматически обновить их до безопасной версии. Однако транзитивные зависимости не обновляются, поэтому некоторые проблемы все равно могут потребовать ручного вмешательства.

Командам следует помнить, что в .NET 9 сканирование транзитивных зависимостей является необязательной функцией, которую необходимо включить. Без нее NuGet Audit проверяет только те пакеты, на которые вы ссылаетесь напрямую, и может пропустить уязвимости, скрытые глубже в дереве зависимостей. Есть два способа включить сканирование транзитивных зависимостей:

• Добавьте --include-transitive в ваши команды CLI.

Добавьте --include-transitive в ваши команды CLI.

• Установите это глобально в Directory.Build.props, чтобы сканирование запускалось автоматически для всех участников команды. Вот как это сделать:

Установите это глобально в Directory.Build.props, чтобы сканирование запускалось автоматически для всех участников команды. Вот как это сделать:

<Project> <PropertyGroup> <!-- Возможные значения: 'direct' (по умолчанию в .NET 9) или 'all' (по умолчанию в .NET 10+) --> <NuGetAuditMode>all</NuGetAuditMode> </PropertyGroup> </Project>

Три важных изменения в конфигурации NuGet

NuGet Audit работает из коробки, но конфигурация по умолчанию намеренно консервативна. Чтобы извлечь из него максимум пользы, стоит внести три изменения: стандартизировать настройки аудита для всей команды, сделать так, чтобы серьезные уязвимости прерывали сборку, и запускать аудит в CI для обнаружения недавно раскрытых CVE.

1. Добавьте общий nuget.config в систему контроля версий

Microsoft рекомендует фиксировать nuget.config в корне вашего репозитория. Это гарантирует, что каждый разработчик и сервер CI используют абсолютно одинаковые источники пакетов, предотвращая случайный откат к локально неверно настроенному каналу. Однако если вы используете частный канал NuGet, есть нюанс: данные об уязвимостях из этого канала будут недоступны. Чтобы обеспечить доступность, вы можете использовать следующие секции конфигурации, чтобы добавить nuget.org в качестве явного источника аудита, отдельно от ваших обычных источников пакетов:

<packageSources> <clear/> <add key="my-private-feed" value="https://my-private-feed/index.json" /> </packageSources>

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

2. Сделайте так, чтобы критические уязвимости прерывали сборку

По умолчанию NuGet Audit генерирует только предупреждения. Предупреждения легко игнорировать, особенно когда в проекте их много. Решение состоит в том, чтобы повысить уровень предупреждений высокой и критической степени до ошибок. Для этого добавьте команду в файл Directory.Build.props, чтобы она применялась к каждому проекту в решении:

<PropertyGroup> <WarningsAsErrors>NU1900;NU1903;NU1904</WarningsAsErrors> <!-- NU1900 = аудит NuGet недоступен, прервать сборку NU1901 = низкая степень тяжести, NU1902 = средняя степень тяжести, NU1903 = высокая степень тяжести, прервать сборку NU1904 = критическая степень тяжести, прервать сборку--> </PropertyGroup>

Совет: Включение NU1900 сработает, если сам аудит не сможет запуститься (из-за сетевых проблем, неправильных настроек и т. д.). Скрытый сбой аудита равен отсутствию аудита вообще, поэтому вы будете вовремя уведомлены.

3. Используйте его в CI

Ваша локальная сборка будет применять указанные выше правила, но вам также необходим запланированный конвейер (pipeline), который будет обнаруживать уязвимости в уже развернутых решениях, даже если код не менялся. В конце концов, новая CVE может появиться сегодня и затронуть код, который вы выпустили шесть месяцев назад.

Решение — добавить минимальный шаг в Bitbucket Pipelines (то же самое будет работать в GitHub Actions или Azure Pipelines):

pipelines: default: - step: name: Restore and Audit NuGet Packages script: # Restore содержит аудит NuGet # Отмечать уязвимости NuGet высокого (NU1903) и критического (NU1904) уровней как ошибки # Отмечать недоступный аудит (NU1900) как ошибку - dotnet restore /p:WarningsAsErrors=NU1900%3BNU1903%3BNU1904

Достаточно ли безопасности NuGet Audit?

Возможно, вы задаетесь вопросом, достаточно ли NuGet Audit для защиты вашей сборки. Хотя у него есть ограничения, это минимально необходимая мера безопасности, которую должны внедрять команды. Сканер охватывает все дерево зависимостей NuGet, использует хорошо поддерживаемую базу данных рекомендаций и не требует ничего, кроме уже имеющегося у вас SDK. Вот несколько ограничений NuGet Audit, о которых вам следует знать:

• Единственный источник для проверки уязвимостей (GitHub Advisory Database).

Единственный источник для проверки уязвимостей (GitHub Advisory Database).

• Сканирование безопасности только для пакетов NuGet — не распространяется на контейнеры, npm или IaC.

Сканирование безопасности только для пакетов NuGet — не распространяется на контейнеры, npm или IaC.

• Отсутствие автоматического создания PR для исходований.

Отсутствие автоматического создания PR для исходований.

Если вашей команде требуется любая из этих функций, вам следует рассмотреть возможность использования другого инструмента, такого как Dependabot, Renovate или Snyk, в дополнение к NuGet Audit.

Напоминания по конфигурации NuGet

• Включите сканирование транзитивных зависимостей, добавив --include-transitive или установив его глобально в Directory.Build.props.

Включите сканирование транзитивных зависимостей, добавив --include-transitive или установив его глобально в Directory.Build.props.

• Добавьте общий файл nuget.config с явной командой <auditSources>, если вы используете частный канал.

Добавьте общий файл nuget.config с явной командой <auditSources>, если вы используете частный канал.

• Повысьте уровень NU1900, NU1903 и NU1904 до ошибок, чтобы уязвимости высокой и критической степени прерывали сборку.

Повысьте уровень NU1900, NU1903 и NU1904 до ошибок, чтобы уязвимости высокой и критической степени прерывали сборку.

• Настройте запланированный конвейер CI для обнаружения новых CVE в уже развернутом коде.

Безопасность за пределами NuGet

После того как вы внесли предложенные изменения в конфигурацию, рассмотрите возможность использования дополнительных инструментов, если у вас более высокие требования к безопасности или если вы хотите получить преимущество в виде автоматического создания PR.

• Включение Dependabot на GitHub требует всего одного флажка и позволяет автоматически создавать PR для обновления пакетов.

Включение Dependabot на GitHub требует всего одного флажка и создает автоматические PR для обновления пакетов.

• Такие инструменты, как Renovate или Snyk, могут помочь автоматизировать PR для зависимостей в Azure DevOps или Bitbucket.

Такие инструменты, как Renovate или Snyk, могут помочь автоматизировать PR для зависимостей в Azure DevOps или Bitbucket.

Хотя NuGet Audit не заменит полноценный инструмент аудита безопасности, это простой первый шаг, который вы можете предпринять прямо сейчас, чтобы прекратить выпуск решений с уязвимыми пакетами .NET. Это часто упускаемый из виду инструмент, который требует лишь нескольких простых настроек для повышения его эффективности и создания базового уровня безопасности.