Cloud 5 min read

OCM Lens: Inspect OCM Deliveries and Their Embedded SBOMs

OCM Lens opens component descriptors and CTF archives in the browser: component trees, signatures, embedded SBOMs and quality profiles, fully client-only.

OCM Lens: Inspect OCM Deliveries and Their Embedded SBOMs

OCM Lens: Inspect OCM Deliveries and Their Embedded SBOMs

Anyone working with the Open Component Model knows the moment: a CTF archive lands on your disk, somewhere inside sit four components, thirty resources and a couple of SBOMs, and your only window into it is ocm get componentversion in a terminal. For quick answers to questions like “which images does this release ship?” or “is the signature even there?” that is clumsy. So we built OCM Lens: a free viewer for OCM deliveries that opens component descriptors and CTF archives directly in the browser. Like its sibling SBOM Lens it is open source under Apache-2.0 and fully client-only.

Drop an archive, get a tree

OCM Lens takes what a delivery pipeline actually produces: individual component-descriptor.yaml files or complete archives as .ctf, .tar or .tgz. Archives are unpacked in the browser, and both artifact layouts are supported, flat OCI manifest as well as nested artifact sets. The tool resolves component references across all loaded descriptors and renders one continuous tree: component, reference, resource. Unresolvable references appear as actionable placeholders, the same approach that proved itself in SBOM Lens.

The practical kicker: SBOMs stored as resources inside the delivery are extracted in the same pass and linked to their component by checksum. One loaded delivery then answers both supply chain questions at once: what ships, and what is it made of? For the model fundamentals, see our introduction to the Open Component Model.

OCM-native, not someone else’s vocabulary

A deliberate design point: OCM Lens does not squeeze OCM concepts into an SBOM-shaped schema. Labels appear with signing badges, repository contexts, signatures with algorithm and digest triple, access specifications, artifact digests and extraIdentity are all displayed the way the descriptor records them. The tool stays strictly read-only: digests are displayed, never verified. Cryptographic verification remains the job of the OCM CLI; a viewer should stay honest about what it does.

The five views mirror the sibling tool. Explore shows the component tree alongside the raw descriptor, Map the delivery’s topology, Inventory the resource table with CSV and JSON export, Conflicts groups resources shipping in more than one version, and Diff compares two delivery states as copyable Markdown for release notes.

On top, every descriptor gets a quality report against a builtin profile called OCM Component Essentials: version coverage as a hard gate, digest and access coverage as informational meters, plain numbers instead of an invented score. Organizations with stricter house rules can bring their own profile.

Client-only, self-hostable, in your editor

Like SBOM Lens, OCM Lens is a static web app: descriptors and archives are unpacked locally and never leave your machine. For deliveries this matters even more than for SBOMs, since a component descriptor reveals registry paths, internal component names and version states. URL fetching only happens on explicit request. Teams are best served by a self-hosted instance behind their own reverse proxy: it reaches private registries without tokens in the browser and can ship a curated catalog via ocmlens.catalog.json, where one click loads a descriptor and everything it references.

For daily work there is the VS Code extension: “Open with OCM Lens” on any component-descriptor.yaml, CTF archives open with it by default, and workspace scanning finds every delivery in the repository. Both tools share their interaction model and views; the source lives on GitLab, with the sister project alongside it. If you know one, you are instantly at home in the other.

Conclusion

OCM is a strong model with, so far, thin tooling beyond the CLI. OCM Lens fills the reading half of that gap: open deliveries, understand them, compare them, including the SBOMs travelling inside, without a single file leaving your machine. The fastest start is the bundled example in the viewer. And if you are still about to introduce OCM into your delivery pipeline, we accompany the journey from architecture to operations: cloud and infrastructure at EverBright.

Frequently Asked Questions

What is OCM Lens?

OCM Lens is a free, open source viewer for deliveries following the Open Component Model, developed by EverBright IT. It opens component descriptors and CTF archives directly in the browser, resolves component references and shows embedded SBOMs. The tool is client-only and licensed under Apache-2.0.

Which formats can OCM Lens open?

OCM Lens reads component descriptors as YAML or JSON, and CTF or component archives as .ctf, .tar or .tgz. Both artifact layouts are supported, flat OCI manifest and nested artifact sets. SBOMs contained in the delivery are extracted and linked to the matching component automatically.

Does OCM Lens verify signatures?

No, deliberately not. OCM Lens displays signatures with their algorithm and digest triple exactly as the descriptor records them, but stays strictly read-only. Cryptographic verification belongs in the OCM CLI or your CI pipeline. The viewer makes visible whether and which signatures are present.

Do my deliveries stay local when I open them?

Yes. OCM Lens is a static, client-only application: archives are unpacked in the browser and never uploaded. URLs are only fetched on explicit request. For private registries you can run your own instance behind a reverse proxy, optionally with a curated delivery catalog for your team.

#OCM #Open Component Model #CTF #SBOM #OCM Lens
Share:
Sergej Bardin

Sergej Bardin

CEO · AI Strategy & IT Consulting

Helping mid-sized companies adopt AI and shape their cloud strategy. Focus on practical decisions over hype.

AI StrategyMCPRAGMulti-CloudIT ConsultingMid-Market