Congratulations! You’ve taken the first steps to get that great IoT idea of yours into production. You’ve even hired a team of software engineers to build out your dream. But in the rush to market, software security (and security in general) cannot be an afterthought with IoT. Unlike a server crash in an enterprise, failure of an IoT component can result in direct physical harm. Think of medical devices. Or connected cars. Or industrial control systems.  

In-house software engineers are perhaps the one element that is under your control. Proprietary code can and should be tested within your agile software development lifecycle using static analysis software testing (SAST) tools. If you aren’t already testing your own code, you should consider doing so now. Performing software security and quality tests while you code dramatically reduces engineering costs later.

However, up to 90% of software developed today comes from sources outside your immediate control. This includes both commercially available software you may license as well as free open source software. Some open source software even has its own license requirements which, if you are not careful, may require you to expose your proprietary code at some point.

Often the inclusion of third-party software is done out of practicality. For example, you may not be familiar with all the ins and outs of SSL/TLS, so why reinvent the wheel when someone else has perfected it already? It may benefit your organization to use something like OpenSSL, or to purchase an existing commercial SSL package.

While relying upon a supplier may satisfy an immediate goal — get your product out to market sooner — you may experience some regret (and costs) if that product is later found to contain software weaknesses and vulnerabilities.

Once your smart device gets out into the field, its gets significantly harder to update — if your device even allows for updates. Some IoT devices communicate regularly with the internet, so updates may already be built into those communications. Other devices may require the user to download and install updates themselves. Still, other devices may not have the physical capacity to update and this may require a costly replacement of that device in the field.

So, as you develop your product/idea/concept, here are some things you should be asking your software supply chain partners.

1. Have you tested your third-party software against known software vulnerabilities? The MITRE organization publishes a list of known vulnerabilities, technically known as Common Vulnerabilities Exposures or CVEs. These can be found listed on the National Vulnerability Database. An automated Software Composition Analysis tools can check third-party software and identify any known issues.
2. Have you tested your third-party software against known software weaknesses? In addition to exploitable vulnerabilities, you need to be aware of common software weaknesses that can lead to future vulnerabilities and potential exploits. The MITRE organization also maintains a list of common software weaknesses. The Open Web Application Security Project or OWASP publishes a Top 10 list every three years identifying similar weaknesses. And the SANS organization publishes its own Top 25 list. An automated static analysis tool will perform these checks.
3. Do you know what’s in your third-party software? Some open source projects require that you make your source code public. Additionally, there are rules around licenses that could involve future legal actions. Better to know up front. Here again, a good software composition analysis tool can identify open source licenses, allowing you to determine whether or not you should go forward (or least know upfront what the hidden costs might be).
4. Do you know where your data is? Beyond testing the firmware in your device, web and mobile application testing is equally important. How the user interacts with your device or even how the device interacts with the Cloud could expose data in ways you didn’t intend. Agile runtime security analysis or Interactive Application Software Testing (IAST) can identify unintended visibility of sensitive data as it interacts with your software or the Cloud.
5. Finally, have you tested your software against unknown software vulnerabilities? Seriously, you can identify unknown vulnerabilities using a testing technique known as Fuzz Testing, also known as negative input testing or malformed input testing. The idea here is to create malformed inputs that can trigger a crash or signal the presence of a new vulnerability. While you can shoot-for-the-moon and test for every conceivable form of malformed input, you can also rule out a vast number of these scenarios and only focus on specific protocols and therefore be more efficient with your tests.

In production, your hardware will go through a sign off process, where each component is tested separately before inclusion into the final design. Why not do the same with your software and test each component – whether you wrote the code or someone else did? Adding incremental testing — building in quality and security along the way — will help launch your product successfully and reduce the overall costs of product management significantly.