Skip to content
New Pro plans with Agentic Verification.

Software bill of materials. Know what your software runs on.

The applications you rely on are assembled from components someone else wrote. Every Pro rebuild gives you a CycloneDX list of them, so you can patch faster, recover sooner, and get through audits without the last-minute rush.

Book a demo
  • Trusted for software resilience by 3 500+ teams
  • Comes with Agentic Verification
Product security engineers inspect a connected infusion pump in a medical-device lab
Software bill of materialsPayments Core · regenerated by run #12 · Oct 8, 2026CycloneDX
415 components
ComponentVersionTypeLicense
openssl3.0.13LibraryApache-2.0
log4j-core2.23.1LibraryApache-2.0
express4.19.2LibraryMIT
zlib1.3.1LibraryZlib
ledger-core4.2.0Private packageProprietary
pdf-render-sdk9.1.0Licensed componentCommercial

Showing 4 of 415 components.

CycloneDXExample values; apart from the open-source libraries, the names are made up.

Evidence for the frameworks that ask for a component inventory

Why our SBOM

Refresh your SBOM evidence with every rebuild.

If your SBOM tracks vulnerabilities in a regulated industry, it can't afford to feed you false information. On every Pro plan, Agentic Verification rebuilds your critical applications, so each SBOM matches what you're running right now.

February

SBOM · Run #8

412

components · first run

CycloneDX
May

SBOM · Run #9

418

components · 6 added

CycloneDX
August

SBOM · Run #10

421

components · 3 added, 7 updated

CycloneDX
November

SBOM · Run #11

419

components · 2 removed, 4 updated

Latest

From the rebuild: what the build actually pulled inEvery run: up to four times a yearCycloneDX: the standard format

Illustrative names and values for a sample application.

What is an SBOM?

What's really running inside your software?

Think of an SBOM as your software's ingredients list, naming each library, package, and model it's built from, along with the version, type, and licence of every one.

Selling software?

Hand it to buyers to clear security reviews, and show regulators what you supply.

Buying software?

Spot vulnerabilities in what you rely on, and know what a recovery would take.

One SBOM entryExample values
Component
log4j-core
Version
2.23.1
Type
Library
License
Apache-2.0
With AI applications, models and datasets appear in the SBOM too.

What you get

A single list that answers the questions people put to you.

  • Top-level components, all of them.

    Name, version, type, and licence for each, drawn from the application as built.

  • AI models and datasets included.

    Once models and datasets are listed, it qualifies as an AI bill of materials.

  • Taken from an actual rebuild.

    It records everything the build draws in, components missing from the repository included.

  • CycloneDX, ready to share.

    Export to the standard format read by most security and compliance tools, then send it to buyers, auditors, or authorities.

  • A record from each run.

    Every SBOM is kept in the vault alongside the software it covers, for as long as your framework demands.

  • Add-on

    Component watch.

    Get flagged when a new vulnerability affects a component in your SBOM, between runs.

Why you need an SBOM

Regulators now want to know what your software contains.

The CRA, and regulators like the FDA, ask for it outright. Others like DORA and NIS2 name it in different words. But they all agree you need a current component list to support continuity.

An SBOM is required under the CRA.

It must be machine-readable, held in your technical file, and provided whenever authorities request it. Applies from 11 December 2027.

A complete software inventory is required under DORA.

It means an up-to-date record of your software assets and how they link together, and an SBOM is the most practical way to evidence it. Already in force.

How it works

Every run brings a new component list.

Your Pro plan's Agentic Verification runs each produce a refreshed SBOM in CycloneDX format, keeping your compliance evidence up to date with no extra effort.

Keep your code and build files synced.

Link your repositories through 50+ integrations and upload anything stored elsewhere, so the vault has an up-to-date copy each day.

Policy admin · Deposits
policy-admin-apiSynced todayCurrent
policy-admin-webSynced todayCurrent
build-config.zipUploadedCurrent

Launch a run at a time that works for you.

AI agents figure out how your software is built and rebuild it from our copy, using Codekeeper's own models, and once you add anything they flag as missing, the run finishes.

Agentic Verification · Run #12
Work out how the software is builtDone
Rebuild from the depositDone
1 file flagged as missingUpload file
Generate SBOMWaiting

Pick up your latest SBOM.

Check each component behind your application, with its version, type, and licence, along with models and datasets for AI applications.

