Won't an SBOM give away my IP?.

You've spent two years and most of your funding building something genuinely novel. Then someone tells you that to clear the FDA, you'll need to hand over a "bill of materials" listing everything inside your software. The regulator will require it, that part isn't optional. Your hospital customers may well ask for it too.

Your stomach drops a little. I've poured everything into this. Why would I publish a parts list that tells competitors exactly how it's built?

It's a fair worry, and I hear it often. It's also, once you look at what an SBOM actually is, a much smaller problem than it first appears. Let me walk through why.

You've pictured the wrong document

The fear usually comes from imagining the wrong thing. "Share your SBOM" sounds like "share your source code." It isn't.

An SBOM is a list of the third-party and open-source components in your software, with their versions and suppliers, OpenSSL 3.0.7, SQLite 3.41, zlib 1.2.13, that sort of thing. (If you want the full primer, our guide to what an SBOM is covers it.) For the IP question, the thing to hold onto is that it's an ingredients list, not the recipe. It says nothing about how you combined those parts. Your proprietary logic, your algorithms, your architecture, the actual code you wrote, none of that is in there.

And here's the part founders tend to miss: the IP that matters is almost never the list of open-source libraries you used. Half your industry uses the same handful of libraries. Your IP is what you built on top of them, and that is exactly what an SBOM leaves out.

What's actually in an SBOM

The fear lives in the vagueness, so let's make it concrete. A baseline SBOM (the NTIA minimum elements) is deliberately narrow:

• Supplier name
• Component name
• Version of the component
• Unique identifiers (the standardised codes that pin down exactly which component it is)
• Dependency relationships (what relies on what)
• Author of the SBOM data
• A timestamp

That's the baseline. Look at what isn't on the list: no source code, no proprietary algorithms, no architecture diagrams, no clinical logic, no data schemas, no keys. Seven fields, and not one of them is the thing you stayed up late building.

I'll be straight with you about the one nuance: a very detailed SBOM that names your own internal modules reveals a little more than a minimal one, because a module's name can hint at what it does. But that's an argument for sensible scoping and access control, both of which the guidance already expects. It isn't an argument against producing an SBOM at all.

The bit that should actually reassure you

Here's the point that does the most work, and it's worth being technically honest about, because anyone clever enough to worry about this is clever enough to see through a glib answer.

Your real exposure was never the SBOM. It's the shipped product.

The moment you ship software into the field, a determined party with reverse-engineering tools can pull a great deal out of it. And the easiest thing to recover that way is precisely the list of off-the-shelf components, because open-source libraries leave fingerprints: recognisable version strings, known patterns, telltale signatures. Composition analysis tools reconstruct that list automatically.

So the one thing an SBOM contains is the one thing a competitor could already get without it. Producing the SBOM doesn't widen your exposure. It just writes down the part that was never really a secret.

Could a skilled reverse engineer go further and lift some of your proprietary logic from a binary too? Yes, with real effort, they could. But they'd do that from the binary, not from the SBOM, and they could do it whether or not the SBOM exists. That risk is a property of shipping software at all, and the answer to it is the same as it's always been: obfuscation, the sheer cost and effort of reverse engineering, patents where they apply, trade-secret, and contractual protection. An SBOM changes none of it.

If your software lives in the cloud, it's a bit different

One honest caveat. The argument above assumes your software is distributed, shipped firmware, an installed application, a device in someone's hands. That covers a lot of medical devices, but not all of them.

If your software is cloud-hosted, there's no binary for anyone to take apart. Your code runs on your servers and stays there, which means your proprietary logic is actually better protected than in the shipped-device case, not worse.

The trade-off is that the component list isn't sitting in a binary for the world to recover either, so an SBOM does write down more than an outsider could easily get. Two things keep that in proportion. First, a fair bit of your stack is still visible from outside anyway, through response headers, the JavaScript served to a browser, how the system behaves against known issues. Second, and more importantly, this is exactly why an SBOM travels as confidential evidence rather than a public document, which brings me to the real heart of it.

Sharing an SBOM is not publishing it

A lot of the anxiety assumes "share your SBOM" means "release it to the world." It doesn't.

When you give an SBOM to the FDA, it goes into a confidential premarket submission. That's a protected regulatory channel, not a press release. Reviewers use it to check that you can identify and manage vulnerabilities in your third-party components. They are not posting it online.

The international guidance is explicit on this. The principles published by IMDRF, the forum of medical device regulators, for medical device SBOMs (document N73) recommend that SBOMs be classified as sensitive, confidential information, and that the channels used to share them with regulators and healthcare providers support proper protection. Controlled, tiered distribution is baked into how SBOMs are meant to be handled. When a hospital customer receives one, it's under their procurement and security agreements, usually with an NDA, so their security team can run vulnerability management on the device they're about to plug into their network.

In other words, the confidentiality you want for your IP is already built into the way SBOMs are supposed to move. You're pushing on an open door.

The reframe worth keeping

It helps to stop seeing the SBOM as a tax on your IP and start seeing it as the thing that gives you control over the part of your device you didn't write.

You can't patch what you can't see. When the next Log4Shell-scale vulnerability lands, the SBOM is how you answer "are we affected?" in minutes rather than spending a fortnight in manual archaeology. It's also the practical foundation for the SOUP management that IEC 62304 and IEC 81001-5-1 expect, and for the third-party software risk that ISO 14971 asks you to account for. Skip it, and every new vulnerability becomes a fire drill.

The bottom line

An SBOM lists the off-the-shelf parts in your software. It doesn't contain your source code, your logic, or your design, and those were never in it to give away.

It doesn't widen the exposure you already have from shipping a product, and for cloud software your logic never leaves your servers at all. It travels as confidential regulatory evidence, not a public release. And it's the thing that lets you manage the components you didn't write when, not if, the next big vulnerability arrives.

The list of libraries you used was never your secret. What you built with them is, and an SBOM doesn't touch it.