I had the pleasure of joining a recent webinar with FOSSA to talk about SBOMs. We covered both specific regulations relevant to the financial services industry (such as PCI DSS and DORA), along with broader guidance applicable to organizations from across different industries.
The conversation ranged from regulatory history to very practical questions about how teams can actually stand up an SBOM program without making themselves miserable in the process.
This blog is entirely based on that webinar. What follows is my way of organizing the advice I shared into four stages of SBOM management: getting started, tactical planning, implementation and rollout, and ongoing management.
Before we dive in, a quick note for those who may not be familiar with my background. I’ve spent much of my career working on software supply chain security, both inside and outside government. I previously served as a senior advisor and strategist at CISA, led foundational SBOM and vulnerability disclosure work at NTIA, and today advise a number of organizations on areas related to supply chain security and SBOM management.
Getting Started with Your SBOM Program
When organizations ask me how to begin an SBOM program, I almost always respond with a question of my own: why are you doing this?
For many teams, the honest answer is compliance. That’s not a bad thing. In fact, compliance is often what finally unlocks budget and attention for software supply chain work. But if compliance is the only reason you’re doing SBOMs, you may be taking a shortsighted view.
Maximizing the value of your SBOM program involves treating SBOMs as a way to improve how you build, maintain, and understand your software rather than solely an artifact you generate for an auditor. Modern tooling has made SBOMs far cheaper and easier than they were even a few years ago, which means this is a great opportunity to think bigger about security and quality improvements at the same time.
One mindset I strongly encourage from day one is thinking in terms of feedback loops. Your software changes constantly, and your SBOM program needs to reflect that reality. It’s much harder to bolt feedback and iteration onto a brittle process later than it is to design for it upfront. This can involve the obvious, critical (and occasionally annoying) step of bringing together a more complete set of stakeholders inside an organization to evaluate the potential impact. One hypothetical that I’ve found useful: “Imagine we have a fully operational, fully-resourced SBOM program today — what could we do with it?”
Finally, be explicit about ownership. There’s a real difference between application security teams (often inward-facing) and product security teams (often outward-facing and customer-focused). Both are important, but they optimize for different outcomes and even use different language. Again, this is another place to pull together potential views from across an organization. Deciding who owns the SBOM program — and aligning expectations early — can prevent a lot of internal friction.
Tactical Planning for Your SBOM Program
Once you move past the “we should do SBOMs” phase, planning becomes critical. This is where I see teams get distracted by the wrong early decisions.
A classic example is the debate over SBOM formats: CycloneDX versus SPDX. I’m genuinely neutral on this. Picking a format too early is like buying a car by starting with the paint color. There are more important questions to answer first.
Instead, focus your planning on:
- Scope and coverage: What do you actually need to cover first? Auditors and regulators tend to focus on specific systems or products. Start there, even if your long-term goal is broader.
- Update mechanics: My shorthand rule is simple: if your software changes, you now have a new SBOM. Whether you can actually produce that SBOM on demand depends entirely on your tools and processes.
- Depth and opacity: Top-level dependency data may meet a minimum requirement, but if you’re investing in this work, plan for deeper visibility. Identify opaque parts of your supply chain — proprietary components, legacy binaries, mystery libraries — and decide how you’ll handle them. A lot of the value for an organization kicks in with more complete programs.
- Where in the lifecycle you measure: Source, build, test, and production views can all look different. Pick an approach deliberately and plan for the metadata you’ll need. Some less mature SBOM tools won’t capture everything you care about, so you may need to factor in enrichment for licenses, hashes, identifiers, and vulnerability mappings.
Good planning isn’t about perfection. It’s about choosing constraints that make the program survivable as your software evolves.
Implementation and Initial Rollout of Your SBOM Program
During rollout, consistency matters more than finding a mythical “perfect” SBOM.
Teams are sometimes surprised when different tools or lifecycle stages produce different results. That’s normal. Security tooling is rarely deterministic. The key is not to chase an idealized answer, but to be consistent in how and where you measure so your results are comparable over time. At the same time, it’s easy to run some “sniff tests” to make sure that you’re getting what you are expecting: Does the size and complexity make sense for the software in question, or does it seem too low? Are there known transitive dependencies that you can check for?
This is also the stage where you should start capturing value beyond compliance. Wire SBOM generation into real operational workflows. For example: generate SBOMs as part of nightly builds, run them against vulnerability and threat intelligence feeds, and automatically open tickets when issues arise. At that point, SBOMs stop being static inventories and start driving decisions about patching, upgrades, and risk acceptance.
I also recommend planning early for information sharing. In government, we talk about “tear sheets” — deciding what data can be shared externally and what stays internal. Applying that concept to SBOMs helps organizations avoid accidental oversharing while still meeting customer and regulatory expectations. This is critical if you are treating your SBOM management as a single repository application metadata for internal teams, which might also include data not meant for public consumption.
Ongoing SBOM Management
Long-term SBOM success is mostly about data management, even though that’s not the most exciting part of the work.
You need to think about versioning SBOMs in ways that align with your build and release processes, storing the data you actually need, and being deliberate about what you don’t retain. You also need to consider how SBOMs or related metadata might eventually be shared with customers, auditors, or regulators; scalable sharing is still an unsolved problem in many organizations.
One capability I strongly encourage teams to adopt over time is VEX. VEX gives you a machine-readable way to say: we evaluated this vulnerability in this component, here’s our status, and here’s why. It shows that you’ve already done the work as a security-conscious organization, and have the receipts. That’s invaluable when an auditor or customer flags something in your SBOM and asks uncomfortable questions. It also fits naturally into automated workflows while still being explainable in human-friendly formats.
The Bottom Line
If there’s one thing I hope people take away from this framework, it’s that SBOMs are not about producing a document. Rather, they’re about building a repeatable, living capability for understanding your software supply chain.
The four stages I outlined — getting started, tactical planning, implementation, and ongoing management — are less a checklist and more a maturity path. Everyone is figuring this out at roughly the same time, and there are strong communities across industry and open source working through the same challenges.
If you want more detail and real-world examples, I encourage you to watch the full on-demand recording of my webinar with FOSSA. Note that the first part of the webinar is geared toward the financial services industry, while the second part includes more general SBOM guidance.
And if you’re ready to move from theory to practice, consider reaching out to FOSSA’s team for a demo of how their SBOM management tool can automate the end-to-end SBOM lifecycle.