Warn when a vulnerable or EOL SDK version is resolved

[JamieMagee]

Closes #49552

NuGet warns about vulnerable packages (NU1901-NU1904) but nothing warns about the SDK itself. This adds opt-in build warnings when the resolved SDK has known CVEs or is end of life.

Set <CheckSdkVulnerabilities>true</CheckSdkVulnerabilities> in your project or Directory.Build.props. Off by default. Two warning codes: NETSDK1237 for vulnerabilities, NETSDK1238 for EOL. Suppressible with <NoWarn> if you want one but not the other.

During restore, the CLI fetches release metadata in the background (same releases-index.json that dotnet sdk check uses) and caches it to ~/.dotnet/sdk-vulnerability-cache/. The MSBuild task reads from that cache during build. It never hits the network itself. No cache file means no warnings, so air-gapped builds work fine.

Cache refresh runs alongside the workload manifest updater in RestoringCommand, 24h sentinel. Skipped in source-build. DOTNET_SDK_VULNERABILITY_CHECK_DISABLE and DOTNET_SDK_VULNERABILITY_CHECK_INTERVAL_HOURS are there if you need them.

warning NETSDK1237: The current .NET SDK (9.0.100) has known vulnerabilities (CVE-2025-12345, CVE-2025-99999). Update to version 9.0.102: https://dotnet.microsoft.com/download

warning NETSDK1238: The current .NET SDK (7.0.410) is end of life as of 2024-05-14. It will receive no further security updates: https://dotnet.microsoft.com/download

@baronfel would appreciate your input.

[Copilot]

Pull request overview

Adds SDK vulnerability/EOL warnings to improve security visibility when a potentially vulnerable or out-of-support .NET SDK is resolved, using the same release metadata source as dotnet sdk check and a local on-disk cache to avoid introducing startup latency or network calls during MSBuild resolution.

Changes:

• Add CLI startup notifier that reads cached vulnerability/EOL info and triggers background cache refresh (opt-out + configurable refresh interval via env vars).
• Add MSBuild SDK resolver warnings sourced only from the local cache (no network calls).
• Add shared cache-reader + new unit tests and release-metadata test assets to validate the vulnerability/EOL evaluation logic.

Reviewed changes

