Software Supply Chain Security for Semiconductors and Electronics

Software supply chain security for a semiconductor or electronics company means knowing every software component that goes into the chips, modules and boards you ship, and into the tools you use to design and make them, and being able to show a customer or regulator what is in each one and how you handle its vulnerabilities. For the firmware, drivers, SDKs and host tools you build, you generate SBOMs, track vulnerabilities and fix dependencies yourself. For the software you buy (EDA tools, fab equipment software, licensed IP and vendor SDKs) you require SBOMs, advisories and patch commitments from suppliers, then track them against your own inventory.

The rules now point the same way. NIST has a draft Cybersecurity Framework profile written for semiconductor manufacturing, ISA/IEC 62443 governs the equipment on the fab floor, NIST SP 800-193 sets the bar for firmware resilience, CISA's 2026 SBOM Minimum Elements set what an SBOM should contain, and the EU Cyber Resilience Act's reporting duties have applied since 11 September 2026. This guide covers the software this industry runs, the rules and dates, public incidents from the last three years, who owns each part of the problem, and a 30/60/90-day plan that works with the tools you have today.

Key takeaways

• Semiconductor and electronics companies run four software estates: design (EDA tools, PDKs, IP cores, flow scripts), product (boot firmware, BSPs, RTOS and embedded Linux images, drivers, SDKs, companion apps), manufacturing (fab equipment software, MES, recipe and automation systems, test programs) and enterprise. Open source sits in all four, often several layers deep inside vendor SDKs.
• NIST IR 8546, the draft CSF 2.0 Semiconductor Manufacturing Profile, was published on 27 February 2025; its comment period closed on 30 July 2025. ISA/IEC 62443 parts 4-1 and 4-2 cover how equipment and component suppliers build secure products.
• NIST SP 800-193 (May 2018) frames firmware security as protection, detection and recovery. CISA's 2026 Minimum Elements for an SBOM (29 July 2026) replaced the 2021 NTIA document.
• Recent incidents include firmware flaws shared across many device makers (LogoFAIL, PKfail), an unsupported component in a chip vendor's framework, chipset flaws added to CISA's KEV catalog, and a chipmaker whose factories slowed after an IT intrusion.
• The EU Cyber Resilience Act's reporting obligations apply from 11 September 2026 and its main obligations from 11 December 2027, for hardware and software products with digital elements sold in the EU.
• Safeguard capabilities in this guide, all GA: SBOM generation and analysis, software composition analysis and vulnerability management with EPSS and KEV, Third-Party Risk Manager (TPRM), CSAF and VEX upload, policies and gates (Block, Warn, Notify), the compliance and GRC suite with IEC 62443 mapping, the Trust Center, the CLI and local runner, on-prem and air-gapped deployment with Zero AI mode, Gold Open Source, fork and patch, and autonomous remediation with Griffin fix pull requests (ships switched off, every category set to Manual).

The situation

The trigger in this industry usually arrives from a customer. A device maker asks for an SBOM and a vulnerability disclosure policy for the module you sell them, because their own EU customers now ask them the same thing. A large buyer's supplier security team sends a questionnaire on firmware signing keys and build provenance. Or a board member reads a peer's 8-K and asks how quickly you could say which product lines carry a backdoored library.

A bad week looks like this. A vulnerability lands on Monday in an open source TCP/IP stack or compression library. Corporate IT clears laptops by lunch. Nobody can answer for the products: the firmware team knows each product's SDK version but not which components the chip vendor's SDK pulled in, and two product lines run a drifted fork. Equipment engineers cannot say whether any tool controller contains it either. Customers email on Tuesday. By Friday the answer is still "under investigation". This guide is about shortening that week.

What software semiconductor and electronics companies actually run

Before rules or tools, map the software. It helps to think in four estates, because each has a different owner, a different supplier base and a different way of being fixed.

Design: EDA, PDKs, IP and flow scripts

