Feature request: exclude ProjectReference items from SBOM generation for .NET Framework projects

[chadwjames]

Summary

When running cdxgen from the latest master branch against a .NET Framework 4.8 solution, the tool records both assembly Reference entries and ProjectReference entries in the generated SBOM. ProjectReference entries point to projects within our own source tree and are not third-party components. I request an option to exclude ProjectReference items from SBOM generation or to treat them differently from external assembly references.

How I ran it

pnpm exec cdxgen -r -o x:\bom.json "..\CdxgenExample"

Environment

• cdxgen: latest master branch at time of testing
• Host OS: Windows 11 Business version 24H2

Observed behavior

cdxgen lists internal projects referenced via ProjectReference as components in the SBOM alongside third-party assemblies. This produces SBOM entries for our own projects, which pollutes the bill of materials and complicates supply chain audits.

An example excerpt from the generated bom.json showing project components and their SrcFile properties is shown below for clarity.

"components": [
  {
    "name": "ProjectReferenceTwo",
    "purl": "pkg:nuget/ProjectReferenceTwo@latest",
    "type": "library",
    "properties": [
      { "name": "cdx:dotnet:project_guid", "value": "{13DFB5C8-DF54-4D1D-BDC4-B691F59930B2}" },
      { "name": "Namespaces", "value": "ProjectReferenceTwo" },
      { "name": "cdx:dotnet:target_framework", "value": "v4.8" },
      { "name": "SrcFile", "value": "..\\CdxgenExample\\ProjectReferenceTwo\\ProjectReferenceTwo.csproj" }
    ]
  },
  {
    "name": "ProjectReferenceOne",
    "purl": "pkg:nuget/ProjectReferenceOne@latest",
    "type": "library",
    "properties": [
      { "name": "cdx:dotnet:project_guid", "value": "{588A2416-35BA-46D8-BE34-74E07469AD5E}" },
      { "name": "Namespaces", "value": "ProjectReferenceOne" },
      { "name": "cdx:dotnet:target_framework", "value": "v4.8" },
      { "name": "SrcFile", "value": "..\\CdxgenExample\\ProjectReferenceOne\\ProjectReferenceOne.csproj" }
    ]
  }
]

Minimal example csproj fragment used in repro

Use this fragment to show the ProjectReference items that appear in the SBOM.

<ItemGroup>
  <ProjectReference Include="ProjectReferenceOne\ProjectReferenceOne.csproj">
    <Project>{588a2416-35ba-46d8-be34-74e07469ad5e}</Project>
    <Name>ProjectReferenceOne</Name>
  </ProjectReference>
  <ProjectReference Include="ProjectReferenceTwo\ProjectReferenceTwo.csproj">
    <Project>{13dfb5c8-df54-4d1d-bdc4-b691f59930b2}</Project>
    <Name>ProjectReferenceTwo</Name>
  </ProjectReference>
</ItemGroup>

Reproduction steps

1. Place the CdxgenExample solution as shown in the command above.
2. Run the command shown in the How I ran it section.
3. Inspect bom.json and observe that ProjectReferenceOne and ProjectReferenceTwo appear as components.

Expected behavior

Provide an option to exclude ProjectReference items by default or via an explicit flag so SBOMs list third party and supply chain components without internal project entries unless the user opts in to include them.

Proposed solution

Add a configuration option in the cdxgen config file such as includeProjectReferences: false.

Desired defaults and compatibility

Default behavior should exclude ProjectReference items to align with typical SBOM expectations. Provide an explicit flag or config option to preserve current behavior for users who wish project links recorded. This preserves backward compatibility while giving clearer semantics for SBOM consumers.

CdxgenExample.zip

bom.json

[prabhu]

Have you tried the "--filter" argument? You can pass the project name or the guid.

[chadwjames]

I just tried the filter argument and that removed the the project references from the bom file.

Thank you for the suggestion.

[john-madaras]

Hey @prabhu what would be a real-world scenario where someone might want the project references to be included? It's true that a referenced project could have a vulnerability, but the expectation would be that the referenced project would also be scanned by cdxgen so if contained a vulnerable nuget package (for example), it would be found that way. Listing the referenced projects as components creates noise in the results that would (normally) need to be filtered out. We have a very large solution with 200+ projects so this would be a very large filter exclusion for us that we'd have to maintain. Thoughts?

[prabhu]

There are users who need that information to know which sub-project contains a given vulnerability. In large enterprises, different projects could be owned and maintained by different teams and vendors.

[john-madaras]

Ah I see where that could be helpful internally. The problem for us (and I assume others) is that we have to provide SBOMs to our customers for our product. We have 200+ projects in our product's solution and we wouldn't want these internal projects to show up in the SBOM that they see. We're having to run an older version of CdxGen to avoid this issue. I suppose we could try to use filters, but we'd have hundreds of filters to specify, and we'd likely have to write scripts to generate the filter dynamically as we add projects fairly regularly. It would be a cool enhancement to have a switch to control whether project references show up. Thanks for the feedback and for your contributions Prabhu.