借助 NuGet Audit 让我们的应用更安全

借助 NuGet Audit 让我们的应用更安全

Intro

这次 .NET Conf China 我分享了一个关于 NuGet Audit 的一个话题 “NuGet Audit 让你的应用更安全” ，之所以分享这个话题，我们公司最近安全部门对我们的系统做安全审计以避免引入有漏洞的依赖来保证我们的系统安全性，而 NuGet Audit（审计）可以帮助我们更好地发现代码中有漏洞的依赖，所以想抛出这个话题希望也能对大家有所帮助

这次分享的内容大概分成四部分

• 什么是 NuGet Audit
• 为什么我们需要 NuGet Audit
• 如何使用配置 NuGet Audit
• NuGet Audit 后面的一些计划

What

首先我们来看一下什么是 NuGet Audit，在升级到 .NET 8/9 之后，如果你的项目有一些老的 NuGet 包没有升级可能会看到类似下面这样的警告

nuget audit warnings

这里我截了两个 VS 里的截图，中间这个是使用 dotnet-cli 还原 NuGet 包时出现的警告，这个表示引用的 NuGet 包有安全漏洞，可能要升级到新的版本解决。

从下面的两个警告信息里可以看到这里有一个 GitHub 的链接，这个链接打开之后是 GitHub 安全专家们建立的一个安全建议数据库，NuGet Audit 警告信息就是基于 GitHub 的已经经过审核之后的安全建议数据来触发警告的，使用 GitHub 比较多的朋友可能会注意到 Github 有一个 Dependabot 它也是基于这个数据库对用户开源项目提醒安全漏洞风险的。

GitHub Advisory Database

Why

那为什么我们需要这个功能呢？为什么会引入这个功能呢？用一个词来总结就是安全 Security。

在企业运营的过程中会有供应链的概念，产品从一个个零件到加工运输到最后交付到客户手上。

在软件系统中也会有一个软件供应链的概念，一个开源项目可能会被打包分发到世界各地的各个系统中，如果这个开源项目依赖有漏洞那么就会导致很多系统都有安全风险

software-supply-chain

现在有一个词比较流行，这个词就是 “左移” 是什么意思呢，就是说在软件工程和 IT 管理里，要在流程时间线的早期解决任务和问题。看这个图可以看出来源代码和依赖出于最左侧，也就意味着我们注重安全的话应该更加注意这一环节，从源头避免安全漏洞的引入。

对于安全团队来说，从新建项目开始到编写第一行代码开发测试到部署到项目上线运作每个环节都有安全风险，所以我们开发者所在的第一个环节更要注重安全的问题。

security-ops-overview

在我们的项目里相信也肯定会有一些开源项目的依赖，如何能够及时发现系统中的依赖是否有安全漏洞呢？NuGet Audit 就是帮助我们发现安全风险的，我们在还原项目依赖的时候就会可以触发 NuGet Audit 的检查

前两年有一个比较出名的漏洞问题就是 JAVA 里的 log4j 的漏洞，是一个典型的软件供应链安全的例子

因为被使用的比较广泛，之前热议全球，我们公司的安全团队之前也曾要求我们公司检查所有的 JAVA 应用是否有使用 log4j，不知道大家公司有没有 JAVA 应用，有没有受到影响，还是 dotnet 清真哈

log4j boom

How

那我们如何使用 NuGet 的审计呢？Just Upgrade，只需要升级即可

upgrade

.NET 8 引入了 NuGet 审计的支持，.NET 9 引入了更多配置的支持，之后的 .NET 10 中也还会再继续在 NuGet 的审计上投入

今天我们演示的示例是基于 .NET 9 的毕竟我们 .NET 9 已经发布了一个月了，也鼓励大家有条件的话升级到 .NET 9

升级到 .NET 8 之后的版本后，NuGet 审计默认是打开的，如果你的项目只是示例之类的项目不想打开可以通过 NuGetAudit 这个 property 来显式地禁用，这里第一个示例禁用了 NuGet Audit 所以是没有警告的

默认 NuGetAudit 只检查引用的 NuGet 包引用，对于包引用的引用不会检查，这里显式地指定 NuGetAuditMode 为 direct 为了更好的展示，而且示例项目指定了别的配置所以也需要 override 项目中的配置

第三个示例我们指定了一个 NuGetAuditLevel 为 critical 此时我们发现又没有警告了，因为前面的警告级别是 high 所以我们指定了 critical 时低于这个级别的就不会再警告了，默认是 low，所有的警告都会警告，有需要配置的话可以用这个配置来配

最后一个示例指定了 NuGetAuditMode 为 all，这里可以看到比前面多了一个警告，多了一个没有直接引用的 nuget 包的警告，因为我们显式声明了要检查所有的依赖，即使是间接引用的 NuGet 依赖也会被检查

这里需要注意一下 .NET 9 正式版的第一个 SDK 版本 9.0.100 里默认是 all 但是在上周发布的 9.0.101 版本中默认值又改回了 direct，如果需要设置为 all 需要自己显式的设置一下

NuGet 审计是在还原包时触发的也就是 dotnet restore，而 dotnet build/dotnet publish 默认会触发 dotnet restore 如图所示，不过注意的话注意到 warning 会出现两次，在 GitHub 上提了一个 issue，感兴趣的话大家可以关注一下 https://github.com/dotnet/sdk/issues/45367

dotnet build/publish

默认审计的信息是警告，我们能不能让他变成错误呢，而不是 warning 因为有些朋友不会注意警告，直接变成错误来就能引起大家的注意了，我们可以借助 MSBuild 的特性来将警告信息变成错误，这里展示了两种方式

第一种方式是设置 WarningsAsErrors 可以将需要的 ErrorCode 设置一下将警告变成错误