Chip design runs on licensed electronic design automation tools for synthesis, place and route, simulation and signoff, plus open source simulators. Around them sits in-house code: Tcl and Python flow scripts, regression harnesses, compute farm schedulers, license servers and tapeout dashboards. Foundries supply process design kits (PDKs) and third parties supply IP cores. The security problem here is mainly integrity and confidentiality: who can change a flow script, which packages a regression job pulls, and whether a tool update could alter a design.

Product: firmware, SDKs, drivers and host software

This is the software you ship, and the estate customers ask about: bootloaders, UEFI or other platform firmware, secure element firmware, real-time operating systems, embedded Linux images built with Yocto or Buildroot, board support packages, drivers, wireless stacks, crypto libraries, update agents, and the reference SDKs and example code you give customers. Above that sit host tools (flashing utilities, configuration GUIs) and companion apps.

Open source is everywhere here, and often several layers deep. A module maker builds on a chip vendor's SDK, which bundles an RTOS, a TCP/IP stack, a TLS library and a file system from different upstream projects, each pinned at whatever version the SDK vendor last tested. The module maker's customer, a device maker, inherits all of it. That chain of inheritance is the core supply chain problem of the electronics industry.

Manufacturing: fab tools, MES, automation and test

A fab runs process tools (lithography, etch, deposition, metrology) whose controllers are often Windows or Linux computers maintained by the equipment maker. Around them run the manufacturing execution system, recipe management, process control and fault detection, material handling, SECS/GEM equipment communication and yield analytics. Assembly and test sites add automated test equipment and test programs; board assembly lines add pick and place, reflow and inspection systems.

Much of this software is supplied by vendors and cannot be patched by the fab without the vendor's validation, because a change can affect process qualification. That is why equipment security standards and vendor SBOMs matter so much here.

Enterprise

PLM, ERP, supplier portals, quality systems and customer download portals. The download portal is where SDKs and firmware reach customers, so its integrity is part of the product.

Where open source sits, by estate

The regulations and frameworks that apply

No single law covers software supply chain security for chips and electronics. The obligations come from a mix of voluntary frameworks that customers write into contracts, equipment standards that fabs write into purchase orders, disclosure rules for listed companies, and product rules in export markets. This section summarises the primary sources; it is not legal advice, and you should confirm how each applies to you with counsel.

NIST IR 8546: the CSF 2.0 Semiconductor Manufacturing Profile (draft)

NIST's National Cybersecurity Center of Excellence published the initial public draft of NIST IR 8546, the Cybersecurity Framework Version 2.0 Semiconductor Manufacturing Profile, on 27 February 2025. The comment period was extended to 30 July 2025 and is closed. NIST describes it as a voluntary, risk-based approach for semiconductor development and manufacturing, and notes that the environment is a complex ecosystem of device makers, equipment makers, suppliers and solution providers. As of this writing, CSRC lists the draft and not a final version, so treat it as a draft profile.

What makes it useful is that it speaks the industry's language. It rates CSF 2.0 outcomes against semiconductor business objectives, and the supply chain outcomes in the Govern function (GV.SC) carry fab specific notes. Under GV.SC-05, which asks that supply chain security requirements be established, the draft says purchasing specifications and service level agreements should be rigorously defined for fab operations, and that SBOMs give detailed transparency about software components. It also cites SEMI E187 and E188 as references. If you already report against CSF 2.0, it is the natural way to show a board or a customer how your supply chain controls fit the industry's own view of risk.

SEMI E187 and E188: fab equipment cybersecurity

SEMI, the industry association, publishes the standards fabs use to specify equipment. SEMI E187 (current edition E187-0122) is the specification for cybersecurity of fab equipment. It applies to the computing devices of fab equipment that run Windows or Linux, and sets requirements in four areas: operating system support, network security, endpoint protection and security monitoring. It does not apply to PLC and SCADA computing devices. SEMI E188 (current edition E188-0222) covers malware free equipment integration. Fabs can write both into equipment purchase orders, which turns them into supplier obligations. We have linked our existing post on what a fab should inspect first under SEMI E187 rather than repeat it here.

