Exclude non-shipping code from CG

[Heath Stewart (heaths)]

Ignore sample and test directories so Component Governance reports only dependencies relevant to shipping SDK code.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

Copilot-Session: 900fd06f-19a5-4914-a9ca-8d9f6ee3b327

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
3 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Heath Stewart (heaths)]

For context, we don't commit Cargo.lock files for samples or tests so CG is falling back to cargo metadata which, for a lot of those projects, will show ring. If I generate SBOM JSONs for every Cargo.toml outside of target/ CG finds based on the pipeline logs, I don't find the string #ring@ at all—this would be a substring that is unique to ring and not something like stringify or something in the id property of the SBOM JSON document.

For now, I'm not excluding target/ because 1) I don't find ring in there anyway, and 2) it seems CG should scan all resolved dependencies. But if there is still a problem, we might exclude just target/debug/deps/** because those are just dependencies. Any of our crates' dependencies would be directly in target/debug—though also duplicated in target/debug/deps if used as a dependency, but it's a dup so nothing lost.

Another option considered and rejected was to build SBOMs for everything so that CG didn't fall back to cargo metadata. It wouldn't be hard for samples/ for example:

CARGO_BUILD_SBOMS=true find samples/ -name Cargo.toml -execdir cargo +nightly -Z sbom build --all-features --locked

But we have various test projects at different levels and no doubt would have more in the future and I don't want to start "littering" a bunch of partner projects (or even core) in a shared file. It's not scalable and would require frequent maintenance.

[Copilot]

Pull request overview

Configures Component Governance to omit dependencies found in non-shipping sample and test directories.

Changes:

• Adds exclusion globs for root samples and nested test directories.

Show a summary per file

File	Description
eng/pipelines/templates/variables/globals.yml	Adds Component Detection directory exclusions.

Review details

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

• Files reviewed: 1/1 changed files
• Comments generated: 0
• Review effort level: Balanced

[Heath Stewart (heaths)]

/azp run rust - canary

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Heath Stewart (heaths)]

/azp run rust - canary

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Heath Stewart (heaths)]

This appears to be fixed now. If necessary, we'll have to use --artifact-dir to move our final artifacts from target/ and exclude target/ as well. CG is still finding a lot of stuff it's trying to run cargo metadata on in there which will always yield false positives. When I generated SBOMs over all Cargo.toml files that we own, ring was found in 0 of them.

[Heath Stewart (heaths)]

Another future possibility is to set the DisableRustCliScan env var described in https://github.com/microsoft/component-detection/blob/main/docs/detectors/rust.md. Seems that would disable falling back to cargo metadata entirely, for which we'll always get false positives. It's not clear from the description, however, how that would affect mapping of crates to SBOMs.