Enable SDL Roslyn analysis (incl. internal IA* analyzers) in the OneBranch build

[paulmedynski]

Description

Runs the SDL Roslyn analyzers (including the internal IA* rules) as part of the OneBranch build, and upgrades the Windows build container to Server 2025. Engineering-process/CI only — no product code or public API is affected.

This PR targets the dev/paul/apiscan branch, which provides the shared Guardian SDL plumbing (globalSdl.baseline.baselineFile and the breakOnSdlError parameter). On top of that base, this change adds the analyzer execution, the internal IA* rules, and the Roslyn entries in the baseline.

Windows Server 2025 build image

• Upgraded the Windows build container to ltsc2025/vse2026 and set WindowsHostVersion: { Version: 2025 } so the host and container OS versions match.
• Documented the host-vs-container relationship (and why LinuxHostVersion is not set — Linux containers share the host kernel), plus the legacy CDPx PAT flag (EnableCDPxPAT: false).

Roslyn analysis via "Copy Logs Only"

.NET Roslyn analyzers are compiler-integrated — they only run during the real csc compilation. build.proj is an orchestrator that compiles each package in a separate child dotnet build via <Exec>, so analyzer properties injected onto the outer command never cross into the real compiles. That is why the earlier auto/manual-mode attempts collected 0 SARIF. Instead, the analyzers are baked into the leaf builds and the RoslynAnalyzers@3 task runs in Copy Logs Only mode:

