Skip to main content

​
What an SBOM Is, in Earnie

SBOMs A software bill of materials is what you hand to a customer, an auditor, or a regulator. In Earnie it’s a snapshot: fixed, and never rewritten.

​
Generating a Snapshot

Generate one from the Review Workspace with Export SBOM, or from the SBOM page with + Generate Snapshot. Everything on a project’s Dashboard Download menu comes from the snapshot attached to the exact scan behind the Dashboard posture, so this ledger is where the evidence actually lives. You choose:
  • Format — CycloneDX 1.7 (broad tool support) and/or SPDX 2.3 Lite (licence-focused). You can render the other format later from the same snapshot.
  • Include Vulnerabilities — embeds known vulnerability data (CycloneDX only).
  • Include Cryptographic Assets — when cryptography scanning is enabled for the organisation, adds detected algorithms as CycloneDX cryptographic assets (CBOM) and enables the Export-control evidence report. Each cryptographic-asset component also carries scanoss:exportControl:* export-control metadata: the rolled-up signal state, the asset’s purpose, and the control regime and regime version the signals were evaluated against. Off by default, and disabled for SPDX.

​
CRA SBOM Annex

The CRA SBOM annex export variant uses CycloneDX 1.7 with detected cryptographic assets and component-to-asset relationships in dependencies[].provides. It accompanies the product SBOM; it is not a CRA conformity assessment.
Earnie doesn’t verify FIPS 140-3 module validation.
Earnie stamps the snapshot with the review coverage at the moment of generation, the component count, and who generated it.
If triage has moved on since, the newest snapshot is flagged Triage changed since snapshot, your cue to export again before sending it out.
Immutable on purpose. A snapshot is never edited. If the inventory changes, you generate a new one. That way a document you sent to a customer last quarter still says exactly what it said when you sent it.

​
The Export-Control Evidence Report

When an entitled organisation generates a snapshot with Include Cryptographic Assets, its row also includes an Export-control evidence report download. This self-contained HTML report is frozen with that snapshot: it records the detected assets, export-control signals, cited detection surface, and ruleset identity. It’s evidence for the exporter’s own self-classification, not legal advice or a determination; no ECCN is stated or implied. Its header names the export dataset vintage and review date, then tells you to verify the evidence against the current 15 CFR 740.17 and Category 5 Part 2 before relying on it. Its purpose legend separates confidentiality from Technical Note 1 exclusions, and it names 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 establishes that assertion over the named detection surface; otherwise it marks the assertion as not established. Signature-based detection can’t establish the absence of non-standard cryptography. Generate a new crypto-inclusive snapshot to capture a later scan.
When cryptography is enabled for your organisation, the Cryptography posture card opens the Dashboard’s Cryptography tab. Open SBOMs in the sidebar to inspect eligible reports or generate the next snapshot.

​
Attribution Documents

An SBOM lists what’s present. An Attribution Document is a different deliverable, the compliance package an OSPO ships alongside a release: for every component it carries its licences, the full text of its LICENSE and NOTICE files, its copyright holders, and its obligations. An SBOM names a licence; an Attribution Document carries the text you’re obliged to distribute. The two are never interchangeable. You don’t produce one from the generate dialog. Once a snapshot exists, open its row menu and choose Render Attribution Document. Earnie fetches the licence data for every component in that snapshot’s inventory and writes it out as a plain-text file.
The same document, called a notice file elsewhere. On the Dashboard’s Download menu this artifact is offered as Notice file, and the cross-project verb on All Projects is Generate notice files, it’s the same rendered document, named after the NOTICE.txt you ship. Because it’s rendered from a snapshot, a snapshot has to exist first: on a single project’s Dashboard, with none, Earnie raises “No SBOM snapshot exists for the current scan” rather than offering a notice file it can’t produce. The cross-project verb is more forgiving: for a project with no current snapshot, it generates one and then renders the notice from it as one step.
Frozen on first render. The first time you render a snapshot’s Attribution Document, its content is fixed for good, re-downloading it later always returns those exact bytes, even if upstream licence text changes afterwards. The Documents column shows an ATTR badge; hover it to see when that licence text was fetched, so you can judge how current it is against what you’re about to ship.
A component whose licence data couldn’t be resolved isn’t dropped silently, it’s listed in the document as unresolved, so you always know exactly what the deliverable does and doesn’t cover.

​
What’s Next

With a snapshot exported, the next step is knowing where to look when someone asks why a component was accepted months from now, the audit log.