Schneider Electric’s Footprint: 15,000 Products and 30-Year Firmware Cycles
Schneider Electric makes 15,000 intelligent products. 80% are OT or industrial IoT. Firmware certificates run 30 years because the hardware never stops. A single data center UPS ships with three separate SBOMs: one for the HMI, one for the core card, one for the network card. Crossley started with a goal of 4,000 to 10,000 SBOMs and had to think about scale from day one. Legacy products update once or twice a year, with 40 to 60 firmware versions still installed in the field.
How Customer Contracts and Regulators Forced SBOM Adoption
Crossley’s first SBOM requirement arrived in a utility industry contract in 2019. She could not comply and had to redline it. She joined NTIA’s working groups that year and helped shape the SBOM definition that appeared in EO 14028. The EU Cyber Resilience Act requires SBOMs. Germany finalized its own requirements. The NSA’s NIAP program and the Department of Energy’s critical infrastructure certification process both ask for them. FDA adds another requirement for any medical device maker.
Impact Assessments: 30-Day Long Tails and 10,000-Hour CVEs
Schneider runs 30 to 40 major impact assessments per year for celebrity CVEs. The long tail, the last few products to respond, stretched past 30 days. With 500 product teams all answering simultaneously, one assessment often wasn’t done before the next arrived. Log4j had two CVEs and still required over 10,000 hours of analysis. A standard celebrity CVE runs 5,000 hours or more. With SBOMs, Schneider can tell a team the component is confirmed in their product and enforce an SLA on the spot.
The SBOM Portal: Scoped Access, Version Lookup, and CVE Mapping
The tool gives each customer a scoped view. An operator wanting the ION 8650 smart meter SBOM logs in and sees only authorized products. Downloads come in CycloneDX and SPDX formats. The vulnerability lookup shows every version of OpenSSL across the portfolio, flags unknown versions (forcing worst-case CVE assumptions), and identifies end-of-life code. One product showed six different OpenSSL versions from transitive dependencies and reused components. KEV findings traced directly to missing version numbers prompted Crossley to demand teams clean up their SBOMs.
Why 98 Percent Binary Scanning Is Not Enough
98% of Schneider’s SBOMs come from binary scanning. Scanners miss commercial libraries bought years ago with no continuing contracts. A full illumination of one data center product found 10 commercial libraries, none appearing in open source scanning results. Some were copy-paste code that predated modern package management. The goal is 80% of SBOMs generated inside the build pipeline. Supplier collection is the remaining gap. Crossley meets individually with legacy suppliers who remain uncertain what recipients plan to do with the data.
Q&A
How do you handle copy-pasted open source where the license is embedded in comments rather than a standard identifier? Scanners miss it; Crossley now requires teams to document all dependencies explicitly, and uses deep binary analysis tools like Adelis for older products to surface provenance. ▶ Watch (39:00)
With 4,000-plus SBOMs in the system, how much of the collection process is automated? Most collection is still manual, with 30 to 50 product releases per month requiring teams to hand over binaries; the fix is embedding SBOM generation in build pipelines. ▶ Watch (41:43)
How would an organization without an SBOM program calculate the savings case? Track time-to-response across impact assessments and license inquiries; even eliminating one round of “do you use this library” emails per CVE shows measurable return quickly. ▶ Watch (43:16)
Why no SaaS SBOMs? The SaaS SBOM working group never agreed on a schema, no customer has requested one, and SaaS products remediated Log4j within 24 hours before a new SBOM could even be generated. ▶ Watch (45:21)
Notable Quotes
your sbom you must reply in this SLA get Cassie Crossley · ▶ Watch (21:24)
98% of the es bombs we have we’re Cassie Crossley · ▶ Watch (24:33)
this has been a real game Cher for us to Cassie Crossley · ▶ Watch (35:10)
Key Takeaways
- A single complex product can ship with multiple SBOMs: Schneider’s data center UPS requires three.
- Binary scanning misses commercial libraries; 10 libraries in one product were invisible to open source scanners.
- SBOMs compress impact assessment response time but Log4j still required over 10,000 hours of analysis.
About the Speaker(s)
Cassie Crossley is Vice President of Supply Chain Security in the global Cybersecurity and Product Security Office at Schneider Electric. She is an experienced cybersecurity technology executive across Information Technology and Product Development, and author of “Software Supply Chain Security: Securing the End-to-End Supply Chain for Software, Firmware, and Hardware,” published by O’Reilly Media.