Copilot reviewed 44 out of 44 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
test/dotnet.Tests/SdkVulnerabilityTests/GivenSdkVulnerabilityChecker.cs	Unit tests for vulnerability/EOL evaluation logic against test release metadata.
test/dotnet.Tests/SdkVulnerabilityTests/GivenSdkVulnerabilityCacheReader.cs	Unit tests for reading cached summary JSON (incl. disabled/no-cache cases).
test/dotnet.Tests/SdkVulnerabilityTests/GivenSdkReleaseMetadataCache.cs	Unit tests for cache sentinel interval behavior and cache summary reading.
test/TestAssets/TestReleases/VulnerabilityTestRelease/releases-index.json	Test releases-index metadata including an active and an EOL channel.
test/TestAssets/TestReleases/VulnerabilityTestRelease/9.0/releases.json	Test channel release metadata with CVEs used by unit tests.
test/TestAssets/TestReleases/VulnerabilityTestRelease/7.0/releases.json	Test EOL channel metadata with CVEs used by unit tests.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/xlf/Strings.zh-Hant.xlf	New localizable MSBuild resolver warning strings.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/xlf/Strings.zh-Hans.xlf	New localizable MSBuild resolver warning strings.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/xlf/Strings.tr.xlf	New localizable MSBuild resolver warning strings.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/xlf/Strings.ru.xlf	New localizable MSBuild resolver warning strings.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/xlf/Strings.pt-BR.xlf	New localizable MSBuild resolver warning strings.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/xlf/Strings.pl.xlf	New localizable MSBuild resolver warning strings.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/xlf/Strings.ko.xlf	New localizable MSBuild resolver warning strings.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/xlf/Strings.ja.xlf	New localizable MSBuild resolver warning strings.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/xlf/Strings.it.xlf	New localizable MSBuild resolver warning strings.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/xlf/Strings.fr.xlf	New localizable MSBuild resolver warning strings.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/xlf/Strings.es.xlf	New localizable MSBuild resolver warning strings.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/xlf/Strings.de.xlf	New localizable MSBuild resolver warning strings.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/xlf/Strings.cs.xlf	New localizable MSBuild resolver warning strings.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/Strings.resx	Adds MSBuild resolver warning resources for vulnerable/EOL SDKs.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/Microsoft.DotNet.MSBuildSdkResolver.csproj	Links shared cache-reader into MSBuild resolver build.
src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/MSBuildSdkResolver.cs	Emits MSBuild warnings based on cached vulnerability/EOL summary data.
src/Common/SdkVulnerabilityCacheReader.cs	Shared cache-summary reader DTO + source-gen JSON context for CLI + resolver.
src/Common/EnvironmentVariableNames.cs	Adds env vars to disable the check and configure refresh interval.
src/Cli/dotnet/xlf/CliStrings.zh-Hant.xlf	New localizable CLI warning strings for vulnerable/EOL SDKs.
src/Cli/dotnet/xlf/CliStrings.zh-Hans.xlf	New localizable CLI warning strings for vulnerable/EOL SDKs.
src/Cli/dotnet/xlf/CliStrings.tr.xlf	New localizable CLI warning strings for vulnerable/EOL SDKs.
src/Cli/dotnet/xlf/CliStrings.ru.xlf	New localizable CLI warning strings for vulnerable/EOL SDKs.
src/Cli/dotnet/xlf/CliStrings.pt-BR.xlf	New localizable CLI warning strings for vulnerable/EOL SDKs.
src/Cli/dotnet/xlf/CliStrings.pl.xlf	New localizable CLI warning strings for vulnerable/EOL SDKs.
src/Cli/dotnet/xlf/CliStrings.ko.xlf	New localizable CLI warning strings for vulnerable/EOL SDKs.
src/Cli/dotnet/xlf/CliStrings.ja.xlf	New localizable CLI warning strings for vulnerable/EOL SDKs.
src/Cli/dotnet/xlf/CliStrings.it.xlf	New localizable CLI warning strings for vulnerable/EOL SDKs.
src/Cli/dotnet/xlf/CliStrings.fr.xlf	New localizable CLI warning strings for vulnerable/EOL SDKs.
src/Cli/dotnet/xlf/CliStrings.es.xlf	New localizable CLI warning strings for vulnerable/EOL SDKs.
src/Cli/dotnet/xlf/CliStrings.de.xlf	New localizable CLI warning strings for vulnerable/EOL SDKs.
src/Cli/dotnet/xlf/CliStrings.cs.xlf	New localizable CLI warning strings for vulnerable/EOL SDKs.
src/Cli/dotnet/dotnet.csproj	Links shared cache-reader into CLI build.
src/Cli/dotnet/SdkVulnerability/SdkVulnerabilityNotifier.cs	CLI startup hook to read cache, print warnings, and refresh cache in background.
src/Cli/dotnet/SdkVulnerability/SdkVulnerabilityInfo.cs	DTOs representing SDK vulnerability/EOL status and CVE entries.
src/Cli/dotnet/SdkVulnerability/SdkVulnerabilityChecker.cs	Pure logic that computes vulnerabilities/EOL status from release metadata.
src/Cli/dotnet/SdkVulnerability/SdkReleaseMetadataCache.cs	Cache manager: refresh interval/sentinel, background metadata fetch, and summary persistence.
src/Cli/dotnet/Program.cs	Invokes the notifier during CLI startup.
src/Cli/dotnet/CliStrings.resx	Adds CLI warning resources for vulnerable/EOL SDKs (incl. no-upgrade variants).

[marcpopMSFT]

