Chiplet Race Meets the CRA Stopwatch: Why Software Supply Chain Visibility Just Got Serious

The Chiplet Race Has a Software Problem

The semiconductor industry is in the middle of a chiplet race, and it looks suspiciously like the industry looked at Moore’s Law, shrugged, and said: “What if we stacked more things together and called it progress?” That is a fair summary, though perhaps not one you will hear at a board meeting.

Chiplets are not just a packaging trend. They are a response to the cost and complexity of scaling monolithic designs onto ever-more-expensive advanced nodes. The IEEE article on semiconductor packaging notes that advanced-node scaling is expensive and that packaging technology is key to improving the performance of IT equipment. IBM and Rapidus also announced an expansion of collaboration on chiplet packaging technology for 2nm-generation semiconductors, which is a pretty clear signal that chiplet packaging is becoming part of the mainstream semiconductor roadmap. IEEE source IBM source

But here is the inconvenient part: a chiplet-based product is not merely a piece of silicon. It is a stack. It can include compute dies, I/O dies, firmware, microcode, boot software, drivers, management software, host tooling, package-level calibration data, and the software that connects all of it to the outside world. In other words, the chiplet race is also a software supply chain race.

That matters because software supply chain visibility is no longer a nice-to-have artifact for license auditors and security teams who enjoy long weekends less than everyone else. The EU Cyber Resilience Act, or CRA, is pushing the industry toward a world where visibility has a clock attached to it. According to The Next Web, manufacturers of products with digital elements sold in the European Union face a September 11 deadline under the CRA to notify regulators within 24 hours after learning that a vulnerability is being actively exploited. The Next Web source

The chiplet race used to be about who could stack the most silicon. Now it is about who can answer, before the regulators start tapping the clock: “What shipped, what is vulnerable, who owns the patch, and when did we know?”

Why Chiplets Multiply the Visibility Problem

A monolithic chip is already complicated. A chiplet-based product is complicated in a different way: it distributes complexity across multiple dies, multiple vendors, multiple firmware layers, multiple package processes, and multiple software dependencies. That can be excellent engineering. It can also be a supply chain firework display if nobody has a clear map of what is inside the box.

Consider the layers involved in a modern chiplet product:

• silicon dies with different functions and potentially different owners
• package-level firmware or calibration data
• boot chain and secure boot components
• microcode and device firmware
• host drivers that talk to the hardware
• management agents for monitoring, configuration, and diagnostics
• cloud or on-prem software that consumes hardware telemetry
• build toolchains, containers, scripts, and release pipelines
• license and dependency data for both hardware-adjacent software and embedded software

That is a lot of things that can contain code, and code can contain vulnerabilities. Even if the chiplet itself is not “software” in the traditional sense, the product around it almost certainly is. And if a vulnerability appears in one layer, the impact may depend on another layer. A firmware fix may require a driver update. A driver update may require a kernel change. A kernel change may require a new container image. A container image may require a new release pipeline. Congratulations, you have discovered the software supply chain. It was there all along, wearing a tiny hard hat.

This is where chiplet architecture changes the game. In a monolithic product, a vendor may be able to point to a relatively contained hardware and software release. In a chiplet product, the final product may be a composite of many components, each with its own lifecycle, patch path, and dependency graph. The more chiplets involved, the more important it becomes to know not only what code exists, but where it runs, how it communicates, and which product variants contain it.

The CRA Turns Visibility Into a Stopwatch

The Cyber Resilience Act is important here because it changes the incentives. Before, software supply chain visibility was often treated as a defensive practice: useful for license compliance, vulnerability detection, incident response, and general “please don’t explode later” governance. Under the CRA, that visibility becomes operationally urgent.

The source from The Next Web describes a September 11 deadline under the CRA for manufacturers of products with digital elements sold in the EU to notify regulators within 24 hours after learning that a vulnerability is actively being exploited. That is a very different world from “we will patch it when we get around to it.” The 24-hour window does not mean the vendor must magically fix every issue in 24 hours. It means the vendor must be able to recognize, triage, and report the relevant situation within a very tight window.

