Software Supply Chain Security Best Practices for Device Manufacturers

Two thirds of the attacks that hit software supply chains last year were not vulnerable components at all. They were packages built to be malicious, published under names that looked legitimate, and pulled in by a build system doing exactly what it was told.

Black Duck's 2026 Open Source Security and Risk Analysis report, based on audits of 947 commercial codebases, found that 65% of organizations experienced a software supply chain attack in the preceding year. Of those attacks, 66% involved packages created specifically to harm users through tactics like typosquatting and social engineering. The remaining 34% were legitimate packages that had been hijacked.

That split matters because it breaks the tool most teams rely on. Scanners built to match component versions against CVE databases find known-vulnerable code. A malicious package has no CVE when it lands in your build, and by the time one is assigned, it has shipped.

For connected device manufacturers the exposure runs longer than it does anywhere else. Your products stay in the field for a decade. Your update mechanisms are constrained. Your components arrive as binaries from chipset vendors and board support package suppliers who will not hand over source. These software supply chain security best practices are written for that situation, not for a repository.

What Is the Software Supply Chain, and Where Does It Break?

The software supply chain is every step, tool, and party that touches your code between a developer writing it and a customer powering on the device. It includes your repositories, your build infrastructure, your dependency tree, your suppliers, and the update channel you use after shipping.

It breaks in four places.

• Dependency compromise. An attacker publishes a malicious package or takes over a legitimate one. This is now the dominant category, and the 2025 npm wave, including the self-replicating Shai-Hulud worm, is the reference case.
• Source injection. An attacker reaches your repository through stolen developer credentials and commits code that survives multiple releases.
• Build process manipulation. An attacker modifies build scripts or compromises a build server, and devices ship with compromised firmware that no source review would catch.
• Third-party component exposure. A supplier ships you a component with a known flaw, or with an undeclared dependency you never inventoried.

Verizon's 2026 Data Breach Investigations Report, covering more than 31,000 incidents across 145 countries, found that breaches involving third parties rose 60% year over year and now account for 48% of all breaches. The same report recorded vulnerability exploitation overtaking stolen credentials as the leading initial access vector for the first time in the report's 19 editions.

Long product lifecycles turn each of these from an incident into a decade of exposure.

1. Build the Inventory From What Shipped, Not What the Build Declared

An SBOM is a formal record of the components and supply chain relationships inside a software product. It is the artifact every other practice on this list depends on, and most teams generate it from the wrong source.

Your build manifest documents what you intended to include. The binary contains what actually shipped. These records disagree more often than teams expect, and the disagreements cluster exactly where the risk is: a contract manufacturer swapping a library version, a supplier image carrying an undeclared dependency, a component arriving statically linked inside a vendor blob.

A usable SBOM needs to be:

• Generated from the shipped artifact, so it reflects the firmware image rather than the build intent
• Automatically regenerated on every release, not assembled by hand before an audit
• Complete through transitive dependencies, since the components nobody chose are the ones nobody reviewed
• Populated with lifecycle data, including maintenance status and end-of-support dates per component

That last point is where most SBOMs fail an assessor. Black Duck found that 92% of audited codebases contained components four or more years out of date, and 93% contained components with no development activity for at least two years. An inventory that lists a component without telling you whether anyone still maintains it is not a risk artifact.

Generate and maintain SBOMs from firmware with Finite State. See the SBOM Management data sheet.

2. Pin Dependencies and Lock Versions

Version pinning limits your build to a specific version you previously verified, so a compromised release upstream does not enter the next build automatically.

Lockfiles handle this in package-managed ecosystems. Embedded C and C++ have no standard package manager, which is precisely why this discipline gets skipped in firmware. Components arrive as vendored trees, copied directories, and supplier blobs, and a pin is only as good as your ability to detect when something arrived outside the pinned path.

Pin by digest where the ecosystem supports it. Where it does not, the compensating control is verifying the shipped image against the inventory you expected.

3. Verify Provenance and Sign Your Artifacts

Provenance is verifiable information about where, when, and how an artifact was produced. Signing binds that artifact to the identity that produced it.

Together they create a verification layer that survives credential theft. A stolen developer credential alone is not enough to introduce an unverified artifact into the pipeline, because the signature and the provenance attestation are checked independently of whoever triggered the build.

Three things to put in place:

• Generate provenance on the build platform, not on a developer workstation, so it is difficult to forge
• Separate signing authority from developer credentials, granting signing permissions only to pipeline roles
• Verify signatures at deployment, so an unsigned artifact cannot reach a device

SLSA provides the maturity model for this, and its provenance specification is the reference most tooling now targets.

4. Screen for Malicious Packages, Not Just Vulnerable Ones

This is the practice that separates a 2026 program from a 2023 one.

