IOT_HACKED.jpgSecure software (or the lack thereof) is a now a daily news topic and a major challenge for a growing number of companies who are increasing the amount and complexity of software in their products. Many software architects and developers lack training in security technologies and techniques and have only a rudimentary understanding of what should be done to improve application security. The urgency to improve application security has resulted in security being added to the requirements list in the form of features. This has resulted in feature requirements such as application firewalls, data encryption modules, and adding SSL to secure data flows. While these are all positive improvements; security features don’t do much to address some of the most prevalent security issues, which are the result of insecure code.


Removing defects from code and following secure coding practices falls under the responsibility of the development organization and is viewed more like a software quality issue. Secure code doesn’t usually appear on a feature list and hasn’t traditionally been on a customer's requirements list. Customers don't make requests such as:

  • The software should be free of buffer-overload vulnerabilities
  • The software shouldn’t have run-time errors that can be exploited by a determined attacker
  • The software shouldn’t store my data or data in plain text files which are easily accessed

But why would customers make such requests? They wouldn't think to because they expect manufacturers to have thought of these issues and coded their products securely. For example, just as a mobile phone buyer doesn't specify "the phone should get reception indoors and outdoors" or "charging my phone shouldn’t cause a fire,” software developers and device manufacturers need to adopt a new attitude and approach that addresses the safety, security and reliability of the software to ensure that it doesn’t place users or data at risk.


Writing defect-free secure software needs to become part of software development lifecycle and treated the same as software quality. It can't be considered as a feature you can monetize and charge your customers for. Secure software needs to be seen as a critical component of creating an excellent product that sells more units and creates satisfied customers. Insecure software, especially if it is exploited by an attacker or discovered and publicized by a watchdog group, can generate negative publicity, lack of trust by customers and damage sales. Ultimately, your bottom line is at stake. 

Developing more secure software doesn't replace the need to add security features, such as encryption and firewalls, which play a vital role in security the software and device. These features should most definitely be considered and added for protection, but if they are not implemented properly due to poor coding, then they will fail to deliver a truly secure product and worse give a false sense of protection to those producing and using the software application.


All in all, when then needs of the business and their customers are taken into account developing safe, reliable and secure software is a smart business decision and worth the investment of resources to do it right. 

For more information on how to improve code security  check out the white paper ADDRESSING SECURITY VULNERABILITIES IN EMBEDDED APPLICATIONS USING BEST PRACTICE SOFTWARE DEVELOPMENT PROCESSES AND STANDARDS   and start protecting your applications