Devise a strategy to deal with component governance alerts from SBRP

[MichaelSimons]

The SBRP repo has component governance (CG) alerts reported against the reference packages it produces from time to time. This causes CG alerts to reported against most product repos because of their dependency on SBRP in the source-build CI legs. This prompts a number of questions/issues to be raised for the source-build team to respond to. These CG alerts are in a way invalid as they are reported against reference packages which have no implementation.

To address the alerts in SBRP two things have to occur.

1. All product references to the vulnerable packages have to be removed/upgraded. To support upgrades, the new version must be added to SBRP. It is not the responsibility of the source-build team to perform this step, it is the repo owners.
2. Any references to the vulnerable packages within SBRP must be upgraded. This must be done manually by the source-build team.

After all references to the vulnerable packages have been removed/upgraded, only then can the vulnerable packages be removed and the CG alert will be considered addressed. This process can take a long time because of dependency flows.

What can the source-build team do to streamline this process? What can be done to avoid being pinged by so many repo teams with there are CG alerts in SBRP? A document will help but are there other things that can be done?

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[MichaelSimons]

cc @mmitche, @mthalman

[MichaelSimons]

We should explore if there is an option to ignore the packages coming from SBRP that are not actually used. This would be an ideal solution because if the package is actually used, the CG alert would still get reported.

Alternatively we could ask the CG folks if there is a way to ignore the SBRP packages as they are not the real package that has the vulnerability.

[mmitche]

Update on this. I've managed to get CG to exclude the extracted location for the source build upstream cache, but it's still picking up the source build intermediate packages that end up in the build's package cache. There is no way to ignore paths with wildcards.

One solution to this would be to avoid using a PackageReference for source build intermediates, and instead use a package download. That would mean you could extract the contained nupkgs to the predictable upstream package path but not have them show up in the local package cache.

[mmitche]

https://dev.azure.com/dnceng/internal/_build/results?buildId=2233975&view=results

This arcade build attempts to delete the intermediate nupkg after its contents have been moved to the local nupkg cache.

[mmitche]

https://dev.azure.com/dnceng/internal/_build/results?buildId=2234119&view=logs&j=2f0d093c-1064-5c86-fc5b-b7b1eca8e66a&t=20c732f6-a6a9-5126-4712-50e32916e5f1