Generating an SBOM for C# / .NET (NuGet)

The step below writes a CycloneDX JSON file in your own pipeline. The CRA Desk scan reads that file and turns it into a readiness report - it never generates one for you.

Run in CI:

dotnet tool install --global CycloneDX
dotnet restore
dotnet CycloneDX . -o . --json --filename sbom.json

Produces:

sbom.json

Format:

CycloneDX JSON

The whole CI job

- uses: actions/checkout@v4
- run: dotnet tool install --global CycloneDX
- run: dotnet restore
- run: dotnet CycloneDX . -o . --json --filename sbom.json
- uses: mmalinowski/cradesk-action@v1
  with:
    sbom-path: sbom.json

generate-sbom:
  script:
    - dotnet tool install --global CycloneDX
    - dotnet restore
    - dotnet CycloneDX . -o . --json --filename sbom.json

include:
  - component: gitlab.com/cradesk/scan/readiness@1
    inputs:
      sbom_path: sbom.json

Only the first step changes with your stack - the CRA Desk step after it is identical everywhere.

What goes wrong here

The tool resolves what restore put on disk, so dotnet restore has to run first; pointing it at a solution rather than a single project is what gets every shipped assembly in.

What CRA Desk does with the result

Components from this build carry pkg:nuget package URLs, which the watch matches against OSV's NuGet advisories when the SBOM arrives and again as new advisories land. Matching runs on every plan; e-mail alerts and the full match list are what a paid plan adds.

A generator that runs is not the same as coverage. Components with no purl, no version, or from an ecosystem outside the nine we watch are counted as gaps in every report rather than reported as clean.