search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.67k stars 1.06k forks source link

Develop process to validate SDK does not include any vulnerable components #41659

Open MichaelSimons opened 3 months ago

MichaelSimons commented 3 months ago

A validation process is needed to ensure the SDK does not include any vulnerable components. This includes pre-disclosed vulnerabilities. See https://github.com/dotnet/dotnet-docker/issues/5325 and https://github.com/dotnet/sdk/issues/30659 for the background and how these may be "false positives". This validation should be automated and run as part of CI to ensure the SDK is in a clean state prior to shipping.

marcpopMSFT commented 3 months ago

I do not believe this is possible with the tooling we have today. CG doesn't check for false positives in the deps.json file which we want to be clean on and doesn't flag before we release.

If the runtime knows a specific component is getting a security fix, we could potentially check every branch but that doesn't scale.

Potentially we could leverage nuget to tell us when a package is flagged assuming that support is coming @JonDouglas but that would still tell us after that component has shipped rather than before.

JonDouglas commented 3 months ago

NuGet doesn't check deps.json, but we can absolutely provide auditing at development time. Perhaps dogfooding the recent .NET 9 Preview 6 functionality for transitives will be an interesting exercise here for at least known vulnerable top-level and transitive packages.

https://github.com/dotnet/release-notes-drafts/pull/62

Do note that we simply report the awareness of what is vulnerable. There may in fact be false positives and future tooling and SBOM work will allow us to reduce these in the future.

/cc @zivkan & @nkolev92

ericstj commented 3 months ago

The way I was checking this was scanning all binaries/deps/packages in the product drop and looking for inconsistencies. Flagging where we are referencing or shipping something older than we are shipping elsewhere. EG we ship package A 3.0.0, but reference 2.0.0 in the product. It's actually pretty straight forward if you have broad enough scope.

This doesn't capture external things that need to update. For that we have CG. For external things that haven't released yet - suppose a package that only ships out of a repo outside of dotnet - we need to feed in the data to such a test. I still think that's possible without too much work. It's just a difference in the algorithm of determining latest. In the first category above, latest is the max(everything we ship). For this case it would be the max(everything we ship, some data source).