provenance
Sign in

RODMENA LIMITED · bill of materials as a platform

Every device you own and every component you ship, in one register

provenance is a bill-of-materials system of record. It holds your hardware estate and your software supply chain together, keeps both tamper-evident, and turns them into the evidence an ISO 27001 or Cyber Essentials assessor asks for.

The questions it exists to answer

Each of these spans hardware and software. A tool that holds only one half can get part of the way and then asks you to join the rest by hand, usually in a spreadsheet, usually during an incident.

A critical CVE lands in a dependency

Which of our releases contain it, which of those are deployed right now, and which machines are they running on? One lookup, because components are deduplicated by purl across the estate and joined to the deployment map.

Someone leaves on Friday

What hardware do they hold, including anything out for repair or recorded lost, was each device wiped, and were their sessions ended? Offboarding lands on one page instead of four systems.

An assessor asks what you held in March

The register is reconstructed from its event log for any past date, so “what did we own, and who had it” has an answer that is not a backup restore.

Prove this SBOM is the one CI produced

The published bytes are retained with their digest, so the document you hand a regulator is the artefact your build emitted, not a lookalike regenerated from a database years later.

One register, two halves

The field splits these: asset-management tools own hardware, software-composition tools own dependencies, and the join between them is left to you. That join is the whole point — it is what separates a vulnerability you must fix tonight from one that can wait for the next release.

Software bill of materials

CycloneDX ingest per release, components deduplicated by purl, a deployment map naming the environment and the machine, vulnerability findings ranked by real exposure, VEX positions a human approves, and licence policy with recorded verdicts.

Hardware bill of materials

Every device with a full lifecycle, the custodian who holds it, disk-encryption evidence, the register as it stood on any past date, and disposal that requires a certificate and a human approval before anything leaves the books.

Built to be checked, not believed

A compliance record is only worth what an auditor can verify. Four things here are unusual, and each exists because the alternative is a system that looks correct and is not.

  • A hash-chained audit log you can recompute. Every mutation and every read is appended and linked to its predecessor by digest. The service publishes the canonical payload, so you can verify the chain yourself and never have to trust a green tick we render.
  • A scanner that has to prove itself. A clean scan result from a broken scanner is indistinguishable from a clean estate. The scanner is gated on finding planted vulnerabilities first, and the dashboard says so whenever its trustworthiness is unproven.
  • Machines record and propose; a person approves. Suppressing a critical finding, disposing of an asset and accounting for a break in the audit chain are scopes no API key can ever hold, by anyone, including an administrator.
  • Evidence that states its own limits. Every control in an exported pack carries what the register proves and what it does not. A pack that claims more than it can support is worse than no pack, because the gap is found by the assessor.

For the systems, not only the people

Every screen here is a thin layer over an HTTP API that CI, a scheduler or an agent drives directly. Credentials are scoped API keys with mandatory expiry, capped at a year, shown once and stored as a digest. The API is documented for machines at /llms.txt, and a credential can ask what it may do without discovering its limits by provoking a refusal.

Common questions

What is the difference between a BOM, an SBOM and an HBOM?

A bill of materials lists what something is made of. A software bill of materials (SBOM) lists the components inside a release — libraries, versions and licences. A hardware bill of materials (HBOM) lists the physical estate — laptops, servers, network kit — and who holds each one. Most tools do one or the other. provenance keeps both in one register, because the question that matters in an incident spans them: this library is vulnerable, which releases ship it, and which machines are running those releases right now.

Which SBOM formats can I publish?

CycloneDX JSON today, posted per release. The exact bytes you publish are retained and their SHA-256 digest is recorded, so the document you download later is provably the one your build produced, not a reconstruction assembled after the fact. SPDX ingest is on the roadmap.

Does it scan for vulnerabilities, or do I bring my own findings?

It scans. A release with a published SBOM can be scanned on demand or on a nightly schedule, correlating several advisory sources. Findings are ranked by whether the affected release is actually deployed, because a critical CVE in something nobody runs is a backlog item and the same CVE in production is an incident.

How is this different from a vulnerability scanner?

A scanner tells you what is wrong today. A register tells you what you had, what you shipped and what you decided, on any past date, in a form an auditor can check. provenance keeps the deployment map, the licence positions, the disposal certificates and a hash-chained log of every change, so it answers questions after the fact that a scanner cannot answer at all.

Can I trust the audit trail if I do not trust you?

That is the design. Every entry stores the digest of its predecessor, and the service publishes the exact fields the digest covers along with the whole log in genesis order. You can recompute the chain yourself and reach your own verdict without taking our word for anything. Breaks are never repaired, only annotated, because repairing one is the act the chain exists to detect.

What does it cost?

Free for personal and evaluation use, and you get the whole platform — there is no cut-down tier. Enterprise deployments are scoped with our sales team against the estate you actually run. Write to sales@rodmena.co.uk with its size and we will take it from there.

How does this work for a company?

Enterprise customers get their own workspace, operated by RODMENA and sized to their estate, with membership, roles and invitations managed inside it. Tell us the shape of the estate and we will scope it with you; see the security page for how separation works today and where it is going.

Start with your own estate

Free for personal and evaluation use. For an enterprise deployment, tell us the size of the estate and what you need to evidence, and we will size it with you.