Software Bill of Materials

Know what's in your software. Export an SBOM auditors accept.

BreachLens builds a CycloneDX SBOM for every repository and container image it scans — the complete dependency inventory, with the known-vulnerable components flagged and tied to whether they're actually reachable. The artifact your software-supply-chain program runs on.

Book a technical demo Read the docs

CycloneDX exportVulnerable components flaggedAir-gap capable

Inventory you can hand over

You can't secure what you can't list.

Regulators and customers increasingly ask for a bill of materials, and “we think we know our dependencies” isn't an answer. BreachLens produces the list as a byproduct of scanning — and marks which entries are actually a risk.

Scan

Repos and images

BreachLens inventories the dependencies in a repository or a container image as part of a normal scan.

Inventory

The full component list

Every component, version, and license is captured — with the known-vulnerable ones flagged against their CVEs.

Export

CycloneDX, on demand

Export a CycloneDX SBOM whenever you need one — for an auditor, a customer, or your own supply-chain records.

What you get

An inventory that's more than a list.

CycloneDX export

The format that travels.

· For repositories and container images alike.
· Machine-readable, ready for your supply-chain tooling.
· Generated as a byproduct of scanning — no separate step.

Vulnerable components flagged

Not just what — what's risky.

· Which dependency, which version, which CVE.
· The risky entries called out, not buried in the list.
· The bridge from “inventory” to “action.”

Tied to reachability

Is the risky package even used?

· Cross-referenced with function-level reachability.
· So a vulnerable-but-unreached package doesn't fake an emergency.
· Across major language ecosystems.

Provenance you can verify

Not just what — where it came from.

· Verify container image signatures with Cosign during a scan.
· A bill of materials that sits next to a provenance check.
· All of it inside your own network.

Part of the attack path

A supply-chain risk, in context.

· A vulnerable dependency correlates with the image and app it ships in.
· So a risky component surfaces as a chain, not an isolated row.
· Supply-chain risk you can prioritise, not just enumerate.

breachlens · dependencies

A real BreachLens repository view — the dependency inventory for a repo, grouped by tier, with known-vulnerable components flagged against their CVEs, the fix versions to move to, and whether each is actually reachable.

Every dependency BreachLens finds — the known-vulnerable ones flagged with their CVE, the fix version to move to, and whether the package is actually reachable.

Straight answers

What a compliance owner asks about SBOMs.

Which SBOM format do you produce?

CycloneDX, for repositories and container images. SPDX export is on the roadmap, not shipped — if you need SPDX today, we'll tell you where that stands rather than imply it's live.

Does it flag vulnerable components?

Yes — the SBOM isn't just an inventory. Known-vulnerable components are flagged against their CVEs, and cross-referenced with reachability so an unused vulnerable package doesn't read as a fire.

Can it verify image signatures?

Yes — BreachLens can verify container image signatures with Cosign as part of a container scan, so a bill of materials sits alongside a supply-chain provenance check.

Where does it run?

On your infrastructure. Your dependency inventory never leaves your network — it can run fully air-gapped.