fix(pipelines): route NuGet version check through CFS feed to resolve CFSClean violation

[gavinbarron]

Summary

Resolves the single CFSClean (SFI-ES4.2.4 network isolation) violation flagged in the build stage's 🔒 Stop Network Isolation step of the Dotnet Beta Preview pipeline (ADO pipeline ID 199, pipelines/ci-build.yml).

Exact finding / log evidence

From the build job's "Stop Network Isolation" step log (build 227727, log id 68):

Policy: CFSClean - Policy required for SFI compliance. Status = [ NOT COMPLIANT ] (1 violations)
##[group]api.nuget.org
  Domain name: api.nuget.org
  Service tags: AzureFrontDoor.Frontend
  IP address: 13.107.226.40
  Process path: C:\Program Files\PowerShell\7\pwsh.exe
  Task name: PowerShell
##[endgroup]

Policy: CFSClean2 - Status = [ COMPLIANT ]
Policy: CFSClean3 - Status = [ COMPLIANT ]
Policy: Default Deny - Status = [ COMPLIANT ]

Root cause

The Validate updated version PowerShell@2 step (running scripts/ValidateUpdatedNugetVersion.ps1) calls the public NuGet.org search API directly via Invoke-RestMethod to check whether the current csproj version has already been published. This is a direct connection from a pwsh.exe/PowerShell process to a public package registry domain (api.nuget.org/azuresearch-usnc.nuget.org), which trips the CFSClean policy — separate from and unrelated to the earlier dotnet restore CFS fix (#1139), which only covered the restore operation.

A prior commit on this branch (avoid blocked NuGet registration endpoint) had already swapped one direct nuget.org endpoint for another (registration API → search API) to fix a functional blocking issue, but neither endpoint is CFS-routed, so the compliance violation persisted.

Fix

• scripts/ValidateUpdatedNugetVersion.ps1: added a required -nugetConfigPath parameter and replaced the raw Invoke-RestMethod call to the public NuGet.org search API with dotnet package search --configfile <nuget.config>, querying the same Central Feed Service (CFS) feed already configured and authenticated (via NuGetAuthenticate@1) for dotnet restore. That feed has NuGet.org configured as an upstream source, so it transparently proxies the search — keeping the check functional while eliminating the direct-to-public-registry network call.
• pipelines/ci-build.yml: pass -nugetConfigPath "$(Build.SourcesDirectory)\nuget.config" (the file already created by the earlier Create nuget.config (central feed) step) to the script invocation.

Validation

• PowerShell parser check: [System.Management.Automation.Language.Parser]::ParseFile(...) — no syntax errors.
• Functional dry-run locally with a temporary nuget.config pointed at https://api.nuget.org/v3/index.json (as a stand-in for the private CFS feed, to prove the dotnet package search --configfile mechanism) covering all three script branches:
  • Version already ahead of latest published → Validated that the version has been updated ... (exit 0)
  • Version not incremented (matches/behind latest published) → Write-Error with the original message (unchanged behavior)
  • Non-existent package name → graceful No package exists... first-time-publish message (exit 0)
• Confirmed no other files reference the script's old two-argument signature.

Cannot trigger a live ADO run from this session to directly re-confirm the Stop Network Isolation compliance status, but the fix eliminates the only direct public-registry call in the build job, matching the same remediation pattern already used for dotnet restore.

Microsoft Reviewers: Open in CodeFlow