In our recent webinar, 5 ways to accelerate standards compliance with static code analysis, SCA experts Walter Capitani of Rogue Wave Software and Christopher Rommel of VDC Research reviewed the results of the latest VDC Research paper on the trends, techniques, and best practices for standards compliance within embedded software teams. This post is the second in a series answering your questions on static code analysis. Today, Christopher tackles five questions he didn’t get a chance to answer during the webinar.
- 1. Answering your questions on static code analysis
- 2. Christopher Rommel of VDC Research answers your questions on static code analysis
- 3. Walter Capitani answers your questions on static code analysis
Security threats, IoT, and embedded software
What about new or emerging security threats? How can I find those issues?
A great way to find new and emerging security issues is by ensuring your software composition and automated test tools (e.g. static analysis) are up to date. While many of those tools will already be updated against new known weaknesses and vulnerabilities, you can also stay on top of known issues by following the work of organizations like the MITRE Corp’s Common Weakness Enumeration (CWE) list.
What other new types of tools do you see as emerging and increasingly important to IoT and embedded software development?
The use of, and regular updates to, tools like software composition/compliance management tools (e.g. Palamida/FlexNet Code Insight) and even “older” tool types like software and system modeling tools and requirements management can help engineering organizations better manage system complexity.
What steps or technology do you recommend to address the growing risk to organizations stemming from IoT security threats?
In addition to using the technologies mentioned above, engineering organizations should completely revaluate both their bill-of-materials as well as their development processes. They can help improve the security of their devices through the use of specific runtimes (some RTOSs or security agents) and hardware that employs Trusted Execution Environments. Agile development methods can also help organizations more quickly identify and remediate any issues.
Are there any special automated testing considerations for embedded shops that are “agile-ish”?
Embedded shops that are agile-ish can certainly continue using testing tools that they have in the past, but there are other types of tools, such as static analysis tools, that can be more easily aligned with use within the development environment by developers.
In the age of cloud, IoT devices, and AI, we have to rely on provider platforms, such as AWS shell(s) and board support packages. If our provider does not support critical applications, it follows that our application cannot support critical applications and we should not “pick up” liability for faults of not our own, correct? Here’s an example of a provider disclaimer: “ABCINC products are not designed or intended to be fail-safe, or for use in any application requiring fail-safe performance, such as life-support or safety devices or systems, Class III medical devices, nuclear facilities, applications related to the deployment of airbags, or any other applications that could lead to death, personal injury, or severe property or environmental damage (individually and collectively, ‘Critical Applications’).”
In most cases, liabilities ultimately rest with the product OEM, and it is their responsibility to ensure they are using components that are fit for purpose for their application and that they can meet any industry process or functional safety standards. ISVs and component providers make those disclaimer statements because their effective and safe use is ultimately going to be impacted by the implementation and integration performed by their clients.
Even in those cases when safety certifications are provided, it is often for a specific set of hardware/software components. For example, higher levels of Common Criteria Evaluated Assurance Levels for operating systems are always pinned to specific OS versions and specific processors that were used in the evaluation. The nature of the embedded market is simply such that there are dozens of runtimes, dozens of cloud components, and thousands of processor types, so it is very difficult for vendors to provide assurances for all of their customers across the board.
Answers to more of your SCA questions coming soon
Keep checking our blog for more posts answering your questions on static code analysis. And if you haven’t already, be sure to watch the on-demand version of the webinar.