第二种方式是设置 TreatWarningsAsErrors=true 这种方式会将所有的警告都视为警告，对于项目有质量要求的项目推荐设置，对于某些不想 warning 的可以设置 NoWarn 来排除

warning as error

除了 dotnet restore 的时候可以看有漏洞的依赖我们也可以通过 dotnet list package 来查看，默认不会检查间接依赖，可以通过 --include-transitive 来检查

dotnet list package --vulnerable

这里我们看到我们间接依赖的 NuGet.Common 这个依赖有漏洞，那是哪一个 NuGet 包导致了这个依赖了呢？我们可以通过 .NET 9 中的 dotnet nuget why 命令来检查依赖，这里是一个使用示例，可以看到输出的结果中清晰地表明了是哪一个 package 导致了这个依赖，如果有多个层级依赖也会都列出来

dotnet-nuget-why

对于直接引用的 NuGet 包我们可以直接升级对应 package 的包，对于间接引用的包要怎么修复呢，同样地我们需要引用高版本没有漏洞的依赖，这里推荐大家使用中心化的包版本管理，解决这个问题会变得更简单，直接在 Directory.Package.props 文件中引用即可，无需在具体的项目中添加引用，后续直接依赖的版本升级了不需要这个了也可以方便地移除这个依赖项

Fix vulnerable in CPM

那如果某个版本有漏洞但是目前还没有修复版本怎么办呢？我们可以配置 NuGetAuditSuppress 临时忽略某个安全漏洞的警告

suppress and sources

如果我们自己的私有 NuGet package 源也支持 Audit，也可以配置在 nuget.config 的 Audit Source 里

最后我们来一些 NuGet Audit 接下来的一些计划和功能

NuGet Audit Next

NuGet 团队准备支持一个命令来修复项目中所有的安全漏洞，从开始 Github 漏洞的界面可以看到是有修复版本的信息的，是有可能自动升级到没有漏洞版本的，这样有多个安全风险的话我们就不用一个一个检查一个个升级了，期待！

前面我们提到了可以配置 audit source，后面也将会支持基于本地文件的 audit source，感觉主要是为了本地 folder nuget source 吧

另外在安装一个有安全漏洞的 nuget 依赖时后面也会发出警告，你正在安装一个有漏洞的包版本，避免引入不安全的依赖

最后再提一个 SBOM 的支持，SBOM 全称是 Software Bill of Materials 软件物质清单，会生成一个依赖清单，帮助安全团队更好的理解和审计依赖，在打包 nuget package 的时候可以生成一个依赖清单在 nuget package 里，目前 SDK 层面还不支持，可以单独引用 Microsoft.Sbom.Targets 可以参考：https://github.com/WeihanLi/SamplesInPractice/blob/main/NuGetSamples/NuGetSamples.csproj

More

信息安全审计（英语：Information security audit）是对组织的信息安全水平进行审计的过程，其工作主要是对系统活动纪录和相关系统文件的独立审查。信息安全审核的目的在于提高系统信息安全水平，避免存在风险的系统设计，并优化安全措施和安全流程的效率。

信息安全审计的范围十分广泛，其目的亦可根据企业在不同阶段的发展目标而存在不同的侧重点，在以下领域均可进行开展：

• 信息安全管理组织与制度；
• 访问控制管理；
• 网络安全、漏洞扫描、渗透测试、代码安全扫描、机房及设备物理安全、应用系统安全、信息系统日志管理、加密传输和加密设备管理、补丁管理、IT 项目开发管理；
• 隐私数据安全、数据库和操作系统安全、信息资产分级和管理、数据资产全生命周期管理评估、信息安全事件管理、业务连续性；
• 人力安全、IT 外包安全管理、信息安全意识教育

软件包管理器如 NuGet 的安全审计是一个涉及分析软件项目中包含的软件包安全性的过程。这包括识别漏洞、评估风险和提出改进安全性的建议。审计可以包括对软件包本身的审查，以及任何依赖及其相关风险。审计的目标是识别和减轻任何可能被攻击者利用的安全漏洞，例如代码注入或跨站脚本攻击。

第三方或开源依赖项中可能存在的漏洞可能是您无法像您编写的代码那样严格控制的依赖项，这可能会在供应链中造成潜在的安全风险。

如果这些依赖项之一存在漏洞，那么就有可能存在漏洞。这可能很可怕，因为依赖项之一可能会在我们不知情的情况下发生变化。即使现在依赖项中存在漏洞，但无法利用，将来也可以利用。

最后有一些更多 NuGet Audit 相关内容的参考链接分享给大家，希望对大家有所帮助

References

• https://learn.microsoft.com/en-us/nuget/concepts/auditing-packages
• https://learn.microsoft.com/en-us/nuget/concepts/security-best-practices
• https://devblogs.microsoft.com/nuget/announcing-nuget-6-8-maintaining-security-with-ease/
• https://devblogs.microsoft.com/nuget/nugetaudit-2-0-elevating-security-and-trust-in-package-management/
• https://learn.microsoft.com/en-us/nuget/api/vulnerability-info
• https://github.com/advisories?query=type%3Areviewed+ecosystem%3Anuget
• https://github.com/github/advisory-database
• https://www.youtube.com/watch?v=Nw9ouFSiMjk
• https://github.com/NuGet/Home/issues/12497
• https://github.com/NuGet/Home/issues?q=is%3Aopen+is%3Aissue+label%3AArea%3ANuGetAudit
• https://github.com/NuGet/Home/issues/13816
• https://github.com/NuGet/Home/issues/12497
• https://github.com/WeihanLi/SamplesInPractice/blob/main/NuGetSamples/NuGetSamples.csproj