Waiting for @baronfel's comment. We were discussing adding an experience for this once we had a way to update the SDK rather than going to the download page. We were hesitant as we didn't want to have to download releases.json on every CLI action so have not fully designed this feature yet.

[marcpopMSFT]

Summarizing offline conversation:
As noted, we were thinking of heading in this direction once we had a way of helping customers update. Some key feedback on the design.

• We think it should only be during build commands, not all commands (still not 100% settled on this)
• As such, it should probably be suppressible through a build property and not just an environment variable. That way you can disable with a checked in change to the diretory.build.props rather than a build script change
• It has to be disableable or be able to override the message in source build builds as the current message doesn't apply to those installs (it doesn't apply to installs by VS or VSCode either fwiw). CC @mthalman @omajid for their feedback on how this type of message could work for source build versions.
• It might be worth exploring if we can tell how the SDK was installed so that the message is customized (or silent) in installs it doesn't make sense for.
• There is some discussion on whether we want it every time but nuget audit does so maybe leave it like that.

Overall, we like the direction of not hitting the network and using the cache instead and it makes sense to warn the user when their out of date. VS and VSCode will have more experiences like this in the future but they're going to have ways of upgrading the user for them which greatly improves the user experience.

[JamieMagee]

@marcpopMSFT Thanks for the feedback. I think the right move is to get warnings out of both the CLI startup and the SDK resolver, and put them in a .targets file instead. That one change actually addresses most of your points at once.

Right now warnings fire from Program.ProcessArgs (every command) and from the resolver (during build). If I move them into an MSBuild task with dedicated warning codes (NETSDK2001 for vulnerabilities, NETSDK2002 for EOL), they'll only show up during build, they'll only show up once, and users can suppress them with <NoWarn> or a <SuppressSdkVulnerabilityWarnings> property in Directory.Build.props. Same pattern as SuppressNETCoreSdkPreviewMessage. The resolver can't do property-based suppression because it runs before project evaluation, which is why I want to move out of it entirely.

The cache refresh moves to RestoringCommand, same place as WorkloadManifestUpdater.BackgroundUpdateAdvertisingManifestsAsync. So dotnet --help and dotnet tool list won't touch it.

For source-build, I'll gate the cache refresh with #if !DOT_NET_BUILD_FROM_SOURCE so those SDKs skip network calls. On the .targets side, I can set a _SdkIsSourceBuild property at build time (in GenerateBundledVersions.targets) and either suppress the warning or change the message to say "update via your package manager" instead of linking to dotnet.microsoft.com/download.

For detecting other install sources (VS-managed, install script, etc.), there's no runtime mechanism for that today and adding one means touching MSI, PKG, DEB, RPM, install scripts, and VS bundling. I'd rather defer that to a follow-up. The DOTNET_SDK_VULNERABILITY_CHECK_DISABLE env var stays as the escape hatch, and I'll check it in the .targets Condition too so CI and air-gapped builds can opt out.

[marcpopMSFT]

More offline conversation:
We discussed this further and are ok taking this as an MSBuild flag but opt-in. While that does limit the scope, it limits the risk as well.

Your suggestions about excluding from source build make sense though with this opt-in, becomes less critical.

Another concern we had would be release day. We don't want there to be a timing problem that ends up breaking people's CI and local builds because the releases.json has updated but their SDK hasn't updated. For example, our own repos usually do a deliberate central rollout with new SDK versions which isn't immediate so this would flag during that validation window.

I think we're still ok having it as an opt-in and we do plan on plugging dotnetup into this experience in the future.

[github-actions]

📋 SDK Diagnostic Documentation Reminder

This PR introduces 3 new SDK diagnostic codes:

• NETSDK1238
• NETSDK1239
• NETSDK1240

Action Required

Please ensure that documentation for these diagnostics is added or updated in the dotnet/docs repository at:

