{"id":137,"date":"2026-07-09T14:12:18","date_gmt":"2026-07-09T18:12:18","guid":{"rendered":"https:\/\/blogs.mathworks.com\/digitaleng\/?p=137"},"modified":"2026-07-09T14:12:18","modified_gmt":"2026-07-09T18:12:18","slug":"from-models-to-binaries-where-the-software-bill-of-materials-fits-in-the-digital-thread","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/digitaleng\/2026\/07\/09\/from-models-to-binaries-where-the-software-bill-of-materials-fits-in-the-digital-thread\/","title":{"rendered":"From Models to Binaries: Where the Software Bill of Materials Fits in the Digital Thread"},"content":{"rendered":"<p><em><b>In brief:<\/b>\u00a0This article explains why an SBOM is more useful when it is treated as part of the engineering workflow, not only as a release-time compliance artifact. It looks at where SBOM\u00a0fits from\u00a0software architecture through binaries, how it depends on connected sources of truth, and why the surrounding digital thread\u00a0determines\u00a0whether teams can act on what the SBOM tells them.\u00a0<\/em><\/p>\n<ul>\n<li><em>why SBOM is valuable, but limited, if it appears only at the end of the workflow;\u00a0<\/em><\/li>\n<li><em>how earlier lifecycle context can make SBOM more useful for risk, change impact, verification, and release decisions;\u00a0<\/em><\/li>\n<li><em>how system architecture, models, code, tests, Git, ALM, and PLM each contribute\u00a0different sources\u00a0of truth; and\u00a0<\/em><\/li>\n<li><em>why\u00a0the key question is not simply whether a team has an SBOM, but whether the engineering workflow makes it actionable.\u00a0<\/em><\/li>\n<\/ul>\n<h2>Introduction<\/h2>\n<p>Over the past few years, I have\u00a0heard more customers ask where a software bill of materials, or SBOM, fits in an engineered system. The question came up again recently at a conference, and I do not think it is just a cybersecurity or compliance question. It is also a lifecycle question.<\/p>\n<p>At one level, the answer seems straightforward. An SBOM is a machine-readable inventory of the\u00a0software components in a release. It helps teams understand what is in a product, assess potential vulnerability exposure, and communicate software content across the supply chain.<\/p>\n<p>That is already valuable. But\u00a0most engineering teams do not struggle\u00a0to understand\u00a0the\u00a0core purpose of an SBOM.\u00a0They struggle with the next question:\u00a0<b>when does an SBOM become\u00a0truly useful\u00a0for engineered systems?<\/b><\/p>\n<p>Is it just a report produced near release time? Is it primarily a compliance artifact? Is it something security teams ask for after the software is already built? Or is it part of a broader engineering workflow that helps teams understand change, risk, and traceability throughout the lifecycle?<\/p>\n<p>It can be\u00a0all of\u00a0those things.\u00a0But treating SBOM only as an end-of-line document misses the more useful question:\u00a0<b>how can it help engineering teams make better decisions before and after release?<\/b><\/p>\n<p><img decoding=\"async\" loading=\"lazy\" class=\"alignnone wp-image-138 size-large\" src=\"http:\/\/blogs.mathworks.com\/digitaleng\/files\/2026\/07\/SBOM-Screenshot-1024x480.png\" alt=\"\" width=\"1024\" height=\"480\" \/><\/p>\n<h2 aria-level=\"2\"><\/h2>\n<h2 aria-level=\"2\"><span data-contrast=\"none\">An SBOM Is Not Most Valuable at the End<\/span><span data-ccp-props=\"{&quot;134245418&quot;:true,&quot;134245529&quot;:true,&quot;201341983&quot;:0,&quot;335559738&quot;:160,&quot;335559739&quot;:80,&quot;335559740&quot;:278}\">\u00a0<\/span><\/h2>\n<p><span data-contrast=\"auto\">If an SBOM appears only at the end of the workflow, its\u00a0usefulness\u00a0is limited. It may tell you what software components ended up in a delivered package, but it says little about how they got there, what changed between builds, or what evidence supports the result.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">Like\u00a0FMEA\u00a0and other engineering analyses, an SBOM is more valuable when it informs decisions rather than merely records outcomes.\u00a0A release-time report can satisfy a request. It does not always help a team understand what to do next.<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">If a vulnerability is\u00a0disclosed,\u00a0can you tell which product configurations, builds, or released binaries include the affected\u00a0component?\u00a0If a dependency changes, can you\u00a0determine\u00a0what needs to be rebuilt, retested, or reevaluated? If a software update is delivered into a regulated or safety-critical environment, can you trace that released binary back to the engineering artifacts, version history, and verification evidence that support it?\u00a0Those are the conditions under which an SBOM starts to become useful rather than merely present.<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">The same idea applies before\u00a0release.\u00a0Once the software architecture begins to\u00a0identify\u00a0major components, services, libraries, third-party software, generated code, and supplier-delivered elements, an early SBOM can help teams reason about risk before implementation is frozen.\u00a0It may influence\u00a0component\u00a0selection.\u00a0It may shape supplier conversations. It may help security, licensing, and compliance teams see issues earlier.<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">The SBOM will\u00a0still\u00a0evolve as the product evolves, but that is the point. It becomes part of the engineering process, not just\u00a0something\u00a0produced\u00a0at the end.<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">At the same time,\u00a0compliance\u00a0should not be\u00a0understated. For many organizations, SBOM is not\u00a0a nice-to-have. It is increasingly tied to cybersecurity expectations, software supply chain transparency, and regulatory obligations.\u00a0Producing an SBOM can be essential for\u00a0demonstrating\u00a0what is in a release, assessing exposure, and supporting downstream reporting and audit needs.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">Compliance is\u00a0not\u00a0secondary\u00a0here.\u00a0I\u00a0would argue\u00a0that\u00a0it\u00a0becomes\u00a0stronger\u00a0when the\u00a0SBOM is connected to the engineering workflow that produced the software in the first place.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<h2 aria-level=\"2\"><span data-contrast=\"none\">From Models to Binaries<\/span><span data-ccp-props=\"{&quot;134245418&quot;:true,&quot;134245529&quot;:true,&quot;201341983&quot;:0,&quot;335559738&quot;:160,&quot;335559739&quot;:80,&quot;335559740&quot;:278}\">\u00a0<\/span><\/h2>\n<p><span data-contrast=\"auto\">Engineered systems do not move\u00a0cleanly\u00a0from a requirement to a binary. They move through a chain of artifacts, decisions, transformations, and evidence.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">A system architecture defines the structure of the overall product and helps organize behavior, interfaces, and responsibilities across domains. From there,\u00a0different parts\u00a0of the system move through their own development processes.\u00a0Mechanical, electrical, electronics, and software teams may each use different tools, review cycles, and release mechanisms.\u00a0For software-intensive functions, including controls and other algorithms,\u00a0that path\u00a0continues\u00a0through executable design models, source code, build pipelines, testing workflows, and released binaries.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">Software architecture is where\u00a0that progression\u00a0starts to become concrete for the SBOM.\u00a0It turns system intent into a software structure,\u00a0identifying\u00a0components, services, interfaces, dependencies, third-party elements, generated code, and supplier contributions that may eventually appear in the SBOM.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">At that point, the SBOM is no longer only a\u00a0release\u00a0artifact. It can begin to reflect architectural intent and help teams evaluate risk, compliance, and\u00a0verification\u00a0implications before the software is packaged.<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">Most teams already have\u00a0the artifacts. The harder part is keeping the relationships meaningful as the product changes. Architecture, design, code, tests, and release outputs may all exist, but the engineering value comes from preserving the relationships between them. When the product changes, teams need to understand what\u00a0changed, what is\u00a0impacted, and what evidence still holds.<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">An SBOM becomes\u00a0most\u00a0concrete during implementation and release.\u00a0It tells you what software content is in the product as built. But its usefulness starts earlier when it can be tied back to the software architecture, models, code, dependencies, tests, and lifecycle systems that explain why those contents are there.<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<h2 aria-level=\"2\"><span data-contrast=\"none\">What Are the Authoritative Sources of Truth?<\/span><span data-ccp-props=\"{&quot;134245418&quot;:true,&quot;134245529&quot;:true,&quot;201341983&quot;:0,&quot;335559738&quot;:160,&quot;335559739&quot;:80,&quot;335559740&quot;:278}\">\u00a0<\/span><\/h2>\n<p><span data-contrast=\"auto\">One reason this topic gets messy is that an engineered system rarely has a single authoritative source of truth for everything.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">A system architecture may be authoritative for product structure, interfaces, and system-level intent. Domain-specific artifacts may then become authoritative within their own parts of the lifecycle: mechanical designs for mechanical development, electrical artifacts for electronics, and executable design models or source assets for software-intensive functions, including\u00a0controls\u00a0and other algorithms.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">Git may be authoritative for versioned source history and change tracking. ALM may be authoritative for requirements, work items, defects, and\u00a0software workflow\u00a0execution. PLM may be authoritative for product configuration, release structure, and lifecycle state across the broader\u00a0hardware-software\u00a0product.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">That distribution is normal\u00a0in a complex engineered system.\u00a0Different teams own\u00a0different parts\u00a0of the product definition because they are doing different\u00a0work.<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">The system architecture sets intent and organizes the product at\u00a0a high level. The different engineering domains then carry that intent through their own development processes. Later, those domain outputs\u00a0have to\u00a0be brought back together through integration, verification, configuration, release, and sustainment.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">I think this\u00a0is the key point: the\u00a0question is not which source of truth should replace\u00a0the others.\u00a0The\u00a0question\u00a0is\u00a0<\/span><b><span data-contrast=\"auto\">how those sources of truth stay connected well enough to support engineering decisions across the lifecycle.<\/span><\/b><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">That is where the digital thread earns its value. It connects authoritative artifacts without pretending they all collapse into one tool or one repository.\u00a0Just as importantly, it connects the right versions of those artifacts,\u00a0helping\u00a0teams understand a coherent product configuration at a given point in the lifecycle.\u00a0It helps teams move from local truth within a discipline to lifecycle understanding across the product.<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<h2 aria-level=\"2\"><span data-contrast=\"none\">The Role of Git, ALM, and PLM<\/span><span data-ccp-props=\"{&quot;134245418&quot;:true,&quot;134245529&quot;:true,&quot;201341983&quot;:0,&quot;335559738&quot;:160,&quot;335559739&quot;:80,&quot;335559740&quot;:278}\">\u00a0<\/span><\/h2>\n<p><span data-contrast=\"auto\">It helps to be explicit\u00a0about\u00a0Git, ALM, PLM\u00a0because these terms often get blurred together.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">Git plays a critical role in versioned engineering assets, source history, branching, baselines, and collaborative software development.\u00a0But Git is\u00a0not\u00a0PLM, and it\u00a0is\u00a0not\u00a0meant to\u00a0manage the\u00a0full product\u00a0lifecycle.<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">ALM sits closer to software execution. It\u00a0manages\u00a0requirements, work items, defects, traceability, and software delivery processes.\u00a0It\u00a0is related to PLM,\u00a0but\u00a0it serves\u00a0a\u00a0different purpose.<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">PLM\u00a0remains\u00a0important because product development does not stop at source code. Teams still need configuration control, release structure, lifecycle status, and coordination across hardware, software, manufacturing, and sustainment.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">An SBOM does not replace any of these systems. It\u00a0benefits from\u00a0them.\u00a0When an SBOM is generated in isolation, it can become a static inventory. When it is connected to Git history, ALM workflows, PLM context, model dependencies, and release processes, it becomes much more actionable.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">It starts to answer not only\u00a0<\/span><b><span data-contrast=\"auto\">what is in the software<\/span><\/b><span data-contrast=\"auto\">, but also\u00a0<\/span><b><span data-contrast=\"auto\">where it came from, what changed, what it affects, and what evidence supports it.<\/span><\/b><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">That is also why compliance should not be\u00a0treated as separate\u00a0from engineering flow. In regulated environments, the quality of a compliance artifact is shaped by the quality of the lifecycle thread behind it. A stronger connection between engineering artifacts, change processes, and release evidence supports better compliance outcomes, not\u00a0just better\u00a0engineering efficiency.<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<h2 aria-level=\"2\"><span data-contrast=\"none\">More Than a Checkpoint on a List<\/span><span data-ccp-props=\"{&quot;134245418&quot;:true,&quot;134245529&quot;:true,&quot;201341983&quot;:0,&quot;335559738&quot;:160,&quot;335559739&quot;:80,&quot;335559740&quot;:278}\">\u00a0<\/span><\/h2>\n<p><span data-contrast=\"auto\">It\u00a0is worth being careful\u00a0here.\u00a0SBOM\u00a0should not\u00a0be\u00a0reduced\u00a0to a compliance checkpoint, even while recognizing that compliance is a major reason it matters.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">Some teams need an SBOM to satisfy customer requirements. Others need it for software supply chain governance, cybersecurity review, or regulatory expectations around software content and dependencies.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">But an SBOM becomes more useful when it also supports engineering decisions. It helps teams understand whether a released binary includes a vulnerable dependency, what changed between builds, how software content should be communicated across suppliers and product teams, and how release artifacts connect back to lifecycle context.<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">In stronger workflows, it can do even more. It can help teams connect software content to change impact, verification scope, and release confidence. It can\u00a0help\u00a0identify\u00a0stale artifacts,\u00a0impacted\u00a0tests, and downstream consequences of modification.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">That is\u00a0a very different\u00a0role from \u201cgenerate a file and archive it.\u201d<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<h2 aria-level=\"2\"><span data-contrast=\"none\">Where SBOM Fits in the Digital Thread<\/span><span data-ccp-props=\"{&quot;134245418&quot;:true,&quot;134245529&quot;:true,&quot;201341983&quot;:0,&quot;335559738&quot;:160,&quot;335559739&quot;:80,&quot;335559740&quot;:278}\">\u00a0<\/span><\/h2>\n<p><b><span data-contrast=\"auto\">So where does SBOM fit?<\/span><\/b><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">It becomes most visible near release and deployment, but its\u00a0usefulness\u00a0depends on the upstream context that explains it. It is not the digital thread itself. It is one artifact within that thread.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">In a strong workflow, the thread connects system intent, domain development artifacts, software assets, dependencies, tests, and release outputs. An SBOM then becomes a useful expression of what software content\u00a0made it\u00a0into the product at a given point in time.\u00a0<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">If the surrounding thread is weak, the SBOM is harder to trust, interpret, and act on. If the surrounding thread is strong, the SBOM\u00a0becomes a way to navigate back to the engineering decisions and evidence behind the release.<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">So\u00a0the better question is not \u201c<\/span><b><span data-contrast=\"auto\">Do we have an SBOM?<\/span><\/b><span data-contrast=\"auto\">\u201d<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">It is \u201c<\/span><b><span data-contrast=\"auto\">Can our engineering workflow make the SBOM actionable?<\/span><\/b><span data-contrast=\"auto\">\u201d<\/span><span data-ccp-props=\"{}\">\u00a0<\/span><\/p>\n<p><span data-contrast=\"auto\">An SBOM is not most valuable when it simply exists. It becomes valuable when it stays connected to the engineering artifacts, lifecycle systems, and verification evidence that\u00a0explain\u00a0what is in the product, why it is there, and what has changed. That is where SBOM fits in the digital thread.<\/span><span data-ccp-props=\"{&quot;201341983&quot;:0,&quot;335559740&quot;:278}\">\u00a0<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<div class=\"overview-image\"><img src=\"https:\/\/blogs.mathworks.com\/digitaleng\/files\/2026\/07\/SBOM-Screenshot.png\" class=\"img-responsive attachment-post-thumbnail size-post-thumbnail wp-post-image\" alt=\"\" decoding=\"async\" loading=\"lazy\" \/><\/div>\n<p>In brief:\u00a0This article explains why an SBOM is more useful when it is treated as part of the engineering workflow, not only as a release-time compliance artifact. It looks at where SBOM\u00a0fits&#8230; <a class=\"read-more\" href=\"https:\/\/blogs.mathworks.com\/digitaleng\/2026\/07\/09\/from-models-to-binaries-where-the-software-bill-of-materials-fits-in-the-digital-thread\/\">read more >><\/a><\/p>\n","protected":false},"author":240,"featured_media":138,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/blogs.mathworks.com\/digitaleng\/wp-json\/wp\/v2\/posts\/137"}],"collection":[{"href":"https:\/\/blogs.mathworks.com\/digitaleng\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.mathworks.com\/digitaleng\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.mathworks.com\/digitaleng\/wp-json\/wp\/v2\/users\/240"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.mathworks.com\/digitaleng\/wp-json\/wp\/v2\/comments?post=137"}],"version-history":[{"count":13,"href":"https:\/\/blogs.mathworks.com\/digitaleng\/wp-json\/wp\/v2\/posts\/137\/revisions"}],"predecessor-version":[{"id":152,"href":"https:\/\/blogs.mathworks.com\/digitaleng\/wp-json\/wp\/v2\/posts\/137\/revisions\/152"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.mathworks.com\/digitaleng\/wp-json\/wp\/v2\/media\/138"}],"wp:attachment":[{"href":"https:\/\/blogs.mathworks.com\/digitaleng\/wp-json\/wp\/v2\/media?parent=137"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.mathworks.com\/digitaleng\/wp-json\/wp\/v2\/categories?post=137"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.mathworks.com\/digitaleng\/wp-json\/wp\/v2\/tags?post=137"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}