Skip to content

SBOM

Tree shaking for the minimal viable software bill of materials (SBOM).

License: MIT

Third party dependencies are documented in the folder third-party.

version downloads wheel supported-versions supported-implementations

Bug Tracker

Feature requests and bug reports are best entered in the todos of sbom.

Primary Source repository

The main source of sbom is on a mountain in central Switzerland. We use distributed version control (git). There is no central hub. Every clone can become a new source for the benefit of all. The preferred public clones of sbom are:

  • on codeberg - a democratic community-driven, non-profit software development platform operated by Codeberg e.V.
  • at sourcehut - a collection of tools useful for software development.

Terminology

  • baseline - mandatory elements
  • consume - an SBOM
  • crypto - hashing, signing, and signature validation
  • extension - sets of elements mandatory in addition to baseline
  • fuzz - generate surrogate and poisoned SBOMs
  • merge - an SBOM with other SBOMs or additional information
  • mock - provide optimal testability
  • policy - to apply
  • produce - an SBOM
  • report - anything from produce, transform, and consume
  • rule - executing policies
  • transform - one SBOM into another SBOM

Safety, Security, and Data Protection Considerations

The current implementation SHALL only digest trustworthy data.

Schema validation of JSON and XML formats requires specific measures to
minimize vulnerabilities.

For example: The python xml parser implementation (etree) in
use is presumably vulnerable against some attacks like billion laughs and quadratic blowup.

Plans are to move towards a safer implementation like defusedxml or any other hardened implementation.

The situation is similar for the JSON formats.

In summary and repeating the obvious:

The current implementation SHALL only digest trustworthy data.