ci: query only nuget.org in the vulnerable-packages scan

[jamescrosswell]

The nightly List vulnerable packages job has failed on every run since #5513 enabled the gate:

error: Response status code does not indicate success: 401 (Unauthorized - No local versions of
package 'nsubstitute'; please provide authentication to access versions from upstream that have
not yet been saved to your feed.)

Same feed, same 401, as #5528 — but a different code path.

#5528 scoped perfview-build to the package it provides, which fixed restore. But dotnet package list --vulnerable ignores packageSourceMapping and queries every configured source for every package. perfview-build proxies an upstream it can't authenticate to, so it answers 401 — not 404 — for anything it hasn't already cached, and NuGet treats a 401 from any source as fatal.

Minimal reproduction, a single PackageReference to NSubstitute alongside the repo's nuget.config:

	result
dotnet restore	✅ succeeds — mapping honoured, perfview-build never queried
dotnet package list --vulnerable	❌ 401 … No local versions of package 'nsubstitute'

Probing the feeds directly confirms perfview-build is the only one that fails this way — dotnet-eng and mattleibow return a clean 404 for an unknown package, and dotnet-public returns 200.

Fix

nuget.org is the only configured feed that publishes vulnerability data at all, so --source https://api.nuget.org/v3/index.json (i.e. don't check any sources except nuget.org) removes the failure without narrowing coverage.

Verification

Against the real Sentry.slnx, the command in the diff completes with no 401 and produces the full report for all projects. Running the step's rendered script under CI's exact shell flags (bash --noprofile --norc -e -o pipefail) exits 1 with the intended annotation:

::error::Vulnerable packages detected - see the job output above for the affected projects and advisories.

Dispatched against this branch to confirm end-to-end: run 33705427479. No 401 anywhere in the log, The following sources were used: lists nuget.org alone, the scan runs to completion across all projects, and the step fails with the annotation "Vulnerable packages detected - see the job output above for the affected projects and advisories." — 17 projects flagged.

The job will still be red after this — as designed

The scan reports genuine advisories (Newtonsoft.Json in Sentry.Hangfire, log4net in Sentry.Log4Net, OpenTelemetry.Api in Sentry.OpenTelemetry, …), all minimum-version floors inherited from direct dependencies. Clearing them raises our published minimums and is tracked by #5275 under Breaking Change / Next Major.

#skip-changelog

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.67%. Comparing base (993c333) to head (b184489).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5534      +/-   ##
==========================================
+ Coverage   74.65%   74.67%   +0.02%     
==========================================
  Files         515      515              
  Lines       18909    18909              
  Branches     3691     3691              
==========================================
+ Hits        14117    14121       +4     
+ Misses       3907     3904       -3     
+ Partials      885      884       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sentry]

Bug: The --source flag on dotnet package list --vulnerable may supplement, not override, configured NuGet sources, causing the original authentication error to persist.
_{Severity: MEDIUM}

Suggested Fix

Verify the exact behavior of the --source flag for dotnet package list --vulnerable with the project's .NET SDK version. If it supplements sources, consider temporarily modifying the nuget.config file during the CI step to remove private feeds before running the vulnerability scan, then restoring it afterward. This ensures only the public feed is used.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: .github/workflows/vulnerabilities.yml#L43

Potential issue: The change adds a `--source` flag to the `dotnet package list
--vulnerable` command, intending to prevent authentication errors from private NuGet
feeds. However, evidence suggests that for this specific command, the `--source` flag
might supplement the feeds from `nuget.config` instead of overriding them. If this is
the case, the command will still attempt to access private feeds like `perfview-build`,
and the original 401 authentication error will persist, rendering the fix ineffective.
The behavior of this flag is not well-documented for the specific .NET SDK version used,
creating a risk that the CI job will continue to fail.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[jamescrosswell]

False positive.

Run 33823156701 on this PR's head (b1844893, SDK 10.0.400 — the same SDK the nightly uses) shows the command self-reporting its effective source set as:

The following sources were used:
   https://api.nuget.org/v3/index.json