A vulnerable package is legitimate code with a flaw someone found and catalogued. A malicious package is code an attacker wrote to reach you. The first has a CVE, a CVSS score, and a patch. The second has none of those when it arrives, which means every control keyed to CVE matching is blind to it for the days or weeks before an identifier is assigned.

Two variants deserve naming.

Typosquatting publishes a package under a name close enough to a real one that a developer, or a code assistant, pulls it in without checking. Sleeper packages ship benign and activate later on a delay or trigger, so static analysis at install time finds nothing wrong because at that moment nothing is wrong.

Detecting either requires behavioral analysis and shared intelligence rather than signature matching. Practical steps:

• Route dependencies through a private artifact repository with an approved upstream list, which blocks typosquatted names at the repository boundary instead of relying on developers to spot them
• Monitor malicious package feeds, including the OpenSSF Malicious Packages repository, alongside your CVE sources
• Scan the final build binary, since a package that activates after install is visible in what shipped even when it was invisible at fetch time

5. Vet and Monitor Third-Party and Open Source Components

Open source appears in 98% of commercial codebases. Black Duck recorded a 30% year-over-year increase in components per codebase and a 107% increase in mean vulnerabilities per codebase, from 280 to 581.

Evaluate before adoption:

• Check maintenance signals. Release cadence, contributor count, and how quickly past vulnerabilities were fixed.
• Check the release status. A component pinned to an alpha or a fork is a maintenance liability regardless of its security record.
• Check the license. License obligations and security obligations ride on the same inventory, and our guide to open source license types covers what you inherited when you shipped.

For components you cannot evaluate because they arrived as binaries, the evaluation has to happen against the binary. This is where application security SCA tools struggle on firmware: they were built to read repositories, and a device is not a repository.

6. Prioritize by Reachability, Not by Finding Count

A scan that returns 581 vulnerabilities has not told you what to fix. It has told you that you need a prioritization method.

Verizon's 2026 report found that only 26% of critical vulnerabilities were fully remediated in 2025, down from 38% the year before. The remediation gap is widening because finding volume is growing faster than engineering capacity, and no amount of scanning closes that.

Prioritization that holds up to scrutiny asks three questions in order. Is the vulnerable code actually present in the shipped image? Is it reachable from an entry point? Is there evidence of exploitation in the wild? A finding that fails the first test is not a deferred fix. It is not a finding.

That ordering also produces the artifact an assessor wants, which is a documented, reproducible reason why you patched one thing and deferred another.

7. Secure the Build and Deployment Pipeline

A compromise in the build environment injects code into every device that ships, with no trace in source control.

• Enforce least privilege with role-based access control and multi-factor authentication across development infrastructure.
• Use short-lived credentials. Long-lived tokens sitting in CI configuration are what malicious packages scan for first.
• Store secrets in a dedicated secrets manager, never in the codebase or build scripts.
• Run ephemeral, isolated builds in environments destroyed immediately afterward, so cache poisoning has nothing to persist in.
• Implement reproducible builds, so identical inputs produce identical outputs and tampering becomes detectable.
• Keep pipeline configuration in version control, which brings review and merge policy to the files that control what gets built.

8. Shift Security Left Without Shifting the Blind Spot

Running scans earlier helps. It does not help with the part of your image you did not compile.

Static and dynamic analysis on first-party code catches issues while they are cheap to fix, and shift-left testing is worth doing on its own merits. Automate SBOM generation and policy enforcement inside the pipeline so the checks run without anyone remembering to run them.

The limit is structural. Shifting left operates on code your developers write. On a connected device, the majority of the attack surface arrived from somewhere else, in a form your static analyzer cannot read. Pair the left shift with analysis of the final image, or you have moved the flashlight without widening the beam.

9. Monitor Production and Build a Reporting Capability You Can Trigger

Devices in the field need monitoring for behavior that indicates exploitation, and a product security incident response plan that names who acts.

The requirement changed in September 2026. Under Article 14 of the EU Cyber Resilience Act, manufacturers of products with digital elements placed on the EU market must report actively exploited vulnerabilities and severe incidents through the CRA Single Reporting Platform, to their coordinating CSIRT and ENISA. An early warning is due within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure becoming available for an actively exploited vulnerability, or within one month of the 72 hour notification for a severe incident.

Two points get missed.

First, Article 14 applies to products already on the market. Article 69(2) exempts products placed before December 11, 2027 from full CRA compliance unless substantially modified, but Article 69(3) overrides that specifically for reporting. A product you shipped in 2020 and have not touched since still needs a working 24 hour reporting capability.

Second, Article 14 does not itself require an SBOM, a coordinated disclosure policy, or active vulnerability monitoring by September 2026. Those obligations sit in Article 13 and Annex I Part II, and they apply from December 11, 2027. Coverage that collapses the two into one September deadline is describing the wrong article.

The practical consequence stands regardless. Twenty-four hours leaves no time to work out what is inside a product. You must already know.

