Jere Paavola: Building Secure Mining Equipment with Open Source: Lessons from 20-Year Product Lifecycles

By: Jere Paavola, Product Development Manager, Sandvik Mining

Transcript

1. Building Secure Mining Equipment with Open Source: Lessons from 20 Year Product Lifecycles Jere Paavola Mindtrek 6.10.2026
2. Jere Paavola – Leading development of SICA (Sandvik Intelligent Control Architecture), the platform powering Sandvik's mining machines – 20+ years in software development, including 8+ years at Sandvik – Works across hardware, software, and development tooling to keep the platform reliable, secure, and scalable – Strong advocate for open source, driving its broader adoption across development processes and engineering tools 2
3. Topics for today 1. How 20+ year equipment life-cycles impact on selection of OSS components? 2. How to use OSS based tooling to build secure IEC62443 -4-1 compatible development process? 3
4. Real machines, real environments Applications & cloud services Machines Remote operations –
5. Component lifecycle 5
6. Understand your software lifecycles Pla tf es iti ting softwa r o re pp u S functiona m l or Platform Core elements Long lifecycle, willingness to invest on maintenance, change has a big impact on customers or us. Keep stable, keep minimal. Examples: components with external interfaces, fundamental building blocks of the platform Intermediate life -cycle, impact on customers is manageable as long as changes are well -communicated and update path exists. Examples: User interface components (branding), utils, helpers, services Short lifecycle, often tools, scripts which are supporting the process but necessarily not part of end product. Change typically causes just training and data migration Examples: Tools, applications, scripts 6
7. Mapping lifecycle to selection of OSS component Hype, buzz Classic Popularity Stable License suitable now License stability, predictability Community active now Large community, proven track record Fixes vulnerabilities in the latest version Support for older releases, LTS versions Suitable programming language for the purpose Capability to take ownership if needed. Technological familiarity. Short Long 7
8. Questions to consider for long lifecycle components – What if component community loses momentum or direction is not preferred for us? – Fork own version, do we have competence, resources, interest for maintenance? – Find alternative component, how deeply this is integrated to our solution? – Take ownership, try to create new community? – How essential part the component is in for product? – Should we boost the community by contributing time, resource or money? – Can we minimize the risk with architectural changes? – Do we need plan B if something goes wrong? – What we do if license terms changes? – OSS to dual -licensing or commercial only – Are we willing to change to commercial option? What that means to us? 8
9. How can AI help in long lifecycles? – Lowering the risk level – We can more easily maintain OSS components if community doesn’t. – Less resources are needed for maintenance – Technological fit is less important – Meaning of programming language or used technologies are less significant. AI can program with most of the languages well. – Trivial changes like updating to newer framework version more automated – Quite often functionality of the library is still valid. External dependencies still causes update needs this can be automated mostly. → – Cybersecurity checks for older components – AI is good spotting cyber security problems (special permissions might be needed for this) 9
10. Tooling for secure development 10
11. IEC62443 -4-1 ML3 certification IEC 62443 -4-1 is a standard that defines secure development lifecycle requirements for industrial automation and control system (IACS) products, covering practices like threat modeling, secure coding, and vulnerability management. It focuses on how a product is built securely, rather than on the product's end -state security features (which is covered by IEC 62443 -4-2). 11
12. Tooling landscape Purpose OSS Vulnerability management DependencyTrack Syft Jenkins Version Control Gerrit Github Security Testing jMeter Custom Python scripts Burpsuite Artifact & Package Management ArtifactKeeper Github packages Code analysis CPPCheck Clang Backlog management CI/CD Commercial Polarion Jenkins Github Actions 12
13. DependencyTrack Extensive feature set •No need for costly enterprise alternatives. •Small modifications to support Sandvik WoW Open source solution •We favor an open -source solution over vendor lock -in. •Data can be exported easily via APIs if we need to move to other solution. Integration capabilities •Strong APIs support integrations and further in -house development. •Easy to create external dashboards and other supportive tooling. https:// dependencytrack.org 13
14. ArtifactKeeper Really active community •New features coming weekly •Support for almost all package managers in different languages Open source solution •We favor an open -source solution over vendor lock -in. •Data can be exported easily via APIs if we need to move to other solution. Cost saving opportunity •Commercial tooling prices has increased a lot. •Many commercial options per seat priced → scaling usage costs https://artifactkeeper.com 14
15. Key takeaways Match the component to its lifecycle stage Core and platform elements need classic criteria: stability, large community, license predictability. Short lived tools can freely chase popularity and the latest version. - Plan for community risk before it happens Decide in advance whether you'd fork, contribute, or take ownership. Waiting until the community has already faded removes your options. Open -source tooling can meet ML3 -level certification requirements DependencyTrack and ArtifactKeeper cover the vulnerability management and artifact/package management needs of IEC 62443 -4-1, without a commercial license bill. 15
16. Thank you 16