We recently held a webinar discussing how static analysis and open source scanning play an important role in ensuring that code coming into your organization from a third party, such as a contractor, an open source repository, or an ISV, is free from security flaws and gaps in standards compliance.
Ensuring your own code meets requirements is a difficult enough challenge, ensuring the same for all the code coming into your organization from the outside can be almost insurmountable.
Our attendees were a mix of developers and other people concerned with security and they all had one interest in common: protecting their organization from supplier risks. We always try to understand our attendees so here are some interesting results from the audience polls we conducted during the webinar:
Has either a Tier 1 supplier or an OEM requested information
about the tools/techniques you use for security?
No – 75%
Yes – 25%
This result may seem surprising at first but, in the context of automotive, code security and vehicle information security are concepts new to the industry (and is the main reason we run these webinars – education and action). The demand for connected devices and the growth of the Internet of Things is outpacing the ability of manufacturers to deliver safe and secure code. That’s why security must be built into development processes, testing, and reporting – you can learn more at 22:50 in the webinar.
Is it common for your teams to deploy open source code into a production system?
Yes – 80%
No – 20%
This result may also seem surprising given that an industry built upon safety and reliability would be more likely to avoid open source code that’s not necessarily safe or reliable.
When it comes to open source, it’s important to consider two things: 1) many open source packages have been in use for a very long time such that the sheer amount of “real-world” testing allows people to think that they’re robust; and 2) open source is easy to find and easy to customize to your own specific needs, making it a cost-effective way to get desired functionality. Despite this, it’s important to remember that this ease of use also makes it easy for vulnerabilities and flaws to creep into your product, especially with open source packages that are new or used in non-traditional environments. You can learn more about these risks and ways to defeat them by fast forwarding to 43:25 in the webinar.
What tools/techniques are you currently using to protect yourself from security vulnerabilities?
(multiple answers allowed)
Penetration Testing – 75%
Static Code Analysis – 50%
Dynamic Analysis – 25%
It’s good to see that teams are taking an active approach to security testing and moving beyond traditional static code analysis, often used to find simple bugs only, towards more sophisticated uses.
For more on how Klocwork and OpenLogic help reduce security and safety risk in automotive software development:
• Sign up for our educational series of exclusive videos, articles, and white papers geared towards making you a better automotive developer here
• Read this white paper for three steps towards protecting software against attack, identifying critical coding errors, and managing functional safety issues (PDF)