Your incident response plan needs defined escalation paths, named owners, notification protocols for customers and regulators, and a route from a disclosed CVE to the list of affected SKUs in hours rather than weeks.

10. Align With Frameworks Rather Than Inventing Your Own

Aligning to published frameworks gives you a structure an assessor already recognizes.

• NIST SP 800-218 (SSDF), the secure software development framework referenced across US federal software policy
• NIST SP 800-204D, on integrating supply chain security into DevSecOps pipelines
• SLSA, the maturity model for build integrity and provenance
• EU Cyber Resilience Act, mandatory for products with digital elements on the EU market
• FDA Section 524B, which since March 2023 has required an SBOM covering commercial, open-source, and off-the-shelf components in premarket submissions for cyber devices, as covered in our guide to FDA premarket cybersecurity requirements
• ISO/IEC 27001, for the information security management system around all of it

Key Takeaways

• The threat model changed. Malicious packages outnumber hijacked ones two to one, and CVE-based scanning does not see them until an identifier exists.
• The manifest is not the inventory. Build records describe intent. Binary analysis describes what shipped, and for supplier-provided firmware it is the only method available.
• Reachability beats volume. With mean vulnerabilities per codebase at 581 and remediation rates falling, prioritization is the program.
• The nearest deadline is the reporting one. CRA Article 14 has applied since September 11, 2026, and it reaches products you shipped years ago.
• September 2026 is not an SBOM deadline. Article 14 covers reporting. The SBOM and vulnerability handling obligations arrive December 11, 2027.

Where to Start

One first move, and it costs a build cycle. Take the SBOM you would hand a regulator today, then pull the same inventory from the shipped firmware image and diff them. The delta is your actual attack surface, and until you have measured it once, every practice above is running on an assumption.

Three questions worth putting to your team this month:

1. If a CVE dropped tomorrow on a library buried in a supplier's BSP, how long would it take to list every affected SKU?
2. Who files the Article 14 early warning, by name, and what happens if it lands at 2 a.m. on a Saturday?
3. For the last three products we shipped, can we prove what was in the image, or only what the build system said it put there?

We derive component inventory from shipped firmware and binaries, with no source code required, then track those components against exploit intelligence over time. To see that against your own device, request a walkthrough.

FAQ

What are the best practices for securing the software supply chain?

Generate an SBOM from the shipped binary rather than the build manifest, pin and lock dependencies, verify provenance and sign artifacts, screen for malicious packages alongside vulnerable ones, vet third-party components before adoption, prioritize findings by reachability, harden the build pipeline, shift testing left, monitor production with a working incident reporting capability, and align to a published framework such as SSDF or SLSA.

How do you secure a software supply chain step by step?

Start with inventory, because nothing else is measurable without it. Establish what shipped, then add provenance and signing so future artifacts are verifiable. Introduce prioritization by reachability so remediation is finite. Harden the build environment. Last, build the monitoring and reporting capability that turns a disclosed vulnerability into a list of affected products.

What is the difference between a vulnerable package and a malicious package?

A vulnerable package is legitimate code containing a flaw, which is catalogued with a CVE and fixed with a patch. A malicious package is written by an attacker to cause harm, and it has no identifier when it enters your build. Black Duck's 2026 OSSRA found 66% of supply chain attacks involved purpose-built malicious packages against 34% involving hijacked legitimate ones.

Does the EU Cyber Resilience Act require an SBOM from September 11, 2026?

No. The obligation that applies from September 11, 2026 is Article 14 reporting of actively exploited vulnerabilities and severe incidents. SBOM and vulnerability handling obligations sit in Article 13 and Annex I Part II and apply from December 11, 2027. Reporting still requires an accurate inventory in practice, since the 24 hour clock leaves no time to build one.

Do CRA reporting obligations apply to products already on the market?

Yes. Article 69(2) exempts products placed on the market before December 11, 2027 from full CRA compliance unless substantially modified, but Article 69(3) carves out reporting specifically. A device shipped years ago and never updated still requires a working reporting capability.

How is firmware supply chain security different from application supply chain security?

Firmware has no standard package manager, so dependencies arrive as vendored trees, supplier blobs, and statically linked components rather than manifest entries. Source code is frequently unavailable for supplier-provided code. Devices stay in service for a decade with constrained update paths, so exposure windows measured in years are normal rather than exceptional.

What open source software security risks matter most for connected devices?

Unmaintained components are the dominant risk. Black Duck's 2026 report found 92% of codebases contained components four or more years out of date and 93% contained components with no development activity for two years or more. On a device with a 10 year service life, an abandoned component has no upstream fix path when a vulnerability appears.

What are the most effective ways to ensure software supply chain integrity?

Provenance attestation and artifact signing establish that a build came from the source and pipeline you expect. Reproducible builds make tampering detectable by comparison. Binary analysis of the shipped image verifies that what left the factory matches what you intended, which is the only one of the three that works on components a supplier compiled for you.