Investigate: SBOM creation for all app types

[sophiewigmore]

Context

To implement Paketo RFC0038, we are considering how to build out an SBOM for various types of apps.

Issue

The most straightforward path appears to be generating an SBOM for the packages that get installed via dotnet publish (dotnet publish buildpack) and store it in a CNB lifecycle-accessible file as outlined in the RFC.

However, it may be advantageous for us to consider how we might approach generating SBOMs for apps that don't use 'dotnet publish' such as self-contained apps and framework-dependent executables. In this set up, we may end up generating the SBOM based off of a *.deps.json file. There is plenty of discourse on the options we have in the related Syft issue (linked below)

This issue is to investigate the viability of generating an SBOM from various types of .NET Core apps (framework-dependent executables/deployments, self-contained apps, and source apps).

The outcome should be documented here and used to inform our approach to contributing to the Syft issue, if we choose to go that route.

Associated Issue

Currently, we use the Syft library in packit in order to generate SBOMs for other buildpack language families, such as Node.js. The outcome of this issue will inform our strategy on the mechanism to actually generate an SBOM for a .NET Core app.

anchore/syft#373 exists, which may be the most straightforward and logical place to approach solving this issue, so we can then consume the release and generate the SBOM in a similar fashion to our other buildpacks. A reasonable starting place could be to consider how Syft could gather package info from the *.deps.json file after the publish step, or the obj/project.assets.json file.

[ForestEckhardt]

This issue has spawned a tracking issue in the dotnet-execute buildpack to add SBOM scanning there. You can see that issue here paketo-buildpacks/dotnet-execute#317.