# How to create an SBOM

Tools and commands for creating an SBOM from source code or a container

> An SBOM is created by a tool that reads source code, build output or a container image. This page lists open-source tools, example commands and how to review the result.

Updated: 5 October 2026  
URL: https://sbom.se/en/guides/create-an-sbom

An SBOM is created by a tool that goes through a project and lists the components it finds. Several open-source tools do this from the command line, and they run both on a developer's machine and in a build pipeline.

## Open-source tools

| Tool                                                          | From      | Reads                                           |
| ------------------------------------------------------------- | --------- | ----------------------------------------------- |
| [Syft](https://github.com/anchore/syft)                       | Anchore   | Directories, container images, archives         |
| [Trivy](https://github.com/aquasecurity/trivy)                | Aqua      | Directories, container images, repositories     |
| [cdxgen](https://github.com/CycloneDX/cdxgen)                 | CycloneDX | Source code in many languages and build systems |
| [Observer CLI](https://github.com/sbom-observer/observer-cli) | Bytesafe  | Directories and container images                |

## Examples

Create an SBOM in CycloneDX format from the current directory:

```bash
syft dir:. -o cyclonedx-json=sbom.cdx.json
```

```bash
trivy fs --format cyclonedx --output sbom.cdx.json .
```

```bash
observer fs -o sbom.cdx.json .
```

Create an SBOM from a container image:

```bash
syft nginx:latest -o cyclonedx-json=sbom.cdx.json
```

## Where in the process

Create the SBOM in the build, not afterwards. An SBOM created when the dependencies are installed and locked contains the versions that are actually shipped, including transitive dependencies. Add the command as a step in the pipeline and store the file with the release.

[Different types of SBOMs](https://sbom.se/en/sbom/sbom-types) describes the difference between an SBOM from source, from the build and from a finished artefact. [SBOM and DevOps](https://sbom.se/en/guides/devops) describes how to build it into a pipeline.

## Review the result

Different tools give different results for the same project. Check that the SBOM contains what you expect:

* Are all ecosystems in the project included, for example both npm and Python?
* Do the components have versions and unique identifiers (purl)?
* Are the transitive dependencies included, and the relationships between components?

[Why is SBOM quality important?](https://sbom.se/en/guides/sbom-quality) goes through common gaps.

## Analyse an SBOM

The tools above can often also compare an SBOM against known vulnerabilities. [Grype](https://github.com/anchore/grype) and [osv-scanner](https://github.com/google/osv-scanner) are two tools made for exactly that.

For a quick overview without installing anything, there is the web tool [SBOM Analyzer](https://bytesafe.dev/observer/sbom-analyzer) from Bytesafe. It is free and shows the number of components, known vulnerabilities, licences and whether the SBOM meets the [SBOM Minimum Elements](https://sbom.se/en/sbom/minimum-elements).