SBOM · Run #12CycloneDX
ComponentVersionTypeLicence
openssl3.0.13LibraryApache-2.0
log4j-core2.23.1LibraryApache-2.0
express4.19.2FrameworkMIT
zlib1.3.1LibraryZlib

Store every SBOM with your code.

Each list sits in the vault next to the software it records, kept as long as your framework calls for.

Policy admin · Vault
SBOM · Run #12Oct 2, 2026Latest
SBOM · Run #11Jul 1, 2026Kept
SBOM · Run #10Apr 3, 2026Kept

Example values throughout.

Where your SBOM comes from

A list is a claim. A rebuild backs it up.

A list scanned from a repository can miss what the build actually pulls in. Yours comes from a real rebuild, by our agents or by our engineers.

Included in Pro plans

Agentic Verification. A current SBOM, up to four times a year.

Escrow Pro, Resilience Pro, Continuity Pro, and Software Backup Pro include up to four runs a year, on supported technology stacks, each started whenever you choose, and every successful run produces a new SBOM. Releasing often? Add extra runs, or Component watch to flag new vulnerabilities in your components between runs.

Add-on to any plan

Exit Exercise. An SBOM of the recovered software.

Working by hand from the deposit alone, our specialists rebuild your software, restore its data, deploy it, and test your chosen functions, then give you an SBOM of precisely what they restored.

Sample evidence pack

Browse a sample evidence pack.

See what a run produces, using example values.

What's at stake

What you can't find, you can't patch, recover, or prove.

How things play out in operations and compliance without a current SBOM, and with one from every successful run
AreaWithout a current SBOMWith an SBOM from every successful run
Operations
VulnerabilitiesAn exploited vulnerability becomes days of downtime as the team hunts for the library to fix.Your component lists reveal the affected applications, so patching begins sooner.
RecoveryRecovery grinds to a halt, and the business stays down while someone hunts for missing components.Your recovery team works from a list of everything the build requires.
End of lifeAn unsupported component breaks in production with nothing lined up to replace it.Replacements are lined up well before support runs out.
Compliance
AuditsFindings from the audit end up as extra work on your team's roadmap.The audit moves along, as your CycloneDX inventory is already on file.
Security reviewsThe deal waits on a buyer's security review while you track down answers.Drop the SBOM into the buyer's questionnaire, and the deal keeps moving.
EU market accessWithout an SBOM, you risk losing EU market access and facing CRA fines of up to €15 million or 2.5% of worldwide annual turnover.Your technical file contains the current SBOM the CRA demands for EU market access.
AuthoritiesGiving authorities inaccurate information brings separate fines of up to €5 million or 1% of worldwide annual turnover.Each answer you give authorities is based on current information.

Take stock of your software. At every release.

Each release alters what your software contains. Speak to our software resilience specialists today about keeping your component records up to date.

Frequently asked questions

The SBOM questions worth asking.

What does an SBOM contain?

An SBOM contains an inventory of the components inside an application. The most accurate ones come from an actual build, as yours does, since a build picks up components that never sit in the repository.

Is an SBOM required under the CRA?

Yes, an SBOM is required under the CRA, with manufacturers of products with digital elements obliged to produce one in a commonly used, machine-readable format covering at least top-level dependencies. Its vulnerability reporting duties have applied since 11 September 2026, and its main obligations apply from 11 December 2027. DORA and NIS2 don't name the SBOM, but they expect the inventory one provides.

What's included in the SBOM, and which format is it in?

The SBOM covers your application's top-level dependencies, the components it's built on directly, and, for AI applications, the models and datasets they run on, in CycloneDX, a standard format most security and compliance tools can read. You can export it to share with buyers, auditors, or authorities.

When does the SBOM get updated?

The SBOM is updated with every Agentic Verification run. Pro plans include up to four runs a year, on supported technology stacks, started whenever you choose. You can add more runs, or Component watch to flag new vulnerabilities in between. The Exit Exercise also produces an SBOM of the software as recovered.

Do you have to make your SBOM public?

No, your SBOM doesn't need to be published. The CRA only requires manufacturers to give their SBOM to market surveillance authorities when asked, and many vendors share theirs directly with buyers to get through security reviews.

Do I still need escrow if I have an SBOM?

Yes, escrow is still needed once you have an SBOM, because each does a different job. The SBOM lists the software's contents, while escrow holds everything required to recover it, and your SBOM comes from the very deposit your escrow protects.