2 - Update rails backend to merge and present CycloneDX artifacts

Proposal

This is step 2 of the 4-step migration plan outlined in Create plan for ISBOM rollout.

The purpose of this issue is to update the Rails backend to merge and present the Cyclone artifacts introduced by Update gemnasium to output CycloneDX documents.

The following diagram describes what the process flow should be once this issue has been completed:

flowchart TB
    subgraph "Dependency Scanning Analyzer 1"
      1[Analyze project]-- generate -->2[/"Report \n(deps/vulns)"/]
      1[Analyze project]-- generate -->3[/"CycloneDX Report"/]
    end
    subgraph "Rails app"
        2 -- upload --> 4[Merge]
        4 --> 5[/Reports/]
        3 -- upload --> 13[Merge]
        13 --> 14[/CycloneDX Reports/]
        5 --> 6[Parse]
        6 --> 7[/Vulnerabilities/]
        6 --> 8[/Dependencies/]
        7 --> 9[Display]
        8 --> 9[Display]
        14 --> 15[Export]
    end

    subgraph "Dependency Scanning Analyzer 2"
        10[Analyze project]-- generate -->11[/"Report \n(deps/vulns)"/]
        10[Analyze project]-- generate -->12[/"CycloneDX Report"/]
    end
    11 -- upload --> 4
    12 -- upload --> 13

We need to merge the CycloneDX reports that the Dependency Scanning analyzers have produced, and allow a single file to be exported/downloaded by users.

Since we'll be producing a single file, we have the following options:

  1. Use a tool such as CycloneDX CLI to merge the individual CycloneDX reports into a single file.

    • Pros
      • Easy to implement
      • Produces a standard CycloneDX document
    • Cons
      • We'll lose the ability to track files in multiple projects. For example, each individual CycloneDX report contains metadata that shows the path to the lockfile that was used to generated the report. If we merge multiple reports, the metadata will also be merged, and it will no longer be possible to figure out which dependencies were generated by a particular lockfile, for example.
      • No value to users

  2. Introduce an ISBOM file format with a manifest/index file.

    • Pros
      • Can maintain a rich set of metadata to describe all the files in multiple projects
      • Provides value to the user since it's easier for them to consume a single file
    • Cons
      • Much more difficult to implement
      • Manifest file needs to be documented

As part of this issue, we need to determine which of the following approaches we need to take.

/cc @gonzoyumo @NicoleSchwartz @fcatteau

Edited by Adam Cohen