ISA/IEC 62443: the industrial automation series

ISA/IEC 62443 is the series for industrial automation and control systems, and fab and test floor systems fall under it. The parts that matter most here are 62443-2-4 (security program requirements for service providers, which covers integrators), 62443-3-3 (system security requirements and security levels), 62443-4-1 (secure product development lifecycle requirements for suppliers) and 62443-4-2 (technical security requirements for components). For an equipment maker or an electronics company selling industrial components, 62443-4-1 is where third-party component management lives.

NIST SP 800-193: Platform Firmware Resiliency Guidelines

Published in May 2018, SP 800-193 describes how platform firmware and its critical data should be protected from unauthorized change, how corruption should be detected, and how a platform should recover to a known good state. NIST notes that a successful attack on platform firmware could leave a system inoperable, perhaps permanently. For anyone shipping boot firmware or a root of trust, it is the reference customers' security teams reach for.

NIST SP 800-218 (SSDF) and SP 800-161 Rev. 1 (C-SCRM)

The Secure Software Development Framework sets out practices for producing software securely, including protecting code and build integrity and archiving provenance for each release. SP 800-161 Rev. 1 is NIST's guidance on cybersecurity supply chain risk management for organizations that buy and build technology. Large customers, especially federal and defense ones, often ask suppliers to attest to SSDF practices and use 800-161 to structure how they assess you.

CISA 2026 Minimum Elements for an SBOM (29 July 2026)

CISA, the NSA, the FBI and international partners released the 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026. It updates and replaces the minimum elements published by NTIA in 2021. CISA describes the SBOM as an ingredients list and a building block of supply chain risk management, and notes that some software types may need additional elements. If a customer asks for "an SBOM to minimum elements", this is now the document they mean.

CISA Secure by Demand guidance for OT buyers (13 January 2025)

CISA's guide for operational technology owners and operators lists priority considerations when selecting digital products, including asking manufacturers for a software and hardware bill of materials. Fabs and electronics assembly plants are OT buyers, so the guide gives equipment buyers a ready list of what to ask suppliers.

SEC cybersecurity disclosure rules

Since the SEC's rules announced on 26 July 2023, US listed companies disclose a material cybersecurity incident on Form 8-K Item 1.05 within four business days of determining it is material, and describe their cybersecurity risk management, strategy and governance annually. Many semiconductor companies are listed, and the 8-K is now one of the best primary sources on incidents in this industry.

EU Cyber Resilience Act, as context for exporters

The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. Its reporting obligations for actively exploited vulnerabilities and severe incidents have applied since 11 September 2026, and its main obligations apply from 11 December 2027. The Commission describes it as protecting consumers and businesses that buy hardware or software products with digital elements. Annex III lists important products and Annex IV critical products; manufacturers of important class II and critical products need third-party assessment or a European certification scheme, and Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 gives the technical descriptions of those categories. Check whether your chips, modules or boards fall into one. For a US electronics company the CRA matters mainly through EU customers and distributors, who will flow its requirements up the chain.

Export controls

Export controls on chips, tools and technology decide who may receive what, not how vulnerabilities are handled, but they shape where design data and tools may sit. Our post on fab security and export controls covers that angle.

What each source asks for, side by side

Real public incidents from the last three years

These incidents come from official or primary sources: national CERTs, CISA, NIST and the companies' own filings. We describe what the sources say and draw no conclusions about what anyone should have done.

December 2023: LogoFAIL, image parsers in UEFI firmware

