Why are NuGet project references not included?

[Whathecode]

I'm trying to generate an SBOM using sbom-tool, which uses this package to find dependencies through NuGet configurations. I noticed that project references are missing.

When running component-detection in isolation, I noticed that project references are also omitted in the output. Running a debugger, I can see that there is specific code to parse them, but, they get filtered out in final NavigateAndRegister().

What is the reason for this? This means that I won't see components used by these projects, which is a requirement for my SBOM output. This code was introduced in the "initial commit", so not much more information I can gather from git history.

When removing the early out for || library.Type == ProjectDependencyType, output seems to work fine. Except, the project references show up as "NuGet" references in the ScanManifest, instead of "project" references. I.e., they have " - NuGet" appended to their name and version.

[Whathecode]

Any input on this? As we are approaching another round of needed SBOM output, I'd like to assess whether we should at all rely on this tool. Maybe @melotic ?

[grvillic]

Hi @Whathecode, for historical reasons these dependencies (framework / project) were being considered noisy by customers since they were related to the SDK itself not your app, this was indirectly triggering a ton of security alerts. That being said, after revisiting the problem and the importance of SBOM in the last few years, we concluded that we need to reintroduce all of these. This change should have happened downstream at report level based on customer needs, not at the detection level.

We need to tweak other processes downstream before shipping this but expect it to be released by end of October 2024.

[grvillic]

Update: We are first validating the framework dependency rollout (see #1285). Once enabled by default, we will proceed with the project reference declaration. Framework dependencies should be included and rolled out by the end of November.

Due to the upcoming holiday season, we lack the resources to validate and ship the "project" references before December. Expect delivery early next year (January 2025).

[ericstj]

Exposing project references as PackageReferences might be the right thing to do if those projects are packable and are not PrivateAssets. In those cases the project reference would become a package reference when packed, so the identity is correct and should map to a "real" package.

I wonder what should be done for project-references to non-packable projects (IsPackable=false), or to projects with PrivateAssets="All"

In the case of a non-packable project, the name of the project is not a true component name and could coincidently collide with actual package names but be completely different. In the case of private assets the project might have a reference to the project and it's dependencies at build - but those wouldn't be persisted if the project was packed. Including those might not be the right thing if you were trying to produce an SBOM for the shipping package.