Skip to content

Latest commit

 

History

History
376 lines (214 loc) · 16.1 KB

Features.md

File metadata and controls

376 lines (214 loc) · 16.1 KB
Raw

SBOM Quality Checks

This page describes each SBOM Quality check in detail, including scoring criteria, remediation steps, and an explanation of the potential impact associated with a low score. The checks are continually changing, and we welcome community feedback.

If you have ideas for additions or new detection techniques, please contribute!

Taxonomy

  • A Quality Check is a test that can be performed on SBOM to return a binary result (e.g., A check for specification)
  • A Quality Check Category is a logical grouping of Quality Checks (e.g., "NTIA-Minimum-Elements" Checks)
  • A Quality Check Set is a collection of Quality Checks (e.g., "Default Check Set", "IoT Quality Set")

Scoring Methodology

  • Each Quality Check has an equal weight and a score range of 0.0 - 10.0. (Coming soon: Customization of weight per Quality Check)
  • A Quality Check applied over a list of items (e.g., licenses) averages its score from the Check applied to each element.
  • Quality Check Set Score is an average of scores over all Quality Checks in that Set.

Check Set Versioning

Any Check Set, including the default Check Set, may change over time as new Checks are added, existing ones are removed and meaning of an existing one changes. Such a breaking change is marked by incrementing scoring_engine_version in the output of sbomqs.

Therefore comparing Quality Scores across scoring_engine_version is not recommended.

Quality Check Sets - Interlynk (Default)

Category: Structural

Specification

This check determines whether the SBOM is in one of the specifications (CycloneDX, SPDX, SWID) recommended by the CISA reference document .

CISA recommends limiting the document to three commonly used formats to facilitate widespread adoption.

Remediation

  • Re-create the document in CycloneDX, SPDX, or SWID.

Specification Version

This check determines whether the given SBOM is in the specification version that can support fields necessary for typical SBOM operations. The current check tests for:

  • CycloneDX Versions: 1.0, 1.1, 1.2, 1.3, 1.4
  • SPDX Versions: 2.1, 2.2, 2.3

While the earlier versions of specifications may exist, a document in an earlier version will not be able to carry all of the required fields.

Remediation

  • Re-create the document in one of the versions listed above.

Specification File Format

This check determines whether the given SBOM can be easily consumed by testing for the most common file formats associated with the specification.

  • CycloneDX: XML, JSON
  • SPDX: JSON, YAML, RDF, tag/value

Building and sharing SBOM in the most commonly used file format enables the use of SBOM in various conditions.

Remediation steps

  • Re-create the document in one of the file formats listed above.

Specification Syntax

This check determines whether the given SBOM meets all the requirements of the underlying specification and file format to be parsed.

A syntactic error in the SBOM will prevent it from being usable.

Remediation

  • Check the SBOM generator tool's known issues and get the most recent version of the tool.
  • Check options/setup of the environment variables required to use the tool.
  • Build SBOM with a different tool.

Category: NTIA-Minimum-Elements

Component Name

This check determines whether each component in the SBOM includes a name.

Components must have a name to be used meaningfully to assess compliance or security risk.

Remediation Identify the component with a missing name and check its product page to get its name.

Supplier Name

This check determines whether each component in the SBOM includes a supplier name. Supplier name is not a well defined term especially in the context of Open Source projects and we will update the recommendation here once a consensus emerges.

Remediation

Identify the component with a missing supplier name and check its product page to get its supplier name.

Unique Identifier

This check determines whether each component in the SBOM includes a unique identifier.

Unique component identifiers are essential to ensure the document can uniquely describe properties associated with the component.

Remediation

Identify the component with a missing/duplicate identifier.

Component Version

This check determines whether each component in the SBOM includes a version.

Components without a version can not be checked for vulnerabilities.

Remediation Identify the component with the missing version and populate the version field below.

Author Name

This check determines whether the document includes the name of the author.

The person, organization, or the tool that created the SBOM must be specified as the Author.

Remediation Check and populate the following fields with the name of the person, organization, or tool creating the SBOM.

Timestamp

This check determines if the document includes the timestamp of its creation.

The timestamp can be used to determine when the SBOM was created relative to the software itself.

Remediation steps

  • Check and populate the following fields with the timestamp of the SBOM document.
  • CycloneDX field: metadata:timestamp
  • SPDX field: Created

Relationship among Components

This check determines if the document describes the relationship among included components.

The dependency relationship can be critical in determining the order of inclusion and updates.

Remediation

  • Check and populate the following fields with the relationship of components in the SBOM.
  • CycloneDX field: dependencies
  • SPDX field: Relationship

Category: Semantic

Component Checksum

This check determines whether each component in the SBOM includes a valid checksum.

A valid checksum can be used to independently identify the contents of the package among variations of the package.

Remediation

Component License

This check determines whether each component in the SBOM includes a valid license.

A declared valid SPDX license is the key to evaluating any compliance risks.

Remediation steps

Check and populate the following fields with the relationship of components in the SBOM.

Required Fields

This check determines whether several fields required by the underlying specification are present in the document.

With the required fields, the SBOM processing becomes consistent by different tools.

Remediation

Check and populate the following required fields:

Category: Quality

Vulnerability Lookup Identifier

This check determines whether at least one vulnerability lookup identifier (CPE/PURL) is present for each component.

A vulnerability lookup identifier is critical in mapping SBOM components to known vulnerability databases (e.g., NVD).

Remediation

Multiple Vulnerability Lookup Identifier

This check determines whether multiple vulnerability lookup identifiers are present for each component.

Including more than one vulnerability lookup identifier can enable vulnerability lookup from multiple sources, reducing the risk of missing any vulnerability.

Remediation

Check and populate the following fields:

Valid SPDX License

This check determines whether all included licenses are valid SPDX licenses or license expressions.

Any license expression not found on the SPDX list is a commercial license and must be evaluated independently for compliance risks.

Remediation

Deprecated License

This check determines whether any of the included licenses have been declared deprecated.

A deprecated license declaration can be considered a compliance risk.

Remediation

Restricted License

This check determines whether any included licenses have been declared restricted for use.

A restricted license declaration can be considered a compliance risk.

Remediation

Primary Purpose

This check determines whether the SBOM component includes the Primary Purpose field.

The primary purpose (or type) indicates the use of the component inside the application.

Remediation steps

Check the following fields to confirm none of the licenses belong to the restricted license list:

Primary Component Present

An sbom is expected to describe a primary component. This check determines if the sbom has a primary component or not.

Remediation steps

  • CycloneDX: ensure the metadata section has the primary component defined
  • SPDX: Should have a DESCRIBES relationship which points to a package, or have a documentDescribes field present.

Category: Sharing

Unencumbered License

This check determines whether the SBOM can be shared easily because it includes an unencumbered license: CC0, Unlicense, 0BSD

Check the following fields to see if the license includes one of the above licenses: