What an SBOM is, and why the CRA asks for one
A software bill of materials is an inventory of what is inside your software. Here is what it is, why the CRA wants it, and how to produce one.
Modern software is mostly other people's software. Your product ships with open-source libraries, frameworks, and dependencies, and each of those can carry its own security flaws. A software bill of materials, or SBOM, is simply an inventory of those components.
Why the CRA wants it
The CRA expects manufacturers to identify and document the components in their products, and to not ship products with known exploitable vulnerabilities. You cannot do either without knowing what is inside your software. An SBOM is how you know. Once you have the inventory, you can screen it against vulnerability databases to see whether any component has a known flaw, and that screening becomes evidence in your technical file.
How to produce one
You do not write an SBOM by hand. Build tools generate it from your dependencies. The two common machine-readable formats are SPDX and CycloneDX. Generate the SBOM as part of your build so it stays current with each release, rather than producing it once and letting it drift.
Then screen it. Tools compare your component list against public vulnerability data such as CVE identifiers and the OSV database, and flag components with known issues. Fix or update the ones that matter, and keep the result as evidence.
In Vandorisk you can upload your SBOM and get the known-vulnerability results back automatically, attached as evidence in your assessment. It turns the inventory into part of your technical file.