• Path: docs/core/tools/sdk-errors/
• Documentation: https://learn.microsoft.com/dotnet/core/tools/sdk-errors/

Each diagnostic should have:

• A clear description of the error/warning
• Possible causes
• Recommended solutions
• Code examples where applicable

Thank you for helping keep our documentation up to date! 🙏

[JamieMagee]

@marcpopMSFT Updated the PR.

It's opt-in now. <CheckSdkVulnerabilities>true</CheckSdkVulnerabilities> in a project or Directory.Build.props enables it, off by default. Warnings use NETSDK1237 (CVEs) and NETSDK1238 (EOL), so <NoWarn> works if you want to suppress one but not the other.

Warnings moved out of CLI startup and the SDK resolver entirely. They come from a .targets file that runs an MSBuild task during build. dotnet --help, dotnet tool list, etc. won't trigger anything.

Cache refresh moved to RestoringCommand, same spot as the workload manifest updater. Background, fire-and-forget, skipped in source-build.

On the release-day timing: since it's opt-in the blast radius is already small, but worth noting that CVE warnings only fire when there's a newer release with security fixes in the same channel. So the window only matters if someone opts in, their SDK version is in releases.json, and a newer patch exists they haven't rolled to yet. Repos doing a deliberate rollout could suppress the code in Directory.Build.props during that window.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 31 changed files in this pull request and generated 6 comments.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 31 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

test/dotnet.Tests/SdkVulnerabilityTests/GivenSdkReleaseMetadataCache.cs:140

• This test sets the sentinel timestamp via File.SetLastAccessTime and DateTime.Now, but the implementation checks GetLastWriteTimeUtc against DateTime.UtcNow. To make the interval logic test meaningful and non-flaky, set LastWriteTimeUtc instead (and use UtcNow) so the 24h vs 1h assertions reflect the actual behavior.

        string sentinelPath = Path.Combine(cacheDir, ".sentinel");
        File.Create(sentinelPath).Close();
        // Set sentinel to 2 hours ago
        File.SetLastAccessTime(sentinelPath, DateTime.Now.AddHours(-2));

        // With default 24h interval, should not be due
        var cache24h = new SdkReleaseMetadataCache(cacheDir, _ => null);
        cache24h.IsDueForUpdate().Should().BeFalse();

        // With 1h interval, should be due
        var cache1h = new SdkReleaseMetadataCache(
            cacheDir,
            name => name == EnvironmentVariableNames.SDK_VULNERABILITY_CHECK_INTERVAL_HOURS ? "1" : null);
        cache1h.IsDueForUpdate().Should().BeTrue();

[Copilot]

Pull request overview

Copilot reviewed 31 out of 31 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 31 changed files in this pull request and generated 2 comments.

[JamieMagee]

/azp run dotnet-sdk-public-ci

[azure-pipelines]

Commenter does not have sufficient privileges for PR 53557 in repo dotnet/sdk

[JoeRobich]

/azp run dotnet-sdk-public-ci

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[baronfel]

Marked as do-not-merge because this hasn't been reviewed by the SDK team yet.

[joeloff]

Does this check for discontinued feature band, for example, at some point we typically stop shipping 2xx or 3xx and only 1xx and 4xx would be in the latest release. So, even though the product (e.g. 8.0) is not EOL, we may have stopped producing 3xx. Essentially you'd want to check if the SDKs collection in the latest release contains the current feature band, if not, it's vulnerable, but technically only if there are at least one newer release that contains security fixes. Depends on how strict you want to be. The runtime of a newer release may contain CVEs, but those may not necessarily impact the SDK.

[JamieMagee]

Right now if someone's on a discontinued band, the checker still pulls in CVEs from newer releases (since those releases are newer than theirs) but FindLatestSdkInFeatureBand returns null because it only looks within the same band. So they get a "has known vulnerabilities, no upgrade available" warning pointing at the download page, which is misleading because there is an upgrade, they just need to switch bands.

