In December 2020, thousands of organizations - including US federal agencies and critical infrastructure operators - discovered that a routine software update they had dutifully installed was carrying a backdoor. The SolarWinds attack did not breach its victims directly; it breached their vendor's build system and let the victims install the compromise themselves, signed and trusted. For SCADA buyers the lesson is uncomfortable and permanent: when you buy industrial software, you inherit the vendor's entire software supply chain - their dependencies, their build pipeline, their release process, their update channel. This guide explains how supply chain attacks reach OT, what SBOMs, dependency scanning, signed builds, and release assurance actually mean, and the specific evidence to demand from any SCADA vendor before their code touches your operation.
Part of the SCADA Security Hub - 60+ guides on SCADA security, compliance & certifications.
Security evaluations of SCADA platforms usually stop at the product: authentication, encryption, network architecture. All necessary - and all beside the point if the software itself arrives compromised. Every piece of vendor software you run is the output of a pipeline you cannot see: source repositories, third-party dependencies, build servers, artifact storage, deployment tooling. Compromise any link and the attacker does not need to defeat a single one of the product's security features, because they are inside the product.
SolarWinds made this concrete. Attackers implanted malware into the vendor's build process, so the malicious code was compiled into legitimate releases, signed with the vendor's real certificate, and distributed through the official update channel - a campaign documented in CISA's joint advisory on the SolarWinds Orion supply chain compromise. Roughly 18,000 organizations installed it. No firewall rule, password policy, or network segmentation at any victim could have prevented it - the trust decision had been made at purchase time. The 2021 Log4Shell disclosure taught the complementary lesson: even an honest, uncompromised vendor ships risk if they cannot tell you within hours whether a newly critical dependency is inside their product.
For OT the stakes compound. SCADA software holds credentials to control physical processes, and its edge components run inside networks that other defenses assume are trusted. This is why supply chain questions belong in every SCADA procurement - the discipline NIST formalizes in SP 800-161, its cybersecurity supply chain risk management practices - alongside, not after, the product-security questions in our cloud SCADA security checklist.
Four vectors cover most real-world cases:
Each vector has a named countermeasure - build integrity and provenance, dependency scanning, signed and verified updates, SBOM-driven response - which is exactly the structure of the rest of this guide.
A software bill of materials (SBOM) - see CISA's SBOM resource hub - is a machine-readable inventory of every component in a software product - direct dependencies, transitive dependencies, versions - usually in the SPDX or CycloneDX format. US Executive Order 14028, issued in 2021 in direct response to SolarWinds, made SBOMs an expectation for software sold to the federal government, and the requirement has been flowing into critical-infrastructure procurement, cyber-insurance questionnaires, and frameworks such as IEC 62443's supply-chain provisions ever since.
For a buyer, the SBOM's value is speed under fire. When the next Log4Shell-class vulnerability drops, the question is immediate: is that component anywhere in our SCADA stack? With an SBOM, your security team answers in minutes with a text search. Without one, you wait for a vendor statement - and vendors without SBOM discipline often need days to answer because they are discovering their own dependency tree in real time. That is the quiet, second value of asking: a vendor who can hand you a current SBOM on request demonstrably knows what is in their product. A vendor who cannot is telling you they do not.
An SBOM is a snapshot; scanning is the ongoing discipline. Mature vendors run automated dependency scanning against vulnerability databases on every build and on a schedule between builds - practices codified in NIST's Secure Software Development Framework (SP 800-218) - so a newly disclosed CVE in a shipped component surfaces in hours, not at the next release. Static analysis (SAST) of the vendor's own code and secret scanning - catching credentials accidentally committed to source control - round out the automated layer.
The buyer's questions are about operationalization, not tooling logos:
Merobix runs dependency and static analysis as part of its continuous validation program, and is building toward release assurance in which build, test, SAST, dependency, secret, and contract checks are all blocking - no release ships unless every gate is green. That "blocking" word is the one to press any vendor on: advisory scanners find problems, blocking scanners prevent them from shipping.
Code signing alone did not save SolarWinds' customers - the malware was signed, because the signing step happened after the compromise. Real build integrity is a chain of custody from reviewed source to running service:
| Maturity Level | What the Vendor Can Prove | What It Stops |
|---|---|---|
| Opaque | Nothing verifiable - "trust us," release notes only | Little; you inherit unknown risk |
| Signed releases | Artifacts unmodified since the build step | Tampering after build; nothing about what went in |
| Version transparency | Exact source revision (Git SHA) of every deployed service, visible on demand | Ambiguity during vulnerability response; silent drift |
| Release assurance | Deploys occur only from an exact green revision that passed all blocking checks; release bundles immutable | Unreviewed or failing code reaching production |
| Signed provenance | Cryptographic attestation binding artifact to source, build system, and checks passed | The SolarWinds gap: signed output from a poisoned pipeline becomes detectable |
Where does Merobix sit on this ladder, stated plainly? Shipped today: signed gateway artifacts with on-device update verification, and build/Git-SHA visibility for deployed services - you can see exactly which revision of each service is running. In progress, framed as roadmap: full release assurance - blocking build, test, SAST, dependency, secret, and contract checks with deploys only from the exact green SHA - plus immutable release bundles and signed build provenance. We publish the distinction deliberately: a vendor who blurs "shipped" and "planned" on supply chain claims is answering your most important diligence question for you. The same continuous validation program includes cross-tenant testing, replay and forgery testing, restore and failover exercises, and independent penetration testing as ongoing work - how to evaluate those claims is covered in our guide to verifying vendor security.
The supply chain does not end at the vendor's cloud - it ends inside your control cabinet. Edge gateways receive software updates over networks you do not fully control, at sites where nobody watches an install happen. If gateways accept unverified updates, every hardening step upstream can be bypassed at the last hop. The baseline is end-to-end artifact verification: Merobix gateways verify signed update artifacts before installation, and the roadmap adds immutable, versioned installs with atomic activation and rollback, with each installed version's provenance bound to the corresponding cloud release - so a bad or malicious update can neither half-apply nor go unnoticed. The full edge-device picture, from device identity to store-and-forward, is in our companion post on edge gateway security.
One structural note for buyers comparing architectures: an outbound-only gateway narrows the update attack surface too, because there is no listening port through which an attacker can push anything - the device fetches, verifies, then installs. How that architecture reshapes overall OT risk is covered in our OT network security guide and factors into any cloud versus on-premise decision.
Key takeaway: You cannot audit your vendor's build server, but you can demand its outputs: a current SBOM on request, blocking dependency and static analysis, visible deployed-version provenance, and cryptographically verified updates end to end. Vendors who have done this work will show you; vendors who have not will offer adjectives. Merobix documents which of these controls are shipped and which are roadmap on its security page - and will walk you through the evidence in a live demo.
Copy these into your next SCADA procurement, and score the specificity of the answers:
Weight these questions comparably to feature comparisons. A platform's alarm engine matters every week; its supply chain discipline matters on the worst day of your career - and by then it is unchangeable. The organized 50-question version across all security domains is in our vendor security question bank.
A software supply chain attack compromises the vendor's software before it ever reaches you - by poisoning the build system, a third-party dependency, or the update channel - so the malicious code arrives signed, trusted, and installed by your own staff. SolarWinds is the canonical example: attackers modified the build process so roughly 18,000 organizations installed a trojanized update of legitimate monitoring software. For SCADA buyers the implication is direct: your vendor's build server is effectively inside your security perimeter, so vet it like you would any other critical system.
An SBOM - software bill of materials - is a machine-readable inventory of every component and dependency inside a software product, typically in SPDX or CycloneDX format. US Executive Order 14028 made SBOMs an expectation for software sold to the federal government, and they are spreading through critical-infrastructure procurement. Buyers should ask for one because when the next Log4Shell-class vulnerability lands, an SBOM answers in minutes whether your SCADA stack is exposed - instead of waiting days for a vendor statement. A vendor who cannot produce one does not fully know what is in their own product.
Three lessons. First, trust in a vendor's brand is not evidence of build integrity - the compromised updates were validly signed by a trusted company. Second, the blast radius of a build-system compromise is every customer at once, which is why build hardening, provenance, and deploy-from-verified-source controls matter more than any single product feature. Third, buyers have leverage: asking concrete questions about build pipelines, dependency scanning, and release controls in procurement is what moves vendors to invest. The attack reshaped US policy - Executive Order 14028 and the push for SBOMs followed directly from it.
A signed build attaches a cryptographic signature to release artifacts so anything altered after the build is detectable. Build provenance goes further: it records verifiable metadata about how the artifact was produced - which source revision, which build system, which checks passed - so you can trace a running binary back to exact reviewed source code. Together they close the gap SolarWinds exploited, where a signature proved who shipped the code but nothing proved what went into it. Merobix exposes the build and Git SHA of deployed services today and is building signed build provenance with immutable release bundles as part of its release assurance roadmap.
Ask the vendor to show you, live: the deployed version identifier of each service, traceable to a specific source revision, plus the software version running on each edge gateway in the fleet. Platforms with build and Git SHA visibility can answer in seconds; vendors who must ask their ops team cannot really answer at all. This matters during vulnerability response - when a CVE drops, the first question is which exact versions are deployed where - and it is a strong proxy for overall release discipline.
Deployed-version provenance, signed gateway updates, blocking validation gates - bring the RFP questions from this guide and we will show you the evidence, shipped and roadmap alike.