On 6 December 2023 CERT/CC published vulnerability note VU#811862, describing flaws found by researchers in the image parsing libraries UEFI firmware uses to show a boot logo. A local attacker with administrative access to the boot partition or firmware flash could use a crafted image to disable Secure Boot or run unwanted code. CERT/CC notes that the UEFI supply chain integrates these shared libraries in many ways, and that major independent BIOS vendors obtained CVEs to track them for their partners and customers. One upstream codebase, many downstream products, each needing its own update.

29 March 2024: the XZ Utils backdoor (CVE-2024-3094)

CISA reported malicious code embedded in XZ Utils versions 5.6.0 and 5.6.1, a data compression library present in Linux distributions. The malicious code could allow unauthorized access to affected systems. For electronics companies the question was immediate and practical: which embedded Linux images, build hosts and tool controllers carried those versions. Companies with per-image SBOMs could answer quickly. Others had to inspect images one by one.

July 2024: PKfail, test platform keys shipped in production firmware (CVE-2024-8105)

CERT/CC vulnerability note VU#455367, made public on 25 July 2024, explains that UEFI software is built by a network of supply chain partners and independent BIOS vendors whose components are shared across many device makers, and that temporary test keys hard-coded for build and testing found their way into production firmware. An attacker holding the private part of such a platform key can sign code that runs with the highest privileges early in boot, bypassing Secure Boot. NVD published CVE-2024-8105 for the issue on 26 August 2024. Firmware supply chain risk is not only vulnerable code: it is also keys and configuration inherited from a supplier.

August 2024: a chipmaker's manufacturing runs below normal levels

Microchip Technology filed a Form 8-K on 20 August 2024. It said that on 17 August it detected suspicious activity in its IT systems, and on 19 August determined that an unauthorized party had disrupted its use of certain servers and some business operations. As a result, certain manufacturing facilities were operating at less than normal levels and its ability to fulfil orders was affected. The filing shows how an IT intrusion at a semiconductor company reaches production and customers.

August to September 2024: an unsupported component in a chip vendor's framework (CVE-2024-7490)

NVD published CVE-2024-7490 on 8 August 2024, and CERT/CC followed with vulnerability note VU#138043 on 19 September 2024. It describes a stack-based overflow in the tinydhcp server of Microchip's Advanced Software Framework (ASF) for microcontrollers that can lead to remote code execution. CERT/CC notes that the software is no longer supported by the vendor and, because it is IoT-centric code, is likely to surface in many places. The pattern is familiar to every embedded team: example code and framework components copied into products, then left behind after the framework stops being maintained. We have a post on this CVE and one on keeping a forked vendor SDK patched after the chip vendor moves on.

3 June 2025: chipset flaws added to the KEV catalog

On 3 June 2025 CISA added three Qualcomm multiple chipsets vulnerabilities to its Known Exploited Vulnerabilities catalog: CVE-2025-21479 and CVE-2025-21480 (incorrect authorization) and CVE-2025-27038 (use after free). NVD describes CVE-2025-21479 as memory corruption in the GPU micronode. Fixes for flaws like these travel from the chip vendor to every device maker, who must integrate them into its own builds and ship its own update. Our posts on CVE-2025-21479 and related entries cover the details.

What the sources show in common

Read together, the sources show shared upstream code spreading one flaw across many brands, keys riding along with code, unsupported components staying in products, and an IT incident reaching production within days. Each needs an inventory of what is inside the products and tools, not only the corporate laptops.

The personas who own the problem

Several people own parts of this problem, and each needs something different at a different moment. Naming them up front stops the work from falling between teams.

The PSIRT lead's workload changes most under the CRA, because reporting duties attach to actively exploited vulnerabilities in products already on the market. The field application engineer is asked first; give them one place to find the current SBOM and VEX for each product.

Step by step: a 30/60/90-day plan that works with or without Safeguard

The plan assumes a mid-sized chip, module or electronics company with firmware teams, a design center and either its own fab or test site or foundry partners. Each step names its output.

Days 1 to 30: know what you have

