Why manually create an SBOM?

A Software Bill of Materials (SBOM) is a detailed inventory of all components, libraries, and dependencies that comprise a software package. An automated process for creating your SBOMs is vital for efficiency, reliability, and scalability. But, sometimes, it can be important to be able to create an SBOM manually, offering a high level of control and granularity, allowing you to document every component and dependency in detail. Manual creation can also benefit smaller or legacy projects where automated tools might not be available or compatible. The SBOM concept may include applications, operating systems, and hardware/firmware.

An SBOM may also be used as a watchlist containing loosely coupled components that are candidates for future use.

Once you’ve manually created your SBOM, it is crucial to include it in your normal cyber security process, continuously and automatically checking for published vulnerabilities, exploits, and other risk indicators.

Here are some steps to manually create an SBOM:

Identifying Components and Gathering Metadata

For each component, gather the following metadata:

  1. Name: The name of the component.
  2. Vendor: The organization/person creating the component.
  3. Version: The specific version of the component.
  4. License: Licensing information for the component.
  5. Source: Where the component came from (e.g., a URL, vendor, etc.)
  6. Hash Value: Optional but highly recommended. A cryptographic hash like SHA-256 can help uniquely identify the component.

One difficulty in manually creating the SBOM is the naming of each parameter. If you want to include the SBOM in an automated cybersecurity process, the parameters must match the content of the security databases. For example, you want to include the Windows operating system as a component. Setting the Name to Windows will not help. You will probably be overloaded with false positives when checking for vulnerabilities. On my Windows computer, the About page says that I’m running Windows 10 Pro, version 22H2, and OS-version 19045.3324. In the SBOM, the Name should be set to windows_10_22h2 and Version to 10.0.19045.3324 for correct matching.

Documentation

Other data to possibly include:

  1. Parent-Child: Document which components depend on others, to create a tree-like structure.
  2. Explanations: Add any notes or explanations that might be necessary for understanding the SBOM.
  3. Timestamp: Include a timestamp indicating when the SBOM was last updated.
  4. Authors: List the people who contributed to the SBOM.

Formats

Yes, you can manually create your SBOM using tools like:

  1. Spreadsheets: Use a spreadsheet program like Microsoft Excel or Google Sheets to document all the information.
  2.  Text Documents: Use a plain text file or a markup language like Markdown or XML to record details.
  3.  Database: For larger projects, you might consider using a database to store this information.

…but the subsequent automated cybersecurity process probably requires the content to be exported in a standard format like CycloneDX or SPDX.

Validation and Review

  1. Legal Review: Have a legal team review the SBOM, particularly the licensing section, to ensure you comply with all legal requirements.
  2.  Security Review: Have a security expert review the security information generated from the SBOM content.

Once you’ve manually created your SBOM, keeping it up-to-date as your software evolves is crucial. An outdated SBOM can be more harmful than not having one, as it could provide a false sense of security.

SBOM Central

SBOM Central will soon release tools to manually create locally stored Components, Artifacts, and SBOMs. The tools will include dictionary support for the correct naming of parameters. The created SBOMs will subsequently be included in the automated cybersecurity process.