Skip to main content
An SBOM (software bill of materials) lists the components your software contains, with their versions and licences. You give it to a customer, an auditor, or a regulator when they ask what’s in your product. This page explains how to generate an SBOM in Earnie, which formats and extras to choose, and how to produce two related documents, the export-control evidence report and the notice file. Before you start:
  • The project needs at least one completed scan. See Your first scan.
  • Triage the findings first. An SBOM records your current decisions, so a project you haven’t triaged produces an SBOM with low review coverage. See Triaging findings.
  • You need the Operator or Admin role to generate a snapshot. Viewers can download existing snapshots but can’t create them.

​
What an SBOM is, in Earnie

SBOMs In Earnie, an SBOM is a snapshot. It records the project’s inventory and your triage decisions at one point in time, and Earnie never rewrites it. To find snapshots, select SBOMs in a project’s sidebar to open the SBOM snapshots page. Everything in a project’s Dashboard Download menu comes from the snapshot attached to the scan behind the Dashboard’s figures. The SBOM snapshots page is where those files are stored.
Snapshots are immutable. Earnie never edits a snapshot. If the inventory changes, you generate a new one. A document you sent to a customer last quarter still says exactly what it said when you sent it.

​
Generating a snapshot

You can start from either of two places:
  • SBOMs in the sidebar → Generate snapshot
  • Review in the sidebar → Export SBOM, which generates a snapshot of the scan you’re reviewing
Both open the same Generate snapshot panel.
  1. Choose a scope. A scope preset picks which sections the snapshot holds. The panel offers only the presets your organisation’s scanning covers: SPDX is available only for the SBOM scope. Earnie names downloaded files after the scope, for example …-cbom, or …-sbom-aibom for a custom mix.
  2. Choose one or more documents. You must choose at least one, and you can choose both: You can render the other format later from the same snapshot.
  3. Choose what to embed in CycloneDX (optional). These options are available only when you select CycloneDX. SPDX doesn’t support them. Both are off by default.
    • Known vulnerabilities embeds known vulnerability data. Each advisory names only the affected versions in the snapshot. When several sources report the same CVE, the document keeps the highest severity and scores, and names every source that reported it.
    • Cryptographic assets adds detected algorithms as CycloneDX cryptographic assets, which makes the document a CBOM (cryptography bill of materials). It also produces the export-control evidence report. This option appears only when cryptography scanning is enabled for your organisation.
    If your organisation has the Enrichment option and you choose both, each library that a cryptographic asset comes from and that has a known vulnerability appears once as a component carrying that vulnerability. This holds even when OSS matching also found the library.
  4. Select Generate snapshot.
Some scans finished before Earnie began keeping SBOM evidence. They have nothing to freeze, and Earnie doesn’t rebuild them from today’s catalogue. If you choose one, Earnie tells you to run a new scan, and the API refuses with 422 scan_evidence_unavailable. Earnie stores nothing. Generate SBOMs on All projects reports such a project the same way and generates SBOMs for the other projects.

​
Licences and tool information in the document

  • Concluded and detected licences. A component you confirmed carries the licence you concluded and, next to it, the licence the scan detected. CycloneDX records them as separate licence entries marked concluded and declared. SPDX records them as licenseConcluded and licenseDeclared. The notice file names only the concluded licence.
  • Generating tool. Every CycloneDX and SPDX document names Earnie and the build that generated it as its tool, for example earnie and its version. A document filed with an auditor says which release produced it. If you render a format later from the same snapshot, that document names the build that rendered it, which can be a newer release.

​
What the snapshot records

Earnie stamps each snapshot with:
  • Reviewed, the review coverage when the snapshot was generated
  • Components, the number of components
  • Generated by, the person who generated it

​
Cryptographic asset details

When Cryptographic assets is on, the CycloneDX document has extra detail for each asset:
  • Export-control metadata. Each cryptographic-asset component has scanoss:exportControl:* properties. They record the rolled-up signal state, the asset’s purpose, and the control regime and regime version Earnie evaluated the signals against.
  • Sizes. Key, nonce, salt, and IV assets have their size under relatedCryptoMaterialProperties.size, when Earnie resolved it.
  • Curves. Elliptic-curve algorithms have their curve under algorithmProperties, when Earnie resolved it.

​
When a snapshot is out of date

If triage has changed since a snapshot was generated, its row shows a Stale badge. Hover it to see “Triage has changed since this snapshot was generated.” Generate a new snapshot before you send it out.

​
How decisions carry into a snapshot

