In December 2021, when the Log4Shell vulnerability was disclosed, the hardest question in many engineering teams was not “how do we patch it?” but “which of our products actually contain Log4j?” Answering it often meant days of digging through build files and asking around. In March 2024, the backdoor in xz-utils raised the same question again, this time about a compression library that almost made it into major Linux distributions.

The European Union has turned that question into a legal matter. The Cyber Resilience Act (CRA) requires companies that sell software in the EU to know what their products are made of, keep that inventory in a machine-readable form, and fix vulnerabilities in it for as long as the product is supported.

In this article, we look at what the CRA expects from companies that ship desktop software, what a software bill of materials (SBOM) is, and how MōBrowser helps the companies to generate one with a single command.

The regulation 

The CRA, formally Regulation (EU) 2024/2847, entered into force on December 10, 2024. It applies to “products with digital elements”: hardware and software placed on the EU market in the course of a commercial activity, provided the product can connect to a device or a network. A commercially distributed desktop application falls into this scope. The official summary describes the full set of rules; here are the obligations that matter most for software vendors:

  • Perform a cybersecurity risk assessment and design the product around it.
  • Document the product’s components, including an SBOM.
  • Handle vulnerabilities during a defined support period and ship security updates.
  • Report actively exploited vulnerabilities and severe incidents within reasonable time.

The rules arrive in stages. The reporting obligations apply from September 11, 2026 — less than two weeks from the day this post is written. The full set of requirements, including the CE marking, applies from December 11, 2027. Breaking the essential requirements can cost up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

One item on that list deserves a closer look, because it turns “what is in our product?” from a question into a concrete artifact: the SBOM.

What SBOMs are 

A software bill of materials (SBOM) is a machine-readable inventory of everything a piece of software is built from: components, their versions, their origins, and how they relate to each other. Packaged food lists its ingredients; an SBOM does the same for software.

Machine readability is the point. Security tooling can match an SBOM against vulnerability databases and answer “are we affected by this CVE?” in seconds instead of days. When the next Log4Shell happens, that is the difference between a query and an archaeology project.

Two formats dominate the field: SPDX, which originated at the Linux Foundation, and CycloneDX, an OWASP project. Both are open specifications with JSON serializations, and both are supported by mainstream security scanners.

The CRA itself asks for a modest baseline: an SBOM in a commonly used, machine-readable format that covers at least the top-level dependencies of the product. It lives in the technical documentation and must be available to market surveillance authorities on request; there is no obligation to publish it. Regulators are not the only audience, though. The US federal government has been pushing its software suppliers toward SBOMs since Executive Order 14028 in 2021, and enterprise customers increasingly ask for them during procurement.

What you ship 

For a desktop application built with web technologies, the developer’s own code is a small slice of the final installer. A MōBrowser application, for example, ships with Chromium, the Node.js runtime for the main process, every production npm dependency with its transitive dependencies, the framework’s native modules, and the components of the update mechanism.

Each of these pieces has its own version, its own license, and its own security advisories. The exact composition also differs per platform: what ships on Windows is not what ships on macOS. An inventory maintained by hand is outdated after the first dependency update, and dependency updates are routine.

There is one party that already knows this inventory precisely: the framework that assembles the application. It decides which Chromium build to bundle, which native libraries to include, and which npm packages end up in the production build.

One command 

Starting with version 2.15.0, released on August 27, 2026, MōBrowser turns that knowledge into a report:

npm run sbom

The command generates a target-specific SBOM in CycloneDX 1.7 JSON format. It inventories the application and its runtime components for the current platform: Chromium, MōBrowser native and third-party dependencies, the Velopack components used for updates, and the installed production npm dependencies. Dependencies used only for development, building, packaging, or testing are excluded — the SBOM describes what customers receive, not what developers use.

The generated document and its SHA-256 checksum are written to build/dist/<target>/sbom/.

Choosing a framework 

Frameworks for building cross-platform desktop applications with web technologies are usually compared on runtime footprint, platform coverage, and API surface. The CRA adds a quieter criterion to that list: how much of the compliance work the framework takes on itself.

Built-in SBOM generation is still rare in this class of tools. For teams that need an SBOM today, the usual route is to attach a third-party scanner to the build pipeline, configure it for every platform they ship, and keep that setup working as the project evolves.

An external scanner also has a visibility problem. It inspects the packaged application from the outside and may miss components the framework bundles deep in its runtime. The framework itself is in a different position: it generates the SBOM from the same knowledge it uses to build the application, so the report reflects what actually ships.

So, if you are evaluating frameworks for building a cross-platform desktop application with web technologies, and dependency transparency is on your requirements list (because of the CRA, customer questionnaires, or your own security process), then it is worth checking what each candidate offers here. MōBrowser answers with one command.

Conclusion 

The CRA makes dependency transparency a legal requirement, and its deadlines are close: reporting obligations start on September 11, 2026, and the full set of rules applies from December 11, 2027. The SBOM is the artifact at the center of that transparency. MōBrowser 2.15.0 produces one with a single command, straight from what the framework actually bundles into your application. The details are in the release notes and the CLI documentation.