sbomqs
is your primary tool to assess the quality of sboms. The higher the score the more consumable your sboms are.
go install github.com/interlynk-io/sbomqs@latest
other installation options.
A high quailty SBOM should allow for managements of assets, license, vulnerabilities, Intellectual Property, configuration management and incidence response.
A quality SBOM is one that is accurate, complete, and up-to-date. There are many factors that go into constructing a high quality sbom
- Identify & list all components of your product along with their transitive dependencies.
- List all your components along with their versions & content checksums.
- Include accurate component licenses.
- Include accurate lookup identifiers e.g. purls or CPEs.
- Quality SBOM depends a lot upon which stage of the lifecycle it has been generated at, we believe closer to the build time is ideal.
- Signed sboms.
- Should layout information based on industry standard specs like CycloneDX, SPDX and SWID.
The main goals of the utility are
- Make it easy and fast to asses the quality of your sboms, generated or acquired.
- Support all well known sbom standards.
- Scoring output should be customizable.
- Scoring output should be consumable.
SBOM can be generated using both commercial and open-source tooling. As consumers of SBOM we wanted a fast & easy way to assess the quality of an SBOM. An sbom with a low score, needs to be re-evaluated or rejected.
sbomqs
makes getting a quick assesment, relatively painless. Just point.
sbomqs score --filepath samples/julia.spdx.tv --reportFormat basic
6.9 samples/julia.spdx.json
NTIA recommends the following standards for SBOM's
- SPDX
- CycloneDX
- SWID
sbomqs
supports SPDX and CycloneDX formats. Support for SWID is incoming.
In additon to supporting the sbom formats, we support various file formats
- SPDX: json, yaml, rdf and tag-value
- CycloneDX: json and xml
sbomqs
scoring output can be customized by category or by feature. We understand everyone needs for scoring would not match ours, we have added customizability around which categories or features should or should not be included for scoring.
We have categorized our current features into the following categories
- NTIA-minimum-elements: Includes features, which help you quickly understand if your sboms comply with NTIA minimum element guidelines.
- Structural: We check if the SBOM complies with the underlying specifications, be it SPDX or CycloneDX
- Semantic: We check meaning of sbom fields specific to their standard.
- Quality: Help determine the quality of the data present in the sbom.
- Sharing: Helps determine if the sbom can be shared.
- OWASP BOM Maturity Model: Work in progress
We allow running any single feature to be tested against an SBOM.
sbomqs generate features
, this generated a features.yaml file- Open the features.yaml file and select the categories or features that you would like enabled
- Save & close the file.
sbomqs score --filepath ~/data/chainguard-sbom/apko.spdx.json --configpath features.yaml
use the yaml file to apply the changes.
For the list of features currently supported, visit features.md.
sbomqs
provides its scoring output in basic and detailed forms.
Basic output is great for a quick check of the quality of our sboms. Once you get a good sense of how the tool works, this could also be your primary way of consuming data from this tool.
6.0 samples/blogifier-dotnet-SBOM.json
6.9 samples/julia.spdx.json
7.6 samples/sbom.spdx.yaml
Detailed output is presented in tabular and json formats currently
Tabular format: this format has been inspired by oss scorecard project.
SBOM Quality Score: 6.0 samples/blogifier-dotnet-SBOM.json
+-----------------------+--------------------------------+-----------+--------------------------------+
| CATEGORY | FEATURE | SCORE | DESC |
+-----------------------+--------------------------------+-----------+--------------------------------+
| NTIA-minimum-elements | Doc has creation timestamp | 10.0/10.0 | doc has creation timestamp |
| | | | 2022-11-04T16:51:54Z |
+ +--------------------------------+-----------+--------------------------------+
| | Components have supplier names | 0.0/10.0 | 0/1649 have supplier names |
+ +--------------------------------+-----------+--------------------------------+
| | Components have names | 10.0/10.0 | 1649/1649 have names |
+ +--------------------------------+-----------+--------------------------------+
| | Doc has relationships | 0.0/10.0 | doc has 0 relationships |
+ +--------------------------------+-----------+--------------------------------+
...
...
json format
{
"run_id": "fc86a94d-7490-4f20-a202-b04bb3cdfde9",
"timestamp": "2023-02-17T14:58:55Z",
"creation_info": {
"name": "sbomqs",
"version": "v0.0.6-3-g248d059",
"scoring_engine_version": "1"
},
"files": [
{
"file_name": "samples/blogifier-dotnet-SBOM.json",
"spec": "cyclonedx",
"spec_version": "1.4",
"file_format": "json",
"avg_score": 6,
"num_components" : 3,
"scores": [
{
"category": "Structural",
"feature": "Spec File Format",
"score": 10,
"max_score": 10,
"description": "provided sbom should be in supported file format for spec: json and version: json,xml"
}
]
}
]
}
https://github.com/interlynk-io/sbomqs/releases
brew tap interlynk-io/interlynk
brew install sbomqs
go install github.com/interlynk-io/sbomqs@latest
This approach invovles cloning the repo and building it.
- Clone the repo
git clone git@github.com:interlynk-io/sbomqs.git
cd
intosbomqs
folder- make build
- To test if the build was successful run the following command
./build/sbomqs version
We look forward to your contributions, below are a few guidelines on how to submit them
- Fork the repo
- Create your feature/bug branch (
git checkout -b feature/new-feature
) - Commit your changes (
git commit -am "awesome new feature"
) - Push your changes (
git push origin feature/new-feature
) - Create a new pull-request