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.