Medical Device & SaMD

Your SBOM Lists the Framework, Not the 1,000 Packages Underneath

Bill Barksdale, CISSP

In short

A first-draft SBOM usually names the framework and a handful of major libraries. A real application pulls in a thousand or more packages transitively, and that is where the vulnerabilities live. Generating the document is a build step. Getting it to come back clean is a software project, and nobody budgets for it.

Of the three things Section 524B requires in a premarket submission, the software bill of materials is the one everybody assumes is handled. It is a list. You have a build system. How hard can a list be.

It is the one I most often find wrong, and it is wrong in a specific and consistent way.

What a cursory SBOM looks like

A first-draft SBOM names the framework and the major libraries. A few dozen entries, everything on it real and correctly identified, every line of it defensible.

The application underneath it references a thousand packages or more.

That gap is not sloppiness, it is a misunderstanding of what the document is for. Somebody sat down and wrote out the software they knew they were using - the dependencies a developer consciously chose and could name from memory. What they did not capture is that each of those pulls in its own dependencies, and those pull in theirs. You take a dependency on one package and you have taken a dependency on forty. Three levels down, nobody chose anything. The package manager resolved it.

Those are the transitive dependencies, and they are the entire point of the exercise.

The vulnerabilities are never in the part you chose

Think about what the SBOM is actually for. Somebody - you, a reviewer, a hospital's security team two years from now - needs to answer one question: a vulnerability was just published in some component, are we affected?

A framework-level list cannot answer that question. The components your developers deliberately selected are the well-known, heavily maintained ones. They get patched fast and they are on everybody's radar. The exposure lives four levels down in a parsing library that one of your dependencies uses for one edge case, maintained by two people, which has an unauthenticated remote code execution advisory nobody at your company has ever heard of.

If that package is not in your SBOM, you have no mechanism for finding out. The document gives you false confidence, which is a worse position than having no document at all, because at least an absent SBOM does not tell you that you checked.

This is also why the NTIA minimum elements FDA points to include dependency relationships. A flat list of what you chose is not a bill of materials. It is a credits page.

The work is the remediation, not the document

Here is the part that nobody puts in the project plan.

Generating a complete SBOM is a build step. Modern tooling walks the resolved dependency tree and emits a machine-readable file, and that part is close to free once it is wired up. The problem is what comes back when you scan it.

Producing an accurate picture routinely means upgrading packages in the hundreds. Not reviewing hundreds. Upgrading them. That is a genuine software project with regression risk, testing, and a real chance of breaking something that currently works, and it sat entirely outside what anyone had scoped as the cybersecurity work.

That is the honest shape of this. The submission asks for a document. The document, if it is accurate, exposes a backlog. The backlog is the actual cost, and it is nearly always larger than the effort to write every other piece of the cybersecurity package combined.

Not every entry on it needs code, either. Some components get upgraded, some are unreachable in your configuration and get a written rationale, and some are mitigated by a control. That is the same discipline that a penetration test report demands: every item gets an explicit verdict, and an undocumented decision is indistinguishable from an oversight when somebody reviews it later.

Budget for the upgrades, not for the file.

Run the scan until it is boring

You do not do this once.

After upgrading, regenerate the SBOM and scan it again. Then again. Each round of upgrades reshapes the dependency tree - a package moves to a new major version and brings different children with it, some of which have their own advisories. You are not converging on the first pass. You iterate until a clean scan is boring rather than surprising, and the boring result is the deliverable.

That repetition also gives you something a reviewer cares about and a one-time document cannot demonstrate: evidence that the process works, was run, and produced a result you acted on. A submission that shows a clean SBOM and no history of getting there is a weaker artifact than one that shows the tree before, the remediation, and the tree after.

Support level and end of support belong in it too

FDA's current premarket guidance asks for more than component names and versions. It recommends recording the level of support for each component and its end-of-support date, alongside the NTIA minimum elements, in a machine-readable format.

That catches something a vulnerability scan will not. A package with no open advisories but no maintainer is a problem with a delivery date attached. It has no known vulnerabilities today because nobody is looking for them, and when one is found there will be no patch. Abandoned dependencies are a finding in their own right, and the SBOM is where that becomes visible instead of becoming a surprise in year three.

Then somebody has to own it

Everything above gets you through the gate. What happens after is the part I would push hardest on, because the failure is so predictable.

Section 524B also requires a plan to monitor and address postmarket vulnerabilities. Companies write that plan, get their clearance, and celebrate - reasonably, it is hard-won. And then the plan belongs to nobody in particular. Everyone has a reasonable assumption about where it sits, those assumptions do not match, and nobody discovers the mismatch until something forces the question.

From that moment the system entropies. The first dependency update makes the SBOM inaccurate. Six months of updates make it fiction. The next time you need something from FDA - a new submission, a change to an existing device, or a deficiency letter with a 180-day clock on it

you are not maintaining a package, you are rebuilding one from scratch, and paying that bill a second time.

The fix is a name. One person, designated in writing, whose job includes this. Not a committee and not an assumption.

I would also be honest in the plan about cadence. A full dependency analysis is not a small job, and a plan promising a deep monthly review is a plan that will be abandoned in month four and will look worse in an audit than a modest one you actually ran. Commit to what survives contact with a real release schedule: regenerate the SBOM on every build that ships, since it costs nothing there, and tie the review to events rather than the calendar. A dependency update. A component reaching end of support. A component of yours appearing in the exploited-vulnerabilities catalog. Those are the moments when looking is worth something, and a plan built around them is one somebody can actually run for years.

This is the work I do — FDA cybersecurity submissions, penetration test remediation, and security ownership for companies too small for a full-time CISO. bill@bato.com.

Common questions

Does an SBOM have to include transitive dependencies?

Yes. The NTIA minimum elements include dependency relationships, so a document listing only the components your developers chose directly does not meet them. It also fails the purpose, since the components you selected are rarely the ones carrying the vulnerabilities.

Why is the SBOM the easiest of the three 524B requirements to get wrong?

Because it is the only one that looks finished when it is not. A monitoring plan that says nothing is visibly thin. A list of software components looks like a list of software components, whether it has forty entries or a thousand, and only a vulnerability scan against it reveals which one you have.

How often should we regenerate it?

Every build that ships, because that is when it can be accurate at no marginal cost. Separately from that, tie your vulnerability review to events - a dependency update, a component going end of support, a relevant entry in the exploited-vulnerabilities catalog - rather than promising a deep monthly analysis you will not sustain.

What happens to all this after clearance?

Whatever the person who owns it makes happen. If nobody is designated, the answer is nothing. The build drifts, the SBOM goes stale on the first dependency update, and the next time you need something from FDA you repeat the entire exercise from the beginning.

FDA Section 524B: What Premarket Cybersecurity Actually Requires Responding to an FDA Cybersecurity Deficiency Letter Using AI Coding Assistants in a Regulated Codebase You Have a Penetration Test Report. Now What?

← More in Medical Device & SaMD