INTRODUCTION:
The recent interest in the so called “software supply chain” highlights the growing importance of using and reusing existing software. Companies realize they need to buy more and build less in order to meet their business goals. However, reusing open source and commercial software does have risks. It’s critical that software included in your product meets required quality and security goals. Automating the analysis and auditing of third party code and binaries is one of the ways of assuring the quality of your software supply chain. This post looks at the risks and rewards of the software supply chain and how advanced static analysis can improve outcomes.
Related
- Managing Third-Party Code Security and Quality with Binary Analysis
- 3 Ways to Strengthen Security with Software Supply-Chain Automation
- Reducing the Risk of the Software Supply Chain in Medical Devices
Reuse, COTS and Open Source
The productivity benefits of not “reinventing the wheel” are clear. Ideally, you are reusing your own code as much as possible; however, it’s most likely not devoid of security and quality issues. Free and open source software is usually of good quality and provides significant benefits especially when used for entire subsystems, for example, operating systems, web servers, file systems and networking layers. The same applies for commercial off the shelf (COTS) software. Again, security and quality is variable depending on the source of the software. In most cases, you aren’t certain if reused components are secure and high quality and thus steps must be taken to alleviate this risk.
Risks in the software supply chain
The risks in the software supply chain include but not limited to the following:
- Security: Despite developers’ best efforts security is often overlooked or simply not a priority during development. However, whenever third party source, libraries or object code is used in your project you inherit any existing security vulnerabilities. This introduces two key risks. The first risk is that you must keep third party software up-to-date as the vendor/developer releases security updates. The second risk is that any hidden or non-disclosed vulnerabilities are now part of your system.
- Safety: Developers creating safety critical systems understand the strict standards for writing and testing code for these devices. However, inclusion of third party software must adhere to the same standards or be analyzed and tested internally at additional time and cost. If the product needs safety certification, the certifying institution usually needs full documentation on how third party code was used and accounted for – a further cost.
- Quality: If bugs arise with third party software that aren’t necessarily safety or security related they may still cause disruption, poor performance and customer satisfaction issues. Again, your product inherits these issues so it’s critical to understand the quality of the software you’re using.
- Licensing: A particularly important issue when dealing with reused software is licensing. Open source isn’t necessarily free to use in commercial products or if it is, redistribution in a product may have legal requirements you need to satisfy. Devices that contain third party software are redistributing any source or binaries used within them which is a unique use case of open source. There is significant legal risk in not properly managing licenses of all of the third-party source and binaries used in your project.
Automating the Software Supply Chain
It’s not practical to inspect large amounts of third party software manually. Even in source form, it’s very difficult to inspect code that isn’t developed in house. In addition, it’s nearly impossible to inspect binary object files and libraries. The only way to effectively deal with this influx is automation. Automation encompasses more than just inspection, it also includes change and defect/security management, patch and updates, testing, and static and dynamic analysis. Of interest in this post is the important role that advanced source and binary static analysis plays in reducing the risk in your software supply chain.
The Role of Static Analysis
Static analysis tools provide quality and security assessments of code without extensive hands-on testing or understanding of the code or source. Security vulnerabilities and serious bugs can be detected and analyzed for cause and effect. Detailed reports can be sent to software vendors or internal teams for reparation. Open source projects can be notified and bug reports can be lodged for them.
Static analysis tools typically search for known programming problems described by the Common Weakness Enumerations (CWE) such as buffer overruns and null pointer exceptions. However, modern static analysis tools can also be extended to include domain specific checkers, validations that specifically hold for your software system.
Examples
Some examples of the types of vulnerabilities that static analysis can find is a buffer overrun in which memory is written, or read beyond the boundaries of a buffer. These types of errors are often not detected during testing as they do not always trigger a failed test-case, either as the buffer overrun is not hit by the input to the test-case, or because the buffer overrun still does not lead to a failed test-case, but the application may still have corrupted memory and cause a problem later. This type of problem underlies previously reported vulnerabilities such as Heartbleed.
A more domain specific test could be that for a specific application to function correctly, a user needs to be authorized before a certain function is called. A static analysis tool can be extended to codify that rule and it can be used to verify that property and make sure that it is never violated, even in the presence of 3rd party or legacy code.
Binary Code Analysis
GrammaTech’s binary analysis technology is built into CodeSonar. It can evaluate object and library files for quality and security vulnerabilities, augmenting static source code analysis by detecting tool-chain induced errors and vulnerabilities. It can also be used to evaluate the correct use of library functions from the calling source into a binary object, making the combination of source and binary analysis a very powerful tool indeed.
Although the possibility of fixing issues found in third-party code is often limited, binary analysis does provide a bellwether of the quality and security of the code. It can provide a quality metric of the third party code release-over-release that can be used to manage the relationship with the vendor. It can also be used to find vulnerabilities and then go back to technical support of the vendor and ask for confirmation and analysis of the discovered vulnerabilities. The key here is that the product vulnerability is better understood — third-party software with a large number of security issues found using binary analysis must be dealt with appropriately either internally or through negotiation with a software vendor.
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.
CONCLUSION:
An increased focus on the software supply chain is a good thing. Realizing that reuse is more productive means development teams can focus on differentiating features. However, the supply chain has risks that need to be addressed and automation is the key. Static analysis tools are key part of third party code management and help reduce cost and risk.
Like what you read? Download our whitepaper “Eliminating Vulnerabilities in Third-Party Code with Binary Analysis” to learn more.
{{cta(‘0da4b110-669c-481f-8096-6da4de44cbd1’)}}