That has enormous implications for software supply chain visibility. If a vendor cannot quickly answer the following questions, the clock becomes a problem:

• Which products contain the vulnerable component?
• Which customers or regions are affected?
• Is the vulnerability active, theoretical, or already exploited?
• Which team owns the affected component?
• Can the vendor produce evidence of when it became aware?
• Can the vendor coordinate a fix across firmware, drivers, and host software?
• Can the vendor explain the risk clearly enough for regulators and customers?

This is why SBOMs matter. A Software Bill of Materials is not just a spreadsheet with extra steps. It is a machine-readable inventory of the software components inside a product. Percona’s blog on SBOMs for Percona Server for MongoDB explains that SBOMs offer end users enhanced supply chain visibility and facilitate license compliance and timely vulnerability detection. Percona source

For chiplet products, the same principle applies, but the inventory must be broader. You are not only asking, “Which npm packages are in the application?” You are asking, “Which firmware, drivers, boot components, management agents, and host software are part of the product that shipped?” That is the difference between a tidy SBOM and a supply chain map with actual mileage.

SBOMs Are the First Layer, Not the Whole House

An SBOM is a powerful starting point because it gives you a structured view of what is inside a product. Percona’s example with Percona Server for MongoDB shows how database products can provide SBOMs to improve visibility for end users. That is useful. Very useful. But a chiplet-aware supply chain strategy needs to go further.

A traditional SBOM might list application libraries, package versions, licenses, and dependencies. A chiplet-aware SBOM needs to connect those software components to the hardware and firmware layers around them. Otherwise, you may know that your product contains a vulnerable library, but not whether that library is running on the host, embedded in a management agent, used by a diagnostic tool, or completely irrelevant to the affected hardware path.

For chiplet products, the SBOM should ideally answer several questions:

1. Identity: What component is present?
2. Version: Which exact version, build, or revision is present?
3. Supplier: Who provided or maintained it?
4. Location: Is it in firmware, driver, host software, package tooling, or cloud service?
5. Relationship: Is it direct, indirect, optional, runtime, build-time, or diagnostic?
6. Product mapping: Which SKUs, revisions, and customer deployments contain it?
7. Vulnerability context: Is there a known issue, and is it actively exploited?
8. Patch path: Who can update it, and what downstream components depend on it?

This is where the CRA becomes more than a compliance story. It becomes an engineering discipline story. If the 24-hour reporting window is real, then the organization needs an automated path from vulnerability signal to product impact to regulatory response. Manual spreadsheets are not enough. The moment someone says “actively exploited,” the organization needs to know which products are affected without spending six hours asking three teams whether they “probably” use the component in question.

And yes, this is exactly why people who once thought SBOMs were boring are now discovering that boring documents can become mission-critical infrastructure. The spreadsheet of shame has been promoted to control plane.

What a Chiplet-Aware SBOM Looks Like

A chiplet-aware SBOM does not need to be mystical. It needs to be precise. The goal is to connect software components to the product architecture in a way that allows rapid vulnerability matching and patch coordination.

Product: AI accelerator appliance
package: chiplet-based accelerator board
die: compute tile
firmware: microcode 1.4.2
calibration data: package-specific revision 7
die: I/O tile
firmware: I/O controller 2.1.0
host software:
driver: kernel module 3.1.4
management agent: telemetry daemon 1.9.0
user-space library: inference runtime 5.2.1
build pipeline:
container image: build-runner 2024.06
package manifest: signed release manifest
vulnerability context:
CVE: candidate match
status: triage pending
affected products: SKU-A, SKU-B
patch path: firmware + driver + agent

This is the kind of mapping that becomes valuable when the CRA stopwatch starts running. If a vulnerability appears in the management agent, the SBOM tells you which products contain it. If the vulnerability is in firmware, the SBOM tells you which chiplet packages and revisions are exposed. If the fix requires both firmware and driver updates, the SBOM shows the dependency path so the vendor can coordinate a safe release.