I'll add a discontinued-band path: if there's no newer SDK in the user's band but product.LatestSdkVersion is greater than theirs, recommend that instead and use a new warning string saying the band is no longer serviced. Should just be a bool + string on SdkVulnerabilityInfo.

On runtime vs SDK CVE attribution, I looked and don't see a clean way to do it. The cves collection is per-release, not per-component, and there's no flag for runtime-only fixes. The SDK ships the runtime anyway, so a runtime CVE in your SDK's bundled runtime is genuinely a CVE in your install. I'd rather over-warn than try to parse CVE descriptions to guess scope. Let me know if you have a signal I'm missing though.

On strictness I'm leaning towards warn whenever a same-channel newer release with CVEs exists. Stricter than what you described but matches what I'd expect from a "vulnerable SDK" warning. Happy to dial it back if that's too aggressive.

[joeloff]

No, that sounds good to me. Starting off more aggressive feels like the correct approach given that we're dealing with vulnerabilities.

[joeloff]

Do the checks handle newer SDKs that are not published? There are a couple of edge cases.

1. New major release of .NET being used before the first preview is shipped - early releases usually have an alpha designation.
2. Daily build of an unreleased SDK, e.g. new feature band that's in preview.
3. Official feature band that's not part of the releases.json. We had a special case with .NET 5 and Visual Studio 16. .NET 5 was going out of support, .NET Core 3.1 was still in support. So we ended up shipping 5.0.4xx SDKs that ran on .NET 6. These only shipped with VS, and allowed users to continue targeting .NET Core 3.1 until newer versions of VS shipped .NET 6.0 SDK.

For early releases, I think it's fine to consider it in support, e.g. if the Major.Minor is newer than the latest product version, e.g. you installed .NET 12.0, but the last official product we shipped was 11.0. Same for SDKs, if the SDK version is newer than any known SDK and the product is not EOL, we should consider the SDK to be valid.

[joeloff]

• It might be worth exploring if we can tell how the SDK was installed so that the message is customized (or silent) in installs it doesn't make sense for.

It's doable, we have code that can do this on Windows, and do it extremely accurately, but it's expensive. If you want that to have value, you have to be accurate.

[JamieMagee]

Do the checks handle newer SDKs that are not published? There are a couple of edge cases.

All three are already handled. The currentReleaseIndex < 0 -> return null early exit covers 2 and 3, and case 1 falls out from the channel lookup returning null.

1. New major release of .NET being used before the first preview is shipped - early releases usually have an alpha designation.

Case 1, 12.0 alpha when latest released is 11.0: channel "12.0" isn't in releases-index.json, checker returns null. Covered by UnknownSdkVersionReturnsNull.

2. Daily build of an unreleased SDK, e.g. new feature band that's in preview.

Case 2, daily build or new in-preview band on a known channel: channel found, SDK not in any release on it, currentReleaseIndex < 0, returns null. Covered by KnownChannelButUnknownSdkVersionReturnsNull.

3. Official feature band that's not part of the releases.json. We had a special case with .NET 5 and Visual Studio 16. .NET 5 was going out of support, .NET Core 3.1 was still in support. So we ended up shipping 5.0.4xx SDKs that ran on .NET 6. These only shipped with VS, and allowed users to continue targeting .NET Core 3.1 until newer versions of VS shipped .NET 6.0 SDK.

Case 3 is the same path as case 2. Channel can be EOL, but if the SDK isn't in releases.json we return null and emit nothing. For the 5.0.4xx scenario that seems right — those SDKs were deliberately shipped to let people target EOL frameworks, so warning about EOL and pointing at the download page would be actively wrong.

I'll add a regression test for case 3 (EOL channel + unknown SDK -> null) so the behaviour doesn't drift.

[joeloff]

@baronfel do we have a tracking issue for docs?

[JamieMagee]

@joeloff No tracking issue, but I opened dotnet/docs#53870 with the three error pages and supporting cross-references.