1. Name owners for each estate. One accountable owner each for product firmware and software, design environment, manufacturing systems and enterprise. Output: a one-page RACI.
2. List your products and their builds. For each product line, list the shipped firmware images and host software, the SDK and RTOS or Linux version each is built from, and whether the SDK is upstream or a fork. Output: a product to build table.
3. Generate SBOMs for the builds you control. Start with what you ship most widely, using the methods in the firmware section below. Output: one SBOM per shipped build, stored with the release.
4. Request SBOMs from your key suppliers. Chip vendors whose SDKs you ship, EDA vendors, key equipment makers and your MES vendor, to CISA's 2026 minimum elements. Output: a supplier request tracker with due dates.
5. Write down your keys and credentials inventory. Signing keys, Secure Boot keys and debug unlock credentials, with holder and storage. Output: a key inventory.
6. Pick your first watch list. The components that appear in the most products (network stacks, TLS libraries, compression, bootloaders). Output: a short list you check every new advisory against.

A simple supplier SBOM request template:

Days 31 to 60: decide how you will act

1. Set a triage rule. Decide by known exploitation (CISA KEV), likelihood (EPSS), whether the component is present and reachable, and how many products it touches. Output: a written triage rule.
2. Set release gates for software you build. For example: no known exploited vulnerabilities, no critical vulnerabilities without an approved exception, no unapproved licenses in shipped SDKs. Output: gates in CI for firmware and host software builds.
3. Decide how you will patch forked SDKs. Either rebase on the chip vendor's newer release, or backport fixes into your fork with a named maintainer. Output: an owner and a rebase or backport policy per fork.
4. Agree a patch decision process for fab tools. Agree who decides, which compensating controls apply (segmentation, removable media control, allow listing) and how risk acceptance is recorded with an expiry. Output: a decision table.
5. Write your VEX practice. When a vulnerable component is present but not exploitable, say so in a VEX statement with a justification. Output: a VEX template and an owner.
6. Prepare for EU reporting if you sell there. Map who decides that a vulnerability is actively exploited, who drafts the notification, and how you reach downstream customers. Output: a runbook.

A patch decision table for fab and test equipment:

Days 61 to 90: make it routine and show it working

1. Automate and monitor SBOMs. Generate them in CI on every release and watch them daily, because new CVEs land in old components. Output: alerts on new critical or known exploited vulnerabilities in any shipped build.
2. Publish what customers need. A customer facing place with current SBOMs, VEX statements and your disclosure policy, with access controls where needed. Output: one link field engineers can share.
3. Score suppliers. Use SBOM quality, response time to advisories and open critical issues. Output: a supplier scorecard for renewals.
4. Report. Give the board three numbers: time to answer "are we affected" for a new critical CVE, open known exploited vulnerabilities in shipped products, and percentage of key suppliers providing current SBOMs. Output: a one-page quarterly report.
5. Run a drill. Pick a past vulnerability such as the XZ Utils backdoor and time how long it takes to list every affected product, build host and tool. Output: a measured time and a fix list.

How do you build an SBOM for bare metal or RTOS firmware?

Package manager based tools see little in a firmware tree, because components arrive as vendored source. Treat the build as the source of truth: keep a manifest of every third-party component (name, version, upstream URL, license, local patches) next to the code, have the build check it against the vendored directories, and generate the SBOM from it. For embedded Linux, use the build system's own SBOM output. For binaries without source, ask the supplier for an SBOM.

How do you keep a forked vendor SDK patched?

Most teams carry a fork of a chip vendor's SDK. The risk is drift: upstream fixes a vulnerability and the fork never gets it. Give each fork an owner, track its upstream base in the SBOM, and decide explicitly to rebase or backport. When the vendor stops maintaining the SDK, you become the maintainer. Our post on keeping a forked vendor SDK patched goes into detail.

How do you secure the EDA and design environment?

