Why it exists
Provenance started as the tool its authors needed to run their own estate: servers across several countries and data centres, and no way to answer “what do I own, and is any of it exposed” without a spreadsheet and a bad afternoon.
An estate of any size splits across teams and tools: the hardware register lives in one place, the dependency lists in another, the deployment record in a third. Each is defensible on its own. Together they cannot answer the question that actually arrives, which is always some version of “a vulnerability was published in this library — do we ship it, and is it running?”
Answering it means joining three things by hand, under time pressure, from systems that were never designed to be joined. The join is the work. Everything on this platform exists to make that join a lookup instead of an afternoon.
Both of these are real categories doing real work. Neither is the thing described above, and it is worth being precise about why.
| Category | What it is very good at | What it leaves to you |
|---|---|---|
| Vulnerability scanners | Finding what is wrong with a host or an image, in depth, continuously. | The inventory the findings hang off. A finding per machine is not an answer to “which of our releases ships this, and which are live”. |
| Cyber asset attack surface management | Federating what your other systems already know — cloud accounts, directory, scanners — and reconciling the overlaps. | The record of what you can evidence. A reconciled view of other tools is a view of other tools; an assessor asks what you published and when. |
No agent to install, no connector matrix to complete before the first useful screen, no call required to see the product. The cost of that choice is honest: nothing appears here on its own. What you get back is a register nobody has to be persuaded to deploy.
Every count on this platform is scoped to what you actually run, because a critical finding in a release nobody deploys is a backlog item and the same finding in production is an incident. A dashboard that ranks nothing trains people to read nothing.
Personal use carries the whole platform in a workspace of your own. And the audit log is hash-chained with the recipe published, so you can recompute it yourself rather than take our word for the thing the product is for.
Stated here so it is not a discovery you make after adopting it. Provenance does not sweep your network to find assets, does not apply patches, and does not watch a live host for configuration drift. It is a register of record and the evidence that the record is intact. Where a page elsewhere on this site counts something, it says what population it counted.
The person who has to answer for the estate: a systems or platform engineer with more machines and services than fit in one head, a security engineer who needs exposure ranked by reality, and the person who has to hand an assessor something they can check. It is built for the people doing the work rather than for the slide that describes it, which is the reason it looks the way it does.
A scanner answers "what is wrong with this host". This answers "what do I own, what is in it, and where is it running" — and then ranks what is wrong by that. The difference shows up during an incident: a scanner gives you a list of findings per machine, and the question you actually have is which releases contain a named library and which of those are live. That is a join across the inventory, not a deeper scan.
CAASM tools federate other systems: they connect to your cloud accounts, your directory and your existing scanners, and reconcile what those already know. This is a register of record instead — the SBOM your build actually published, the device your custodian actually holds — with a hash-chained history of every change. Those are complementary jobs. One tells you what your other tools believe; this tells you what you can evidence.
No. There is nothing to install on a host. Software enters the register when your CI publishes a CycloneDX SBOM against a release, and hardware enters it through the API or the register screens. That is a deliberate constraint: an agent is a privileged process on every machine you own, and it is the single largest reason inventory projects stall before they finish.
Personal use is free with the whole platform in it, in a workspace of your own that nobody else can see. A tool that is only trustworthy once you have paid for it cannot be evaluated honestly, and an engineer who cannot run it on their own machines will not recommend it for anyone else’s.
It does not discover assets by scanning your network, does not patch anything for you, and does not watch a running host for configuration drift. It records what you tell it and what your build publishes, and it makes that record verifiable. Those absences are on the record here rather than left for you to discover.
Yes. The register that runs this platform is the platform, including the components of the page you are reading. That is not a virtue in itself — it simply means the screens that are unpleasant to use get found by us first.
Personal use is free and the platform is whole. If you run an estate for somebody else, the enterprise conversation starts with what you actually have rather than a seat count.