Manufacturers know how to qualify a physical supplier. Parts are traced to batches and tested before production. When a defect appears, there is a recall path.

Software often enters through a less visible route. A developer adds a package or a build tool pulls an action. The component can then reach a factory system without appearing in a traditional supplier register. This gap can completely shatter production resilience.

The factory depends on code it did not write

IBM’s 2026 X-Force Threat Intelligence Index found that manufacturing accounted for 27.7% of the incidents it observed in 2025. It was the most targeted industry for the fifth consecutive year.

The sector has an unusually broad attack surface. Corporate applications connect with operational technology, while software also runs inside products leaving the factory. One vulnerable component can therefore sit across systems with very different patching windows.

This is where physical and software supply chains begin to resemble each other. Both contain lower-tier suppliers that the organisation may never deal with directly. In software, those hidden tiers are often transitive dependencies pulled in by another package.

A five-year-old flaw is still generating millions of detections

Recent manufacturing data shows how long software risk can persist.

SonicWall recorded 474 million intrusion-prevention events on manufacturing networks in the first half of 2026. Its sensors also registered 13.8 million Log4j2 detection events, more than four years after Log4Shell was disclosed and fixed versions became available.

These are detection events rather than confirmed breaches. They still show that old dependency risk remains active inside manufacturing environments long after the wider industry has moved on.

A patch can exist while an organisation struggles to find every affected system. The problem becomes harder when the same library appears inside factory applications, engineering tools and connected products maintained by different teams.

The Trivy incident changed the trust question

The March 2026 compromise of Trivy showed that a trusted tool can become part of the attack path.

According to Aqua Security’s GitHub advisory, an attacker used compromised credentials to publish malicious releases of the open-source vulnerability scanner. The attacker also rewrote nearly every version tag in the Trivy GitHub Action so that affected build pipelines executed credential-stealing malware.

Teams used Trivy because they wanted to find vulnerabilities. During the exposure window, the scanner itself carried the risk.

The lesson is broader than one project. Supplier approval and a clean scan provide evidence at a point in time. Manufacturing teams also need to know which version entered each build and whether the source changed afterwards.

A software outage can reach thousands of suppliers

The 2025 Jaguar Land Rover cyber incident showed how quickly digital disruption can become a physical supply-chain problem.

The Cyber Monitoring Centre estimated a £1.9 billion impact on the UK and said more than 5,000 organisations were affected. Most of the modelled loss came from reduced manufacturing output at JLR and its suppliers.

The available public evidence does not identify an open-source dependency as the cause. The incident is still relevant because it shows the scale of exposure once software disruption stops production. A digital failure at one manufacturer can reach component suppliers and dealerships without directly compromising their systems.

Procurement cannot see a transitive dependency

Traditional supplier governance records the company providing a platform or industrial system. It rarely shows every open-source package inside that product.

Engineering teams may have part of the answer in manifests and lockfiles. Security may have separate scan results. Operations knows which system is critical. When these records are disconnected, the organisation cannot move quickly from a vulnerability notice to an affected production service.

Current dependency evidence closes that gap. A release-linked component inventory shows what was deployed. Continuous monitoring keeps the inventory useful when new vulnerabilities or malicious packages appear.

Make the evidence useful while code is changing

Dependency checks are most useful when developers can act on them. Waiting for a final pipeline gate can turn a small version change into a larger remediation task.

Developer-side checks can flag a vulnerable package as a manifest changes and point towards a safe version. The pipeline can then verify the same policy before release. This gives engineering and security teams a shared record without asking developers to leave their normal workflow.

A sensible starting point is one critical production service. Connect its component inventory to each release and test how quickly the team can locate a newly disclosed vulnerability. The result will show whether the software supply-chain map works under pressure.

Manufacturers already understand that supplier evidence must stay current. The same discipline now needs to reach the code running the factory.