Treat it as a build system. Pin flow dependencies, build farm images from a reviewed base, scan them, and restrict who can change flow scripts before tapeout. Ask EDA vendors for SBOMs and advisories, and stage tool updates. Licensed EDA binaries are the vendor's to fix; your flow code and its open source are yours.

How do you answer a customer's SBOM and CRA questions for a chip or module?

Customers want three things: an SBOM for the firmware and SDK you ship them, your position on known vulnerabilities in it (VEX), and your process for handling new ones. Prepare those once per product release rather than per request. Be clear about scope: an SBOM for the software you ship is not a hardware bill of materials, and a customer asking about silicon provenance needs a different answer. Our post on questions to ask a chip or module supplier shows the same exchange from the buyer's side.

How Safeguard does this

This section shows how the same plan runs in Safeguard, using only flows from Safeguard's documentation. Commands are shown as the docs show them; we did not run them for this post.

1. Generate SBOMs for the software you build. SBOM generation and analysis (GA) and software composition analysis with deep transitive dependency scanning (GA) cover host tools, companion apps, embedded Linux userland, design flow code and build farm containers. The Safeguard CLI (GA) signs in with an OAuth device code flow; on a machine without a browser it prints a URL and code to enter elsewhere:

   safeguard login --no-browser
   safeguard scan --dir .
   safeguard scan --image myregistry.example.com/flow-runner:3.1
   

   The image name is illustrative. Results are written as JSON under ./output.

2. Bring in SBOMs your firmware build produces, and SBOMs suppliers send. The CLI validates an SBOM against its specification and scans it locally with safeguard validate sbom.json and safeguard scan --sbom sbom.json. To monitor an SBOM over time, go to Integrations, click Connect on the Upload SBOM card, enter the project name and version, and upload the file. Safeguard validates it, enriches components with vulnerability matches, EPSS, CISA KEV status, license and supplier data, and keeps monitoring for new vulnerabilities. Vulnerability management with EPSS and KEV is GA. This is how a firmware SBOM generated from your build manifest, or a chip vendor's SDK SBOM, gets watched every day instead of once at release.

3. Request SBOMs from suppliers. Third-Party Risk Manager (TPRM, GA) turns the supplier request into a tracked workflow: navigate to the vendor, click Request SBOM, select products, choose a template, set a deadline and send. Custom templates live under Settings, Request Templates, so yours can name CISA's 2026 minimum elements. Requests move through Sent, Viewed, In Progress, Submitted, and Validated or Rejected, with reminders before and at the deadline and an escalation after it.

4. Score and monitor suppliers. TPRM scores each vendor from 0 to 100 from vulnerability risk, SBOM quality and age, component health and operational factors, and alerts you when a new critical vulnerability or a KEV listing affects a vendor SBOM, when a score drops or when an SBOM goes stale. To accept a supplier risk, click Accept Risk, give a justification, set a review date and obtain approvals.

5. Ingest supplier advisories and VEX. CSAF and VEX upload (GA) takes CSAF 2.0 advisories and VEX in CycloneDX, OpenVEX and CSAF VEX formats from the Upload CSAF/VEX card under Integrations, so a chip vendor's "not affected" statement is recorded against the right product.

6. Gate releases of firmware and host software. Policies, gates and guardrails (GA) enforce your release rules. Go to Settings, Policies, click Create Policy, define conditions with the visual builder or YAML, set severity and actions, then save and enable. Each policy's action is Block (the gate fails), Warn (the gate passes with a warning) or Notify (the gate passes and a notification is sent). Exceptions carry a justification and an expiry date, go to approvers and are recorded in an audit trail. In CI the docs show:

   safeguard ci scan --wait --fail-on-gate <gate>
   

7. Map evidence to IEC 62443. The compliance and GRC suite (GA) includes IEC 62443 and IEC 62443-4-2 mappings. The docs list SBOM checks such as component inventory, integrity hashes, known suppliers for externally provided components and unambiguous identifiers for third-party components. These show whether the SBOM carries what a clause presupposes; they do not assess your whole program.

