The SBOM from the binary
you ship.

Every library inside a stripped binary or firmware image, with its version and known CVEs. CycloneDX and SPDX for the CRA. No source, no lockfile, nothing executed.

Drop a binary or an imageSee a real image
COMPONENTS · router-fw-2.1.390.bin · 812 MEMBERS · UNPACKED10 COMPONENTS · 58 CVES · 1 ON THE KEV LIST
Signature1.84M library signatures name components inside stripped binaries, most with a CVE-precise version.
Package databaseapk, dpkg, rpm and opkg databases inside a firmware or container image, read beside the signatures.
ManifestLockfiles from npm, PyPI, Go, Java, PHP, Ruby and Rust land in the same table.

The lockfile is a plan.
The binary is the product.

A shipped image carries libraries no manifest lists. Some are statically linked, some vendored, some copied in by a supplier years ago. Manifest scanners read the package database and stop.

openbinary names each component from the compiled bytes, with its version and known CVEs. Package databases inside the image are read as well. What you ship is what you file.

Named from the bytes, not the lockfile.

SBOM from the compiled bytes
Stripped binaries namedLibraries compiled or statically linked into a stripped binary are named with no symbols and no package database.
Package databases inside the imageapk, dpkg, rpm and opkg databases inside a firmware or container image are read beside the signatures. One table covers what was installed and what was compiled in.
Source manifests in the same tableLockfiles from npm, PyPI, Go, Java, PHP, Ruby and Rust land in the same table with the same exports.
CycloneDX and SPDXPer binary and per package, from the page or one API call. JSON and SARIF beside them.
Known vulnerabilities
Severity, KEV and EPSS on every matchEach CVE carries its severity, whether CISA lists it as exploited, and its EPSS score. All three are labelled enrichment, not facts about the binary.
Per binary, per packageOne binary gets its table. A whole image scans as one unit, worst CVE and KEV flag per member, the full list behind each row.
Release against releaseTwo releases side by side. Components added, removed or bumped, CVEs cleared or introduced.
A CVE match is a version matchIt is reported as one, with no claim that the vulnerable code is reached. Unknown bugs found in the same binary do carry whether they are reachable from main.
Across the fleet and the corpus
Fleet CVE rollupKnown vulnerabilities rolled up across every binary in the workspace, worst first.
What-if before a CVE landsWhich CVEs a version bump clears, how many of them are on the KEV list, vulnerable binaries before and after.
Variant huntingOne known bug, every other firmware in the corpus that carries the same code.
Peer benchmarkingYour components, hardening and secrets ranked against every other vendor's shipped firmware.

How a component gets its name.

Every row says which evidence named it. A row without a version says that too.

Signature matchThe compiled functions of a stripped binary are matched against the signature library. The version is read from the signature where it carries one.openssl 1.0.1f · 1,207 functions matched
Package databaseapk, dpkg, rpm and opkg records inside a firmware or container image. Shown beside the signature when both name one file.opkg · libopenssl 1.0.1f-1
ManifestLockfiles from npm, PyPI, Go, Java, PHP, Ruby and Rust. What the source declares, not what the binary carries.package-lock.json · lodash 4.17.21
What the table does not say
No versionThe component is named and listed without one. No CVE range is matched against a guess.
No reachabilityA CVE match is a version match. It says nothing about whether the vulnerable code is reached.

Built for. The people who file the SBOM.

Device makersFile the CRA SBOM from the image you ship, with the evidence behind every row.
Security teamsAnswer an advisory with the components and versions this build runs, in seconds.
EnterpriseSay which of thousands of binaries carry a new CVE, and which a version bump clears.
1.84Mlibrary signatures
69.6%with a CVE-precise version
11manifest ecosystems read
11 Dec 2027CRA applies in full

Binary SBOM, asked plainly.

Short answers. Docs has the long ones.

Read the docs
  1. 01

    How do I upload a binary or an image?

    Drop a file, call the API, or install the GitHub App and every release asset is analysed when it is published. Each binary takes seconds.

  2. 02

    How is this different from Trivy, Grype or Syft?

    They read the package database inside an image and stop there. openbinary reads that too, then names what was compiled or statically linked into the binaries themselves, where no package database lists it.

  3. 03

    Which SBOM format does the CRA want?

    The CRA asks for a machine-readable SBOM on every connected product. CycloneDX and SPDX export per binary and per package, from the page or one API call.

  4. 04

    Does it work on firmware and container images?

    Yes. The image is unpacked and every member read, and the components roll up into one table per image with the worst CVE per member.

  5. 05

    Can an agent pull the SBOM?

    Yes. Components, CVEs and the exports are agent tools. One command installs all 69 into the agent you already use.

  6. 06

    Where does it run, and who sees my binaries?

    Cloud, on-prem or air-gapped. Private workspaces are visible to their members only, and uploaded binaries are never redistributed. An air-gapped install needs the operator to refresh the OSV, EPSS and KEV feeds.

Drop a binary.

Mach-O, ELF, PE, DEX, WASM, firmware, container and archive images. Up to 2 GB. The report is public unless you sign in.

Choose a fileSet up an agent