INTRODUCTION:
According to VDC Research, 45% of embedded projects are outsourcing product development. The use of outsourced, open source, commercial software (COTS), legacy source, and binary code are increasing each year (e.g. VDC claims embedded Linux will be the embedded operating system of choice for 64.7% of all embedded shipments by 2017). Reliance on third-party software in embedded development and using software of unknown quality and security is risky and requires more scrutiny before forming part of your IoT and Machine to Machine (M2M) product. Static analysis of source and binaries is an essential part of the toolset needed to asses third party code.
More:
- Eliminating Vulnerabilities in Third-Party Code with Binary Analysis
- Outsourced Code Development Driving Automated Test Tool Market
- A Four-Step Guide to Security Assurance for IoT Devices
Reuse is Good
Reinventing the wheel has never been productive. Buying versus building often favors re-use, whether through open source or COTS solutions. Projects are rarely greenfield developments, so legacy code and reusing other corporate assets are a reality. Some of the most common uses of third-party code include the following:
- Communications — Enabling an application to communicate via the Internet or wirelessly with other applications.
- Databases — Third-party software is used extensively to manage, optimize, monitor, and back-up databases.
- Standard Libraries — These typically include definitions for commonly used algorithms, data structures, and mechanisms for input and output. Developers have become so accustomed to some of them that they forget the libraries are not part of the language itself.
With re-use’s reward, there is the risk of security vulnerabilities hiding in the code. Your end customer is going to hold your company responsible for the product regardless of where your source comes from! Evaluating the quality and security of existing source and binaries (libraries, object files, executables, and dynamic link libraries) is a particular strength of static analysis tools.
Assessing Third Party Code
The code you receive can come in all forms: uncompiled source, partial source and binaries, or binaries only. Given this, tools are needed to handle each type of situation:
Source Code Analysis
When full source is available, security assessment before integration into your product with static analysis tools such as GrammaTech CodeSonar is warranted. If the code is of “unknown pedigree (provenance)” or SOUP, as it is known, investigating quality and security errors is critical. In many cases, after initial assessment and repair, this acquired source can be integrated into the continuous build/analysis cycle.
Binary Code Analysis
If precompiled libraries or executables are the only form your third party code is available in, there is still the possibility to assess the software. CodeSonar’s binary analysis technology can evaluate binary code for quality and security vulnerabilities. Although the possibility of investigating and fixing the issues is often limited, it does provide a bellwether of the quality and security of the code. Customers of COTS products can go back to technical support of the vendor and ask for confirmation and analysis of the discovered vulnerabilities. The key here is that potential vulnerabilities are detected and accounted before code is used in a final product. More details on eliminating security vulnerabilities with binary analysis is available in this whitepaper.
Binary and Source Hybrid Analysis
Binary analysis really shines when used in a hybrid fashion with source analysis. Source static analysis has much more information about the intent and design of the software than binary analysis. However, whenever an external library is called, including standard C/C++ libraries, static analysis can’t tell if the use of the function is correct or not (assumptions are made, of course, for well known functions like strcpy() ). By combining source and binary analysis, a more complete analysis is possible. For example, if an external function takes a pointer to a buffer and a buffer overflow is possible with misused parameters, hybrid static analysis can detect this problem.
Supply Chain Risk Management for IoT
The growth rate in product development and the potential proliferation of millions of insecure devices is a serious threat to the success of IoT in the marketplace. Companies serious about security need to manage the security risk in their supply chain, including software (COTS and FOSS). Static analysis provides an easy-to-adopt and efficient approach to improving the quality and security of the third-party software.
This is the fourth and final in a series of blogs that go into more detail on this four step process.
CONCLUSION:
The success of IoT will depend somewhat on the smart build-versus-buy decisions on behalf of the device manufacturers. However, bringing in outside source and binary code has its risks, and proper assessment of this software is critical. Static source and binary analysis used individually and together provides a practical way to assess third-party code. To make good on the benefits of software re-use, it makes sense to keep all code at the same high quality and security standards.