The important shift is from “component inventory” to “product impact inventory.” A basic SBOM says what is present. A chiplet-aware SBOM says where it is, how it is used, and what happens if it breaks. That is the difference between a library list and a fire drill map.

For vendors, this means the SBOM should be generated from the same release pipeline that builds the product. If the release process can produce a signed image, it should also be able to produce a signed SBOM that describes the image. If the product has multiple SKUs, the SBOM should support variant-level mapping. If the product includes firmware, drivers, and host software, the SBOM should link those layers together.

This is also where provenance matters. A component name and version are useful, but provenance answers the harder question: where did this component come from, who built it, and can you trust the artifact? In a chiplet ecosystem with many suppliers and packaging partners, provenance is not a luxury. It is the difference between “we think this is our build” and “we can prove this is the build we shipped.”

The 24-Hour Workflow: From Signal to Regulator

The CRA’s 24-hour reporting expectation changes the shape of the incident response process. The organization needs a workflow that can move from vulnerability signal to report without turning into a committee-shaped swamp.

Here is the practical pipeline:

vulnerability signal
-> intake and normalization
-> SBOM lookup
-> product impact mapping
-> exploitability triage
-> ownership confirmation
-> regulator report preparation
-> customer and partner coordination
-> patch or mitigation plan
-> evidence retention
-> post-incident review

The first step is intake. The signal may come from a researcher, a customer, a vulnerability database, a supplier notice, or internal telemetry. The important thing is that the organization needs a defined path for receiving and normalizing that signal. If every vulnerability report lands in someone’s inbox and then slowly evaporates, the CRA is going to feel much less theoretical.

The second step is SBOM lookup. The vulnerability identifier, component name, version, and package context must be matched against the SBOM. For chiplet products, this lookup must include firmware, drivers, management agents, and host software, not just application libraries. If the vulnerable component is present in only one SKU or one package revision, the SBOM should make that clear.

The third step is product impact mapping. This is where the SBOM becomes a product map. The organization needs to know which customers, regions, deployments, and hardware revisions are affected. In chiplet products, this may require linking the SBOM to a product bill of materials, a firmware manifest, and a release record.

The fourth step is exploitability triage. The CRA source specifically refers to actively exploited vulnerabilities. That means the organization needs to determine whether the vulnerability is merely known, merely theoretically exploitable, or actually being exploited in the wild. This is not always easy, but it is exactly why visibility matters. If the organization has poor component data, it cannot triage quickly.

The fifth step is ownership confirmation. In a chiplet ecosystem, ownership may be distributed. One team may own the firmware, another the driver, another the host agent, and another the release process. The organization needs to know who can make decisions quickly. If nobody knows who owns the patch, the 24-hour clock is already on life support.

The sixth step is report preparation. The report does not need to be a novel, but it does need to be accurate, timely, and actionable. The organization should be able to explain what happened, which products are affected, what is known, what is still being investigated, and what mitigation or remediation is being performed.

The seventh step is patch or mitigation planning. The CRA reporting window is not the same as the patch window, but customers still need a path to safety. In chiplet products, the patch may involve firmware, drivers, management agents, and host software. If those pieces are not coordinated, the vendor may technically report on time and still leave customers exposed.

The eighth step is evidence retention. This is the boring part that saves people from being very, very sorry later. The organization should retain the vulnerability signal, the time it was received, the SBOM version used for matching, the product impact analysis, the decision log, the regulator report, and the remediation evidence.

This workflow is where software supply chain visibility becomes operational. It is not enough to have an SBOM sitting in a repository like a decorative plant. The SBOM must be connected to vulnerability management, release management, incident response, and regulatory reporting.

The Tooling Stack: From SBOM to Supply Chain Control Plane

To make this work, vendors need a tooling stack that can connect several domains that have historically lived in separate silos. The chiplet race makes those silos more expensive to maintain, because the product boundary is no longer just “application code.” It includes hardware-adjacent software, firmware, drivers, and package-level dependencies.

A practical stack might include:

• component registry for normalized software and firmware identities
• SBOM ingestion for SPDX, CycloneDX, or internal manifests
• vulnerability intelligence for CVEs, supplier advisories, and exploit signals
• dependency graph for direct and indirect relationships
• product bill of materials for SKU, revision, and package mapping
• provenance and attestation for build and release evidence
• ticketing and incident management for ownership and escalation
• reporting templates for regulator-ready vulnerability notices
• patch orchestration for firmware, driver, agent, and host software releases

The key is automation. Manual matching between a vulnerability report and an SBOM is too slow when the CRA clock is running. The organization needs to know, almost immediately, whether the vulnerable component is present in any shipped product. That requires automated ingestion, normalization, and matching.

For chiplet products, the tooling also needs to understand relationships. A vulnerability in a driver may not matter if the relevant firmware is absent. A firmware vulnerability may matter only for certain package revisions. A management agent vulnerability may affect only customers using remote diagnostics. Without relationship data, the vendor either over-reports or under-reports, and both outcomes are unpleasant.

This is also where vendor contracts matter. If a chiplet supplier provides firmware or package-level software, the primary vendor needs contractual rights to receive SBOMs, vulnerability notices, patch timelines, and provenance data. Otherwise, the primary vendor may be left trying to answer CRA questions with incomplete information. That is a very expensive way to discover that “we thought they owned that layer” is not a regulatory strategy.

Where SBOMs Fall Short

It is important not to turn SBOMs into magic spells. An SBOM is a powerful visibility tool, but it is not a complete security solution. Percona’s discussion of SBOMs highlights their value for supply chain visibility, license compliance, and vulnerability detection. That is true. But the SBOM is still an inventory. It does not automatically tell you exploitability, impact, patch readiness, or regulatory posture.

For chiplet products, several limitations become more visible:

• Inventory is not exploitability: Knowing a component exists does not mean it is vulnerable or reachable.
• Version strings can be ambiguous: Two builds may share a label but differ in patch level.
• Proprietary firmware may be opaque: Some components may not be fully visible to the final product vendor.
• Interactions matter: A vulnerability may arise from how layers communicate, not from one isolated component.
• SKU variation matters: Different product revisions may contain different chiplets, firmware, or drivers.
• Patch coordination matters: A fix in one layer may require updates in others.
• Legal timing matters: The CRA reporting window requires fast decisions, not just good data.

This is why the right mindset is not “we have an SBOM, therefore we are compliant.” The right mindset is “we have an SBOM, therefore we have a faster path to accurate decisions.” That is a much healthier mental model and slightly less likely to produce a post-incident memo titled “How We Learned This the Hard Way.”

Conclusion: The Race Is Now About Traceability

The chiplet race is reshaping semiconductor strategy, but it is also reshaping software supply chain strategy. As products move toward chiplet-based designs, the number of software layers, suppliers, dependencies, and patch paths increases. That makes visibility more valuable and more urgent.

The CRA adds the regulatory stopwatch. According to The Next Web, manufacturers of products with digital elements sold in the European Union face a September 11 deadline to notify regulators within 24 hours after learning that a vulnerability is actively being exploited. That changes the meaning of SBOMs. They are no longer just inventory artifacts for license teams and security researchers. They become part of the operational machinery needed to detect, map, report, and remediate vulnerabilities quickly.

The winners will be the vendors that can answer five questions fast:

1. What did we ship?
2. What software and firmware are inside it?
3. Which products are affected by a vulnerability?
4. Who can patch it?
5. When did we know, and what did we do next?

That is the real connection between chiplets and the CRA. Chiplets multiply complexity. The CRA demands speed. SBOMs provide the visibility layer that makes both possible. Without that visibility, the chiplet race becomes a race toward confusion. With it, vendors can move from reactive patching to controlled, evidence-based response.

So yes, chiplets are changing hardware. But they are also changing software supply chain visibility in a very practical way. The future belongs not to the company with the most chiplets, but to the company that can prove what is inside them, what runs on them, and how quickly it can respond when the CRA stopwatch starts ticking. And that, dear reader, is the kind of technical debt that even a chiplet cannot package away.