Compliancy story for the VMR

[premun]

Context

The VMR is a projection of sources of all product repos and with it come all the problems such as making sure the repo is compliant. This issue is about investigating what is the final set of scans and validations we should run and when and how to run them. The scope should be ranging from CG through Secure Supply chain and SDL to 1ES PT scans such as CodeQL.

Problems

There are several problems we already know about:

• CodeQL runs too long on Windows for a repo of this size.
• Suppressed CG alerts coming from product repositories will re-surface in the VMR. The dismissal in t he AzDO UI won't transfer and the VMR will get flagged again.
• Alerts showing in the VMR need to be routed to some owners from their original repositories.
• Submodules of 3rd party repos can contain problems which will surface in the VMR as they are inlined in the repo.
• Many scans run in all builds of all platforms, no matter how different these are.

Business goal

We have a responsible and sustainable compliancy solution for the VMR.

Related docs

https://eng.ms/docs/cloud-ai-platform/devdiv/one-engineering-system-1es/1es-docs

Related issues

• [x] https://github.com/dotnet/source-build/issues/3152

[mthalman]

Another aspect to consider is Guardian suppression files. Those may be added in a product repos to handle suppression of certain errors from Guardian in their CI builds. But when the offending source flows into the VMR, the product repo's suppression file is not used by the VMR build and the error would be reported for the VMR but not the product repo.

[ellahathaway]

This related issue also popped up yesterday: https://github.com/dotnet/source-build/issues/4294.

I'm seeing SDL issues at the product level but not in all the individual repos. It seems like many repos have fixed the SDL issue at the repo level by syncing with arcade, but those updated repos have not been syncing into the VMR.