Health-ISAC Summit Takeaways: FDA SBOM Requirements and Software Transparency in Healthcare

Attending the Health-ISAC Fall Americas Summit was a meaningful milestone for me, both professionally and personally. It was my first event representing Cybeats as an Advisor, and it immediately reinforced why software transparency and software supply chain security matter so deeply in healthcare and medical devices. The conversations throughout the summit were thoughtful, practical, and grounded in the realities of patient safety, regulatory oversight, and operational resilience.

For those unfamiliar, Health-ISAC brings together healthcare providers, medical device manufacturers, pharmaceutical companies, and security practitioners focused on strengthening cybersecurity across the healthcare ecosystem. Unlike many large security conferences, this summit felt purpose-driven. Every discussion ultimately came back to patient outcomes, trust, and the real-world impact of cyber risk. Many of the challenges discussed at the summit align closely with ongoing industry conversations around medical device security, vulnerability disclosure, and coordinated response.

One of the most enjoyable aspects of the summit was reconnecting with people I have known for years through CISA SBOM (software bill of materials) working groups and other public-private collaborations. Many of these relationships were built through long, detailed discussions about software bills of materials and vulnerability disclosures.

At the same time, I had the chance to meet many new professionals who are just beginning their SBOM journeys. These included security leaders at medical device manufacturers, hospital CISOs, and product teams grappling with how to operationalize software transparency without slowing innovation. Their questions were insightful and practical. They were not asking whether SBOMs matter. They were asking how to make them useful, scalable, and defensible.

That shift alone tells us how far the industry has come.

FDA SBOM Requirements Were Front and Center

Unsurprisingly, one of the most discussed topics at our Cybeats table was the FDA’s SBOM expectations for medical devices. Since the implementation of Section 524B of the Food, Drug, and Cosmetic Act, SBOMs are no longer optional for many regulated products. Manufacturers must now provide a software bill of materials as part of premarket submissions for certain devices, along with plans for vulnerability monitoring and coordinated disclosure.

Several hallway conversations focused on what is actually required, what reviewers are looking for, and how organizations can avoid common pitfalls. There was strong interest in aligning SBOM practices with recognized standards such as SPDX and CycloneDX, as well as leveraging automation to keep SBOMs current over time.

What stood out most was not resistance to the requirement, but uncertainty around interpretation. How complete is complete enough? How often should SBOMs be updated? How do you handle legacy products or complex supplier ecosystems? These are not theoretical questions. They are operational challenges that teams are working through right now.

The Version Number Debate and Why It Matters

One moment that sparked particularly lively discussion was when someone mentioned that their organization was hesitant to include version numbers for software components in their SBOMs. The concern was that exposing version information might reveal too much about their internal design or give competitors an advantage.

I understand where that instinct comes from, but I fundamentally disagree with the conclusion.

Version numbers are not the secret sauce. They are the minimum viable information needed to assess risk.

An SBOM without version numbers is like an ingredient list that says “legumes” instead of “peanuts.” For someone with a peanut allergy, that level of abstraction is not just unhelpful, it is dangerous. The same logic applies to software. Knowing that a product uses an open source logging library is not enough. Knowing which version is in use determines whether a known vulnerability applies, whether mitigations exist, and how urgent the response needs to be.

Without version information, security teams, regulators, and customers are left guessing. That guesswork increases risk for everyone involved.

Transparency Does Not Mean Giving Away Competitive Advantage

Another concern I heard was that SBOMs might expose proprietary components or internal architecture. This is a misconception that continues to surface, and it is worth addressing head-on.

A well-constructed SBOM does not require you to publish source code or design diagrams. It requires you to disclose the components that make up your software, including open source, third-party, and proprietary elements, along with relevant metadata such as versions and dependencies.

If you have a proprietary calculator library that includes Log4j, the SBOM should reflect that relationship. If CassieCalc depends on Log4j, then CassieCalc inherits the risk of Log4Shell. That is not a weakness in transparency. That is the reality of software composition.

Including proprietary components in SBOMs does not weaken security. It strengthens it by enabling accurate vulnerability correlation, faster incident response, and clearer communication with customers and regulators.

Transitive Dependencies Are Not Optional

Another recurring theme was the challenge of transitive dependencies. Many organizations are still focused primarily on their direct dependencies, even though the majority of software risk often resides deeper in the dependency tree.

Healthcare environments are particularly sensitive to this issue. Medical devices often have long lifecycles, complex firmware stacks, and limited patching windows. If a vulnerability exists several layers down, it can persist unnoticed for years without proper visibility.

This is why I firmly believe that SBOMs should include all known components, including transitive dependencies. Anything less creates blind spots that attackers are more than happy to exploit.

Modern tooling makes this level of visibility achievable. The challenge is not technical feasibility. It is organizational commitment and process maturity.

Why This Matters So Much in Healthcare

In many industries, a software vulnerability might lead to data loss or downtime. In healthcare, the consequences can extend to patient safety, delayed care, and loss of trust. That reality was never far from the surface at the Health-ISAC Summit.

Healthcare organizations are already balancing regulatory pressure, resource constraints, and an increasingly hostile threat landscape. SBOMs, when done well, are not an additional burden. They are a foundational capability that supports vulnerability management, incident response, and informed decision-making.

They also create a common language between manufacturers, providers, regulators, and security teams. That shared understanding is critical in moments of crisis.

A Strong Start with Cybeats

Representing Cybeats at this event made the experience even more rewarding. Cybeats’ focus on SBOM management, software supply chain security, and operational transparency aligns closely with the needs I heard expressed throughout the summit. Many conversations naturally flowed into how organizations can move from compliance-driven SBOM creation to continuous, risk-informed SBOM operations.

It was encouraging to see how receptive the community was to that message. Healthcare leaders are not looking for checkbox compliance. They are looking for solutions that help them understand risk, prioritize action, and protect patients.

Looking Ahead

The Health-ISAC Summit left me optimistic. The questions are getting sharper, the expectations clearer, and the willingness to collaborate stronger. There is still work to do, particularly around standardization, automation, and education, but the direction is right.

SBOMs are no longer a future concept in healthcare. They are here, they are required, and they are increasingly understood as a critical security control.

I am grateful for the conversations, the connections, and the opportunity to engage with this community in my new role with Cybeats. If this summit was any indication, the healthcare sector is ready to move beyond debating whether SBOMs matter and focus instead on how to do them well.

That is exactly where the real progress begins.