Abstract: Software development generally is challenging, and embedded software development for tomorrow’s devices is even more challenging. Product development teams and innovators are increasingly leaning towards open-source software for convenience and financial benefits. This approach addresses time to market challenges as well as the interoperability of legacy and future systems. But how safe or secure are these open-source software, and what are the considerations that are needed to make sure of reliability, safety, and security issues? This article focuses on the challenges of open-source software-based development and suggests considerations that are needed for the safe and secure products for the future.
The New Normal of Embedded Systems Development. But with Vulnerabilities?
Introduction
Software and compilers were delivered as part of hardware purchases starting the 1950s and not charged for it. The academic community is the earliest adopters of computing technology. Having said that, academia always aspired to experiment and innovate the existing software, and it is this quality that made the academia share the developed/modified software openly. The concept of free sharing of technological information long existed even before computers and that made it possible for individual innovators to come together for developing a product in use. Development based on the sharing and collaborative improvement of software source code has a history as long as software development itself. In the late 1990s, interest and participation in this phenomenon increased markedly with mainstream recognition of Linux in publications like Forbes and the release of the Netscape browser’s source code. The “open-source” label was created at a strategy session held on February 3rd, 1998 in Palo Alto, California, shortly after the announcement of the release of the Netscape source code.
Advantages of Open-Source Software
Open-source software doesn’t necessarily mean free. It is more dependent on the developer whether it can be charged or shared for free. The basic advantage of open-source software is the reduced time to work on the source code from scratch. Open-source code helps in quickly being used to develop the target application layer on top of the base code, thus giving a faster turnaround. The control that is available over the source code is the next advantage. The developer can examine the code to make sure of spurious activities and can change parts that do not suit the product requirement. The most important advantage is the financial benefit that the open-source software gives to a product development organization. But does open-source software is all that advantageous only? No.
Challenges of Open-Source Software
License: The various open-source license mechanism is Apache License 2.0, BSD 3-Clause “New” or “Revised” license, BSD 2-Clause “Simplified” or “FreeBSD” license, GNU General Public License (GPL), GNU Library or “Lesser” General Public License (LGPL), MIT license, Mozilla Public License 2.0, Common Development and Distribution License, Eclipse Public License version 2.0. These two broad categories of open-source permissive and copyleft. The features of permissive are:
- Do whatever you want at your own risk
- Acknowledge the author/contributor
The copyleft license adds additional expectations and requirements on the top of the permissive license.
- If you distribute binaries, you must ensure the source code for those binaries available
- The updated/modified source code must be made available under the same copyleft category under which the original code is acquired
- Additional restrictions on the top of existing copyleft license cannot be imposed
| Permissive Licenses | Copyleft licenses |
| BSD (Berkeley Software Distribution)MITApache 2 | Affero GPL (AGPL)GPLLesser GPL (LGPL)Mozilla Public License (MPL)Eclipse Public License (EPL)Common Development and Distribution License (CDDL) |
Various license schemes are captured in the above table in decreasing the level of strength or restrictions.
The weaker license like LGPL and other licenses lying below allow dynamic linking to other proprietary code without subjecting that linked code to the same GPL requirements. So, source code distributed under these licenses could be used in proprietary/closed source code as a library call.
Security: Software programming architecture poses additional challenges to those faced in a traditional PC- or server-based development environment, due to the ‘locked-in’ nature of the software when it is the post-deployment stage inside of a device.More contributors – more risk, and this is a real concern as well as the biggest challenge. But the most critical risk is that it can be hacked by any person with a basic understanding of programming. Security risks and hazards are practical, given the diverse group of contributors to the actual open-source software. Several open-source security issues are often overlooked, however, not the least of which is the fact that the code libraries it draws from do not always face the same level of scrutiny. In some cases, these vulnerabilities are documented, but the organization’s staff simply aren’t aware of them.
Quality: Many of the open-source software focuses on getting the work done. The considerations for documentation (comments, function header information), coding guidelines (MISRA/CERT and others), robustness, fuzz, stress, performance testing, structural coverage (required for safety-critical systems), and design patterns are not fully considered. At times usability and functionalities on multiple platforms are not explored, which could lead to operational, safety, and security concerns. Some of the open-source software might limit their exposure to the development environment and therefore not providing a testing framework either for development or deployment phases.
Maintainability: Many open-source libraries, applications are maintained by users/promoters and some are left unmanaged without updates, bug fixing, and security concerns. It would be prerogative of the user to understand the risk while using the open-source software.
Conclusion Just like any software solution, open-source software will need enterprises to apply policies, approvals, and controls around its deployment. Although typical use of open-source software can lower the total cost of ownership, poor management of open-source can bring out hidden costs related to licensing compliance issues and software vulnerabilities. The key to successful use of open-source software and keeping costs low is to ensure that there is an effective and enforceable open-source software policy in place. In addition to having a strong governance policy for open-source software, the use of qualified tools for verification and validation activities will always ensure the product is safe and secure while reducing the risk of exposure to litigations.
