SBOM∞
Tree shaking for the minimal viable software bill of materials (SBOM).
Third party dependencies are documented in the folder third-party.
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.