Bill of materials and SBOM tools

The software bill of materials (SBOM) lists the components a product is made of. It exists to answer, fast, the question that matters during an incident: «does this defect affect us?». CRAnotify does not generate SBOMs: it connects to the tools you already run in your pipelines and records the synchronisation.

Connectable tools

From Account area › SBOM you enable the tools in use and, where needed, enter an address and a token:

GenerationSyft, Trivy, GitLab.

Analysis and vulnerabilitiesGrype, Snyk, JFrog Xray, Sonatype Nexus, Mend.

Bill-of-materials managementDependency-Track, FOSSA.

Development platformGitHub (security advisories and dependencies).

The configuration is per organisation and is an administrator action; every change leaves a registry row.

Automatic intake from your pipelines

A CI scanner can push the SBOM straight into CRAnotify. The push authenticates with an API key carrying the products:write scope, on the X-CRA-API-Key header (or Authorization: Bearer cra_live_…). The product is identified by the SKU in the path:

curl -X POST "https://api.cranotify.eu/api/v1/external/products/PRD-4f2a91/sbom?tool=trivy&release=2.4.1" \
     -H "X-CRA-API-Key: cra_live_…" \
     -H "Content-Type: application/json" \
     --data-binary @sbom.json

Aspect	Value
Accepted formats	CycloneDX (JSON) and SPDX (JSON).
Maximum size	25 MB per push.
`tool` parameter	Optional: if absent, the tool is recognised from the document's metadata.
Product (SKU in the path)	The product is identified by the SKU in the path (`/products/{sku}/sbom`): the SBOM always attaches to that product. A SKU that does not exist in your organisation is rejected (see below).
`release` parameter	Optional: it attaches the document to a specific release in the product's history. If absent, the release the product declares as current is used.
Response	JSON with tool, format, number of components and of vulnerabilities, and the moment of receipt.

A successful push marks the tool as genuinely connected (storing a token is not enough), updates the component count and leaves a registry row.

Response	Meaning
`401 invalid_api_key`	Key missing, wrong or revoked.
`403` (missing scope)	The key exists but does not carry the `products:write` scope.
`404 unknown_product`	The SKU in the path names a product that does not exist in your organisation. A SKU belonging to another organisation gives the same answer as one that was never created.
`422 unrecognised_sbom_format`	The body is neither CycloneDX nor SPDX JSON.

History: bills of materials are never overwritten

Every bill of materials received is kept as a fact of its own, with two distinct times — when it was produced and when we received it. The identity of a bill of materials is product + release: a second push for the same release becomes a new version, and the earlier one stays readable.

An SBOM therefore belongs to a specific release and is versioned per release (never overwritten). Web upload, external API and CLI all converge on the same versioned model. The release detail (/releases/{id}) shows the release information, the SBOM history and the component inventory.

This is not a convenience. If an authority asks which version of a component was shipped on the day you became aware of a problem, the answer has to be rebuilt from what the system could know that day — and «we no longer know» is an answer no later diligence recovers.

FreshnessFour technical states: a bill of materials exists for the release the product declares as current; only earlier releases have one; none has ever arrived; the product declares no release. They say whether the material is aligned, never whether the product is in order.

ComparisonBetween the two most recent bills: components added, removed and updated. If either of them held a truncated list, the comparison declares itself unreliable instead of announcing removals that never happened.

Very large listsBeyond 5000 components the stored list is truncated and says so: the count and the digest of the document stay exact regardless.

Uploading a bill of materials by hand

From a product page you can upload an SBOM file directly, with no pipeline and no key. It is what you need on day one, when the integration is not there yet but the product must already stop being blind: without a bill of materials, a vulnerability published on a component cannot be matched to any product.

The file goes through the same checks as the automatic push — same formats, same 25 MB limit, same rejections — and enters the same history. If you do not state a release, the one the product declares as current is used; if the product declares none, the upload is rejected rather than one being invented. The record keeps who brought that document in, and that it was a person.

What it is for in the flow

Narrowing the scope. When a vulnerability lands on a widely used library, the bill of materials says which of your products carry it, and in which version.
Feeding the upstream report. The recorded components are the list the report to the maintainer starts from.
Documenting diligence. Two active tools cover one of the seven steps of the setup checklist.

CRAnotify does not decide for you whether a vulnerable component makes the product exploitable: the presence of a library is not the presence of an exploitable defect in that context. That assessment remains the triage.

Formats

The supported standards are CycloneDX and SPDX. Producing SBOMs in only one of them is fine: what matters is that they are refreshed at every release. A bill of materials two years out of date is worse than none, because it invites wrong conclusions.

How to organise it

Generate the SBOM in the build pipeline, not by hand.
Push it to CRAnotify at every release with a dedicated key (scope products:write only).
Keep the list of critical components with their maintainers in the product register.
Check occasionally that the last synchronisation date matches the last release.