8. Give customers one place to check your posture. The Trust Center (GA) is a public page, managed on Compliance, Trust Center, where customers and prospects see the frameworks you meet, the controls you monitor, your policies and subprocessors and the documents you share, with access requests for documents you release on approval. It gives field application engineers one link to send.

9. Scan in isolated fab and design networks. The local runner (GA) is part of the CLI and opens only outbound HTTPS connections; it scans locally and uploads only the SBOM and findings, never source code. On-prem and air-gapped deployment (GA) runs the platform inside your perimeter, with signed snapshot bundles carrying vulnerability feed updates through a DMZ. Zero AI mode (GA) runs the platform with no language model in the loop. Safeguard's own posture: designed for FedRAMP High, with SOC 2 Type II compliance.

10. Fix dependencies in software you build. Autonomous remediation (GA) uses Griffin to open tested, policy gated fix pull requests, single or in bulk. It ships switched off, with every category set to Manual. When an open source component in a forked SDK has no upstream fix, fork and patch (GA) is the route described in the block below.

11. Look up fixed versions and the industry's map. Gold Open Source (GA) at gold.safeguard.sh is free and needs no login. It gives CVE intelligence with affected and fixed versions, and it also shows a Chip Manufacturers directory that lists semiconductor companies by category (fabless designers, foundries, integrated device makers, memory, EDA and equipment makers) with headquarters and notable products. It is a reference for mapping suppliers, not vulnerability data about any part.

The plan, mapped

What Safeguard does not do

• It does not analyse silicon or hardware. Safeguard works on software components. It does not verify RTL, detect hardware trojans, test for counterfeit parts or produce a hardware bill of materials from a board.
• It does not reconstruct SBOMs from arbitrary firmware binaries. For bare metal and RTOS firmware built from vendored source, the SBOM should come from your build manifest or your supplier; Safeguard then validates, enriches and monitors it.
• It does not patch vendor products. Fab tool software, licensed EDA binaries and chip vendor firmware delivered as binaries are fixed by their makers. Safeguard tracks them through SBOMs and advisories; remediation pull requests apply to code you build.
• It does not manage your signing keys. Firmware signing keys, Secure Boot keys and debug credentials stay in your HSMs and key management processes.
• It does not decide or file regulatory reports. Whether a vulnerability is actively exploited, whether an incident is material and what you tell a regulator or customer are decisions for your people and counsel.
• It does not qualify patches for your process. Whether a tool patch can run in production after qualification is an engineering decision for the fab.

Common mistakes

• Treating the chip vendor's SDK as one component. It is dozens of components with their own versions and their own vulnerabilities.
• Forgetting forks. A fork without an owner drifts from upstream and collects every vulnerability fixed after it was taken.
• Producing an SBOM once. A release SBOM without continuous monitoring goes stale the day a new CVE is published.
• Leaving reference keys and credentials in production. PKfail showed that defaults inherited from a reference design can undermine Secure Boot.
• Asking suppliers for "an SBOM" without a spec. Name the format, the minimum elements, the frequency and the advisory format.
• Patching fab tools without a decision record. When a patch cannot be applied, the compensating controls and expiry date are the evidence.
• Answering customers ad hoc. Improvised SBOM answers are inconsistent and sometimes wrong.

FAQ

What is software supply chain security for semiconductor companies?

Managing the risk from every software component in the products you ship and in the tools used to design and make them: inventory, vulnerability tracking, supplier requirements and fixes.

Is there a NIST framework specific to semiconductor manufacturing?

Yes, in draft: NIST IR 8546, published as an initial public draft on 27 February 2025, with comments closed on 30 July 2025.

Do fab equipment makers have to provide SBOMs?

No US law requires it in general. CISA's Secure by Demand OT guidance and NIST IR 8546 point buyers toward asking, and fabs can write SBOM and SEMI E187 requirements into purchase orders.