A new SBOM or CBOM uses each finding’s current decision, never a withdrawn or superseded one.
  • Reopening a finding restores its unreviewed evidence for the next snapshot.
  • Excluding or replacing one occurrence of a component doesn’t remove another occurrence of the same component that’s still present.
  • If the remaining occurrences disagree on known component metadata, generation stops with a resolution_conflict error. Reconcile those findings’ decisions in Review, then generate again. Existing snapshots and downloads don’t change.

​
CRA SBOM annex

The CRA SBOM annex is a CycloneDX 1.7 export for the EU Cyber Resilience Act (CRA). It includes the detected cryptographic assets as components. It goes with the product SBOM. It is not a CRA conformity assessment.
Not the same CRA reference as a policy. This annex isn’t tied to a specific CRA clause. The CRA — Annex I(2)(e) and CRA — Annex I Part II(1) regulatory template sets are policies, not an SBOM export. All three carry a “CRA” label, but they’re unrelated features.
Neither the Generate snapshot panel nor the Earnie CLI lets you choose the CRA SBOM annex. When a snapshot has one, its row shows a CRA badge.
Earnie doesn’t verify FIPS 140-3 module validation.

​
The snapshot list

Each row on the SBOM snapshots page shows when the snapshot was generated, the scan it came from, its documents, and the stamp described above. The Documents column shows a badge for each document the snapshot has: From each row’s menu you can download a document, render a format the snapshot doesn’t have yet, copy the snapshot ID, regenerate from the same scan, or delete the snapshot.

​
The export-control evidence report

Some countries control the export of software that uses cryptography. The export-control evidence report collects the evidence you need to classify your own product under those rules. When a snapshot was generated with Cryptographic assets on, its row menu offers Download Export-control evidence report. The report is a self-contained HTML file, frozen with that snapshot. It records:
  • the detected cryptographic assets
  • their export-control signals
  • the detection surface it cites, meaning what was scanned
  • the identity of the ruleset Earnie used
The report is evidence for your own self-classification. It isn’t legal advice or a determination, and it doesn’t state or imply an ECCN (export classification). The report’s header names the export dataset and the date it was reviewed. It then tells you to verify the evidence against the current 15 CFR 740.17 and 15 CFR Part 774 Supplement No. 1, Category 5 Part 2, before you rely on it. Its purpose legend separates confidentiality from Technical Note 1 exclusions, and it describes the Technical Note 2.c test in plain language.
The report states that all detected cryptography maps to published standards only when its frozen evidence shows that for the named detection surface. Otherwise it marks the statement as not established. Signature-based detection can’t prove that no non-standard cryptography is present. To cover a later scan, generate a new snapshot with Cryptographic assets on.
When cryptography is enabled for your organisation, the Cryptography card on the Dashboard opens the Dashboard’s Cryptography tab. To see available reports or generate the next snapshot, open SBOMs in the sidebar.

​
Notice files (attribution documents)

An SBOM and a notice file are different documents, and one can’t replace the other:
  • An SBOM lists what’s present and names each component’s licence.
  • A notice file, also called an attribution document, contains the text you’re obliged to distribute. An OSPO (Open Source Program Office) ships it with a release.
For every component, the notice file includes:
  • its licences
  • the full text of its LICENSE and NOTICE files
  • its copyright holders
  • its obligations

​
Rendering a notice file

You don’t create a notice file in the Generate snapshot panel. Earnie renders it from a snapshot that already exists:
  1. On the SBOM snapshots page, open the snapshot’s row menu.
  2. Choose Render Notice file.
Earnie fetches the licence data for every component in that snapshot’s inventory and writes it to a plain-text file. The row then shows a NOTICE badge. If Earnie couldn’t resolve a component’s licence data, it doesn’t drop the component. It lists it at the end of the file under Unresolved components, so you can see what the file doesn’t cover.
Frozen on first render. The first time you render a snapshot’s notice file, Earnie fixes its content. Later downloads return exactly the same file, even if the upstream licence text changes. Hover the NOTICE badge to see when Earnie fetched the licence text, and compare that date with what you’re about to ship.

​
Notice files elsewhere in Earnie

The same document is available in two other places:
  • On a project’s Dashboard, the Download menu offers it as Notice file. Earnie renders it from a snapshot, so a snapshot has to exist first. If there’s none, the Dashboard says “No SBOM snapshot exists for the current scan” instead of offering the notice file.
  • On All projects, the Generate notice files action doesn’t need an existing snapshot. For a project with no current snapshot, it generates one and then renders the notice file from it, in one step.

​
What’s next

When someone asks, months from now, why a component was accepted, look in the audit log.