• build.proj gains an EnableAnalyzers flag that is forwarded into every leaf dotnet build.
• src/Directory.Build.props reacts by enabling the full analyzer set (AnalysisLevel=latest-all + IDE style rules) and emitting one SARIF v1 log per project. ErrorLog intentionally omits ,version=2, because the Guardian sanitizer deserializes SARIF v1 (a v2 log throws and is dropped).
• The step runs an isolated analysis build (IsolatedBuildPath redirects each project's bin and forces a full recompile) so it never disturbs real build output, then the task only collects/sanitizes the *.csproj.*.sarif logs. Because Copy Logs Only performs no build, it needs no MSBuild and is agnostic to the container's VS/MSBuild version. A guard step fails fast if a package produced no SARIF.

Internal IA* analyzers (private ADO.Net pipeline only)

AnalysisLevel=latest-all covers the CA* rules but not the internal Microsoft.Internal.Analyzers ("IA*") rules. That package is Microsoft-internal and confidential, so:

• It is referenced only when InternalAnalyzers=true (gated in Directory.Build.props / Directory.Packages.props, PrivateAssets=all, so it never ships).
• The step generates a private NuGet.config at runtime pointing at the internal feed, with packageSourceMapping scoping Microsoft.Internal.* to that feed so the confidential package never touches the public governed feed.
• The feed URL and pinned version come from the internal-analyzers-variables-v1 variable group, defined only in the private ADO.Net project. No public/private gate is needed because the OneBranch pipelines run only in that project.

SDL baseline

• Adds the pre-existing Roslyn findings (826: CA / IDE / SYSLIB) into the committed .config/guardian/.gdnbaselines, merged with the base branch's non-Roslyn entries (835 total), so official builds only fail on new findings.
• Baseline burn-down is tracked in ADO.Net Feature #46588 with a Roslyn-specific child User Story #46614.

Testing

• sqlclient-non-official 26203.5 (162422) — analyzers run across all packages, SARIF produced, per-package baselines generated. IA* verified loaded (IA5352 in the rule catalog; 0 active findings).
• sqlclient-non-official 26203.6 (162468) — committed .gdnbaselines loaded by Guardian Post-Analysis.
• sqlclient-official — validate the baseline suppresses the Roslyn findings under break (only the official pipeline adds Roslyn to the Guardian break tool-filter, so this is the run that actually exercises the baseline).

[Copilot]

Pull request overview

Updates OneBranch pipeline configuration to modernize the Windows build environment to Windows Server 2025 / VS 2026 containers and to make Roslyn Analyzers SDL run reliably on the new image by switching the task to auto-detected build replay.

Changes:

• Upgraded the OneBranch Windows container image to ltsc2025/vse2026.
• Set WindowsHostVersion: { Version: 2025 } (and documented host-vs-container expectations) in both official and non-official OneBranch pipelines.
• Switched Roslyn Analyzers to auto mode and added a preceding “throwaway” dotnet build so the task can detect/replay compilation from logs; removed the now-unused packageVersion pass-through to that analyzer template.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
eng/pipelines/onebranch/variables/onebranch-variables.yml	Bumps Windows container image to ltsc2025/vse2026 and adds a doc link for OneBranch images.
eng/pipelines/onebranch/steps/roslyn-analyzers-buildproj-step.yml	Moves Roslyn analyzers to auto-detected build replay with a preceding DotNetCoreCLI@2 build for log generation; drops unused packageVersion parameter.
eng/pipelines/onebranch/sqlclient-official.yml	Sets WindowsHostVersion to 2025 and adds detailed documentation about host/container relationship and CDPx PAT injection.
eng/pipelines/onebranch/sqlclient-non-official.yml	Same host-version and documentation updates as the official pipeline.
eng/pipelines/onebranch/jobs/build-buildproj-job.yml	Removes passing packageVersion into the roslyn analyzers step template (since it no longer accepts/needs it).

[paulmedynski]

The Roslyn template no longer needs this value.

[paulmedynski]

Enable the latest tooling and environment for Windows jobs.

[Copilot]

Pull request overview

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

Comments suppressed due to low confidence (1)

eng/pipelines/onebranch/steps/roslyn-analyzers-buildproj-step.yml:98

• This comment refers to the OAuth token env var as system_accesstoken, but the task is actually configured with the standard SYSTEM_ACCESSTOKEN name right below. Updating the comment avoids confusion when troubleshooting log-access failures.

  # analyzers. Requires OAuth token access (system_accesstoken) to read the build logs.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 62.43%. Comparing base (d040700) to head (7d25985).

❗ There is a different number of reports uploaded between BASE (d040700) and HEAD (7d25985). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (d040700)	HEAD (7d25985)
CI-SqlClient	1	0

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4464      +/-   ##
==========================================
- Coverage   70.88%   62.43%   -8.45%     
==========================================
  Files         288      283       -5     
  Lines       43935    66821   +22886     
==========================================
+ Hits        31142    41723   +10581     
- Misses      12793    25098   +12305     

Flag	Coverage Δ
CI-SqlClient	?
PR-SqlClient-Project	62.43% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ 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.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

eng/pipelines/onebranch/steps/roslyn-analyzers-buildproj-step.yml:179

• The PR description says the SDL RoslynAnalyzers task was switched to auto mode (userProvideBuildInfo: autoMsBuildInfo) where the task re-runs the detected build. The current template instead performs an explicit DotNetCoreCLI build and uses RoslynAnalyzers in copyLogsOnly: true mode. Please update the PR description (or the implementation) so they match, to avoid future maintainers debugging the wrong behavior.

  - task: securedevelopmentteam.vss-secure-development-tools.build-task-roslynanalyzers.RoslynAnalyzers@3
    displayName: 'Roslyn Analyzers (collect) - build.proj Build${{ parameters.packageShortName }}'
    inputs:
      copyLogsOnly: true
      # Root to search for the *.csproj.*.sarif logs. The analysis build wrote them next to each

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

eng/pipelines/onebranch/steps/roslyn-analyzers-buildproj-step.yml:203

• The PR description says the RoslynAnalyzers task was switched to auto mode (autoMsBuildInfo) where it re-runs the detected build command. This template now runs RoslynAnalyzers@3 in copyLogsOnly: true mode and performs the build itself via DotNetCoreCLI, so the implementation and PR description are out of sync. Please update the PR description to reflect the current approach (Copy Logs Only + integrated analyzers), or adjust the YAML to match the described auto-mode behavior.

  # Step 2: Collect the analysis results. In Copy Logs Only mode the task does not build or re-run
  # the compiler -- it just gathers and sanitizes the *.csproj.*.sarif logs produced by Step 1 and
  # hands them to Guardian/SDL. No msBuildVersion / msBuildArchitecture / VS setup is involved, and
  # no OAuth token is needed (nothing is queried from Azure DevOps).
  - task: securedevelopmentteam.vss-secure-development-tools.build-task-roslynanalyzers.RoslynAnalyzers@3
    displayName: 'Roslyn Analyzers (collect) - build.proj Build${{ parameters.packageShortName }}'
    inputs:
      copyLogsOnly: true
      # Root to search for the *.csproj.*.sarif logs. The analysis build wrote them next to each
      # project under the repo checkout; the collector globs this directory recursively.
      logRootDirectory: '$(REPO_ROOT)'

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

eng/pipelines/onebranch/steps/roslyn-analyzers-buildproj-step.yml:10

• The PR description says the RoslynAnalyzers step was switched to auto mode (autoMsBuildInfo) where the task re-runs the detected build command. The updated template here instead implements the "integrated analyzers + Copy Logs Only" flow (self-run DotNetCoreCLI build + copyLogsOnly collector) and explicitly states the task performs no build/re-run. Please update the PR description so it matches the actual implementation in this file.

# This template runs Roslyn Analyzers (SDL) against a build.proj target using the RoslynAnalyzers@3
# task from the Secure Development Team's SDL extension, in "Copy Logs Only" mode:
#
# https://eng.ms/docs/cloud-ai-platform/devdiv/one-engineering-system-1es/1es-mohanb/security-integration/guardian-wiki/sdl-azdo-extension/roslyn-analyzers-build-task

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (2)

src/Directory.Build.props:40

• This comment says the build emits “SARIF v2” logs, but the later note (and the ErrorLog value without ",version=2") indicates we intentionally emit SARIF v1 to satisfy the Guardian sanitizer. Updating the comment avoids a contradiction in the same block.

    When EnableAnalyzers is set (by the SDL Roslyn Analyzers pipeline step, forwarded from
    build.proj's EnableAnalyzers property), run as many Roslyn analyzers as possible and emit a
    per-project SARIF v2 log. The RoslynAnalyzers task then runs in "Copy Logs Only" mode and
    collects these logs.

build.proj:288

• This description says EnableAnalyzers emits a “SARIF v2” log, but Directory.Build.props intentionally avoids ",version=2" so the compiler produces SARIF v1 (per the sanitizer requirement). Update the comment to match the actual output format.

                      compiled and makes each project emit a per-project SARIF v2 log (see the

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (3)

src/Directory.Build.props:40

• The header comment says this emits a per-project “SARIF v2” log, but the subsequent comment and the actual configuration intentionally rely on the compiler default SARIF v1 output (no ",version=2") to satisfy the Guardian sanitizer. The “v2” mention is misleading and should be corrected to “v1”.

  <!-- SDL Roslyn analysis pass ======================================== -->
  <!--
    When EnableAnalyzers is set (by the SDL Roslyn Analyzers pipeline step, forwarded from
    build.proj's EnableAnalyzers property), run as many Roslyn analyzers as possible and emit a
    per-project SARIF v2 log. The RoslynAnalyzers task then runs in "Copy Logs Only" mode and
    collects these logs.

build.proj:291

• The build.proj documentation for EnableAnalyzers says it produces a “per-project SARIF v2 log”, but Directory.Build.props is explicitly configured to emit SARIF v1 (no ",version=2") due to the Guardian sanitizer limitation. Update this comment to avoid future confusion.

    <!--
      EnableAnalyzers
      Applies to:     Build* targets (driver and extension projects)
      Description:    When true, turns on the full set of Roslyn analyzers for every project that is
                      compiled and makes each project emit a per-project SARIF v2 log (see the
                      EnableAnalyzers block in src/Directory.Build.props). This is consumed by the
                      SDL Roslyn Analyzers pipeline step, which builds with EnableAnalyzers=true and
                      then collects the SARIF logs in "Copy Logs Only" mode.

eng/pipelines/onebranch/steps/roslyn-analyzers-buildproj-step.yml:209

• PR description notes switching RoslynAnalyzers@3 to auto mode (autoMsBuildInfo) where the task re-runs the detected build command, but this template uses Copy Logs Only (copyLogsOnly: true) and performs a separate DotNetCoreCLI build to generate SARIF. Please update the PR description to match the implemented approach (or, if auto mode is still intended, adjust the task inputs accordingly).

  # Step 3: Collect the analysis results. In Copy Logs Only mode the task does not build or re-run
  # the compiler -- it just gathers and sanitizes the *.csproj.*.sarif logs produced by Step 1 and
  # hands them to Guardian/SDL. No msBuildVersion / msBuildArchitecture / VS setup is involved, and
  # no OAuth token is needed (nothing is queried from Azure DevOps).
  - task: securedevelopmentteam.vss-secure-development-tools.build-task-roslynanalyzers.RoslynAnalyzers@3
    displayName: 'Roslyn Analyzers (collect) - build.proj Build${{ parameters.packageShortName }}'
    inputs:
      copyLogsOnly: true
      # Root to search for the *.csproj.*.sarif logs. The analysis build wrote them next to each
      # project under the repo checkout; the collector globs this directory recursively.
      logRootDirectory: '$(REPO_ROOT)'

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (2)

src/Directory.Build.props:40

• The comment says the analysis emits a per-project SARIF v2 log, but the same block later documents that the Roslyn sanitizer only accepts SARIF v1 and explicitly warns not to append ",version=2". This is internally inconsistent and could cause someone to “fix” the pipeline back to v2 and reintroduce the sanitizer failure.

  <!--
    When EnableAnalyzers is set (by the SDL Roslyn Analyzers pipeline step, forwarded from
    build.proj's EnableAnalyzers property), run as many Roslyn analyzers as possible and emit a
    per-project SARIF v2 log. The RoslynAnalyzers task then runs in "Copy Logs Only" mode and
    collects these logs.

build.proj:289

• This build.proj doc comment claims EnableAnalyzers makes projects emit SARIF v2 logs, but src/Directory.Build.props configures ErrorLog to produce SARIF v1 (no ",version=2") specifically because the Guardian sanitizer only deserializes v1. The comment should match the actual log format to avoid reintroducing the sanitizer regression.

      Description:    When true, turns on the full set of Roslyn analyzers for every project that is
                      compiled and makes each project emit a per-project SARIF v2 log (see the
                      EnableAnalyzers block in src/Directory.Build.props). This is consumed by the

[Copilot]

Pull request overview

Copilot reviewed 10 out of 11 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (3)

src/Directory.Build.props:39

• The comment says this emits a per-project "SARIF v2" log, but the ErrorLog configuration below intentionally produces SARIF v1 (no ",version=2") to satisfy the Guardian sanitizer. Update the comment to avoid a misleading version mismatch.

    per-project SARIF v2 log. The RoslynAnalyzers task then runs in "Copy Logs Only" mode and

build.proj:288

• This description says each project emits a per-project SARIF v2 log, but the repo-wide analyzer configuration intentionally produces SARIF v1 (no ",version=2") for compatibility with the RoslynAnalyzers sanitizer. The comment should match the actual log version to prevent confusion when troubleshooting.

                      compiled and makes each project emit a per-project SARIF v2 log (see the

eng/pipelines/onebranch/steps/roslyn-analyzers-buildproj-step.yml:159

• The comment claims packageSourceMapping "pins" Microsoft.Internal.* to the internal feed, but the generated mapping also allows all packages (including Microsoft.Internal.) to restore from the governed/local sources due to the "" patterns. Please reword this to describe what the mapping actually guarantees (that the internal feed is available for Microsoft.Internal.*) without overstating exclusivity.

  # Step 0a: Generate a private NuGet.config that adds the internal feed hosting
  # Microsoft.Internal.Analyzers. packageSourceMapping pins Microsoft.Internal.* to the internal feed
  # and routes every other package to the existing governed/local sources, so no other restore is
  # redirected. The config is handed to the leaf builds via -p:InternalAnalyzersNugetConfig

[Copilot]

Pull request overview

Copilot reviewed 10 out of 11 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (3)

src/Directory.Build.props:39

• The comment says the analysis pass emits a SARIF v2 log, but the ErrorLog configuration below explicitly avoids ",version=2" so the compiler emits SARIF v1. Update the comment to match the actual output format (v1).

    per-project SARIF v2 log. The RoslynAnalyzers task then runs in "Copy Logs Only" mode and

build.proj:288

• This documentation claims EnableAnalyzers causes projects to emit SARIF v2 logs, but the repo configuration intentionally emits SARIF v1 (no ",version=2") for compatibility with the Guardian Roslyn sanitizer. Update the comment to avoid misleading future maintainers.

                      compiled and makes each project emit a per-project SARIF v2 log (see the

eng/pipelines/onebranch/steps/roslyn-analyzers-buildproj-step.yml:158

• The comment claims packageSourceMapping "pins" Microsoft.Internal.* to the internal feed, but the config also maps "" to governed/local, so Microsoft.Internal. can still match those sources as well. Consider rewording to the more precise behavior (the internal feed is restricted to Microsoft.Internal.*; other packages aren’t redirected).

  # Microsoft.Internal.Analyzers. packageSourceMapping pins Microsoft.Internal.* to the internal feed
  # and routes every other package to the existing governed/local sources, so no other restore is

[Copilot]

Pull request overview

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

Comments suppressed due to low confidence (3)

src/Directory.Build.props:40

• The comment says the analyzer build emits a per-project “SARIF v2” log, but this block intentionally avoids ",version=2" and relies on the compiler’s default ErrorLog format (SARIF v1) for Guardian compatibility. Updating the comment avoids future regressions where someone “fixes” it back to v2 and breaks sanitizer ingestion.

    When EnableAnalyzers is set (by the SDL Roslyn Analyzers pipeline step, forwarded from
    build.proj's EnableAnalyzers property), run as many Roslyn analyzers as possible and emit a
    per-project SARIF v2 log. The RoslynAnalyzers task then runs in "Copy Logs Only" mode and
    collects these logs.

build.proj:288

• This comment says EnableAnalyzers emits a per-project SARIF v2 log, but the build is configured (via src/Directory.Build.props) to emit SARIF v1 (no ",version=2") due to the current Guardian Roslyn sanitizer requirement. Keeping the docs consistent will prevent confusion when troubleshooting SDL ingestion.

                      compiled and makes each project emit a per-project SARIF v2 log (see the

eng/pipelines/onebranch/steps/roslyn-analyzers-buildproj-step.yml:271

• The PR description says the RoslynAnalyzers task was switched to autoMsBuildInfo (auto mode that detects and re-runs a build). The updated template instead performs an explicit DotNetCoreCLI build that emits per-project SARIF and then runs RoslynAnalyzers@3 in Copy Logs Only mode (copyLogsOnly: true). Please align the PR description with the implemented approach (or adjust the template if auto mode is still desired).

  # Step 3: Collect the analysis results. In Copy Logs Only mode the task does not build or re-run
  # the compiler -- it just gathers and sanitizes the *.csproj.*.sarif logs produced by Step 1 and
  # hands them to Guardian/SDL. No msBuildVersion / msBuildArchitecture / VS setup is involved, and
  # no OAuth token is needed (nothing is queried from Azure DevOps).
  - task: securedevelopmentteam.vss-secure-development-tools.build-task-roslynanalyzers.RoslynAnalyzers@3
    displayName: 'Roslyn Analyzers (collect) - build.proj Build${{ parameters.packageShortName }}'
    inputs:
      copyLogsOnly: true
      # Root to search for the *.csproj.*.sarif logs. The analysis build wrote them next to each

[Copilot]

Pull request overview

Copilot reviewed 12 out of 13 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (3)

src/Directory.Build.props:40

• The header comment says the analysis pass emits a per-project SARIF v2 log, but later in this same block it correctly notes that the Guardian Roslyn sanitizer only accepts SARIF v1 and the build intentionally avoids ",version=2". The comment should say SARIF v1 (or just “SARIF”) to avoid contradicting the actual behavior.

    When EnableAnalyzers is set (by the SDL Roslyn Analyzers pipeline step, forwarded from
    build.proj's EnableAnalyzers property), run as many Roslyn analyzers as possible and emit a
    per-project SARIF v2 log. The RoslynAnalyzers task then runs in "Copy Logs Only" mode and
    collects these logs.

build.proj:291

• This build.proj doc comment says EnableAnalyzers emits “SARIF v2”, but Directory.Build.props intentionally emits SARIF v1 (no ",version=2") due to the Roslyn sanitizer’s v1 requirement. Updating the comment avoids misdocumenting the pipeline’s expected log format.

      Description:    When true, turns on the full set of Roslyn analyzers for every project that is
                      compiled and makes each project emit a per-project SARIF v2 log (see the
                      EnableAnalyzers block in src/Directory.Build.props). This is consumed by the
                      SDL Roslyn Analyzers pipeline step, which builds with EnableAnalyzers=true and
                      then collects the SARIF logs in "Copy Logs Only" mode.

eng/pipelines/onebranch/steps/roslyn-analyzers-buildproj-step.yml:159

• The comment claims the generated NuGet.config “pins” Microsoft.Internal.* to the internal feed, but the current packageSourceMapping also maps "" to both governed and local sources. That means Microsoft.Internal. matches multiple sources, so it isn’t actually pinned to the internal feed. Please adjust the wording (or the mapping) so the comment matches the behavior.

  # Microsoft.Internal.Analyzers. packageSourceMapping pins Microsoft.Internal.* to the internal feed
  # and routes every other package to the existing governed/local sources, so no other restore is
  # redirected. The config is handed to the leaf builds via -p:InternalAnalyzersNugetConfig