Does the EU Cyber Resilience Act apply to chips and modules?

The CRA applies to hardware and software products with digital elements placed on the EU market, with stricter assessment for categories in Annexes III and IV. Confirm your products' classification with counsel.

How do I create an SBOM for RTOS firmware?

Keep a manifest of vendored components next to the code, check it in the build, and generate the SBOM from the manifest and the build's inputs. For embedded Linux, use the build system's SBOM output.

What did PKfail teach electronics makers?

That firmware supply chain risk includes keys and configuration inherited from reference designs, not only vulnerable code. Inventory signing and platform keys, and check none are test keys.

How should a fab handle a vulnerable tool it cannot patch?

Isolate it, restrict access, record a risk acceptance with an expiry date, track the vendor's patch commitment, and patch after qualification.

What should we tell customers who ask for an SBOM for our chip?

An SBOM for the firmware and SDK you ship, VEX for known vulnerabilities, and your handling process. A software SBOM is not a hardware bill of materials.

Can Safeguard scan our chip firmware?

For firmware built from vendored source, generate the SBOM from your build manifest and upload it; Safeguard validates, enriches and monitors it. It does not analyse silicon.

Every one of the incidents above began with a component someone else wrote. The block below describes what Safeguard does when a fix exists, and when it does not.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. It is the pattern for a design center or fab network that allows only outbound connections.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal with safeguard, and asks it to "fix the lodash CVE in this repo". The assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow applies to the JavaScript dependencies in a companion app, a configuration GUI or a customer download portal.

Click through it at your own pace, or open it full screen.

Quick check

Try it on your own software: download Safeguard at safeguard.sh/download, and read the docs at docs.safeguard.sh.

Related reading

• Semiconductor fab SBOMs for machines and firmware
• Software supply chain security for manufacturing and OT: a 90-day plan
• Hardware and firmware supply chain inventory, from chips to boards
• Counterfeit electronic parts and how an HBOM helps

Sources

• NIST: IR 8546 (Initial Public Draft), CSF 2.0 Semiconductor Manufacturing Profile
• NIST: SP 800-193, Platform Firmware Resiliency Guidelines
• NIST: SP 800-218, Secure Software Development Framework
• NIST: SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• ISA: ISA/IEC 62443 Series of Standards
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Secure by Demand, Priority Considerations for OT Owners and Operators
• SEC: Cybersecurity disclosure rules press release
• European Commission: Cyber Resilience Act
• CERT/CC: VU#811862, LogoFAIL
• CISA: XZ Utils supply chain compromise (CVE-2024-3094)
• CERT/CC: VU#455367, PKfail
• SEC: Microchip Technology Form 8-K, 20 August 2024
• CERT/CC: VU#138043, Microchip ASF tinydhcp
• NVD: CVE-2024-7490
• NVD: CVE-2024-8105
• CISA: CISA Adds Three Known Exploited Vulnerabilities to Catalog, 3 June 2025
• NIST: IR 8546 initial public draft (PDF)
• SEMI: E187, Specification for Cybersecurity of Fab Equipment
• SEMI: E188, Specification for Malware Free Equipment Integration
• European Commission: Cyber Resilience Act summary
• Gold Open Source: Chip Manufacturers
• Safeguard Docs: CLI Usage
• Safeguard Docs: Existing SBOM
• Safeguard Docs: TPRM SBOM Requests
• Safeguard Docs: TPRM Risk Assessment
• Safeguard Docs: TPRM Monitoring
• Safeguard Docs: CSAF/VEX Upload
• Safeguard Docs: Policies and Gates
• Safeguard Docs: IEC 62443
• Safeguard Docs: IEC 62443-4-2
• Safeguard Docs: Trust Center setup
• Safeguard Docs: Local Runner
• Safeguard Docs: Air-Gapped Deployment

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.