[White Paper]Protecting the Embedded and IoT Software Build Environment with Software Composition Analysis

  /  Industrial IoT   /  Connected Industry   /  [White Paper]Protecting the Embedded and IoT Software Build Environment with Software Composition Analysis
Protecting the Embedded and IoT Software Build Environment with Software Composition Analysis

[White Paper]Protecting the Embedded and IoT Software Build Environment with Software Composition Analysis

Ensuring the quality, reliability and safety of software requires navigating a complex supply chain made up of engineers, operations managers, contractors, and independent software vendors (ISVs), along with open source software (OSS) providers. Oftentimes, device manufacturers that have outsourced development or integrated third-party software are unable to examine the source code. This makes it difficult to verify that the software complies with safety standards and meets the manufacturer’s own best practices for software development. Original equipment manufacturers (OEMs) rarely have access to all the source code used in their products.

Removing Security Vulnerabilities

Protecting the supply chain at each point within the development lifecycle is critical to ensuring the quality and safety of software without slowing down the development and delivery process.

“Hardening” refers to reducing the surfaces of attack and removing security vulnerabilities in the software, device, or system. Some of the primary challenges to hardening include: 1) Verifying non-functional requirements, 2) Reviewing compiled binaries, and 3) Protecting the DevOps build environment.

Security for Hardware

It is important to understand that in order for a system or device to be secure, not only does the software need to be secure, but the hardware itself needs to be designed and managed to provide an environment for the applications to function with optimal security.

Software and hardware composition analysis should be performed on systems and devices during the final product build in order to determine if the system remains free of security vulnerabilities. The development stage can be quite long, and security issues can arise during the development time period that were not present in the earlier development stages. It is also important to understand that the way the software and hardware are configured can affect the security of the final build, since static builds do not tell the story of dynamic execution.

How to Better Manage Software Build Risks

This White Paper covers how to navigate software quality and security safely, the challenges of hardening software and hardware, deconstructing the bill of materials (BOM), standards compliance (e.g. ISO 26262, IEC 62443 4-1, UNECE WP.29, etc) and recommendations for moving forward.

Learn about securing the supply chain and managing your organization’s build risks in this White Paper sponsored by BlackBerry QNX.