Skip to content

sophiewigmore/bom

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

20 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Investigating BoM tools and formats

Contains the BoM fields of interest and how we believe we can represent them in CycloneDX and SPDX.

Tools Investigations

Pack

Command run for CycloneDX XML (from source): syft packages <path-to-source> -o cyclonedx

Command run for CycloneDX XML (from image): syft packages <image-name> -o cyclonedx

Includes examples in both Syft enriched JSON format (not CycloneDX) and CycloneDX (XML)


Tern

Command run for true SPDX JSON format: ./docker_run.sh ternd "report -f spdxjson -i built-app-image:latest"

Includes examples in both Tern enriched JSON format (not SPDX) and true SPDX (JSON)

Conclusions

Time Averages for Scanning

  • Syft on a pre-built image: 4.8062s
  • Syft on application source code: 0.7624s
  • Tern on a pre-built image: 136.4412s

Tern

  • We generated both a Tern-specific SPDX JSON file, as well as a "true" SPDX JSON file.
  • It appears that while neither have all of the metadata we are looking for, the "true" SPDX format has the least.
    • It does not have CPEs, SHAs, and layer paths

Syft

  • The JSON output of Syft is NOT CycloneDX format, but rather it's a superset of all metadata that can be retrieved.

  • The real CycloneDX format from Syft (XML) is missing some information.

    • It does not have CPEs, SHAs, and layer paths
  • This issue on Syft looks like a request for what we might want

  • The enriched formats have all of the information we need, but they don't seem to align with CycloneDX or SPDX as well as we once thought

Syft enriched JSON seems to fit our use case

  • Gets full information on all OS level and indirectly installed packages

    • CPEs, licenses, urls, shas, layer location, name, version
    • These are all fields we feel strongly about being first-class citizens
    • The SPDX output from Tern did not surface this metadata fully/or as clearly
  • For all of our language modules (packages installed by go-mod and npm) can easily be retrieved with fully-fledged metadata

  • It might be nice to integrate with this tooling rather than build out our own custom logic

  • No information about the the actual dependencies we directly install (node, go, etc), but this is information that we can easily provide

  • Does a better job of conveying the information we think is important

  • The tooling ecosystem feels better fleshed out for the use cases we have (language module metadata collection)

Format Concerns

The fact that these scanning tools all seem to have enriched BOM outputs that are outside of either SPDX or CycloneDX and then there translations to these formats are sparse is with interesting and cause for pause.

  • Why do these tools not just try and do everything in the existing BOM formats that they support?
  • Why is the translation between their format and the "official" format so sparse?
  • Is it sparse because they don't care about those formats or because they cannot get more specfic?

To Do

  • Conversion tooling
  • Offline environments?
  • Check CycloneDX Scanning Tools

About

Investigating BoM tools

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published