Is is Time to Reconsider Using Static Analysis?:

Static source code analysis is not a panacea for delivering high quality secure software. But many developers are quick to dismiss static analysis, often based on heresay, or experience with poorly designed tools or low-level bug catchers .

The old excuses are no longer valid for avoiding static code analysisstop_making_excuses.jpg


Does this sound familiar:

Below are some of the common excuses that we’ve encountered when discussing problems with software quality, and our replies:

Reason #1: We haven’t got time to change our processes we need to get the product out. 

This leads to the cycle of releasing bug fixes and patches in amongst new features or as new features and because of the timescales, even more, poor quality code, thereby leading to a cycle of more bugs and fixes.

Reason #2: I have no time- I just need to code and deliver

Greater software complexity through the use of the latest technology advances and complex organizational structures means there will be soon no room for this attitude. Ensuing quality concerns means that it is no longer that simple to “just code” without any thought to quality processes and environments. End users and customers whether in-house or OEMs expect more from their applications both in the way that they perform and the value they deliver.

Reason #3: The tools are too cumbersome

Not if you choose the right tool. Many modern static analysis tools are now well incorporated as an integral process within the developer workbench and workflow of their choice. Static analysis platforms from some of the leading players are providing sophisticated and easy-to- configure static analysis rules and diagnostics as an automatic function of the development process.

Reason #4: The tools are too expensive

While commercial tools represent an investment and have a greater upfront cost than open source options, when viewed relative to the cost of re-work and releasing defective software which can result in millions of dollars of brand damage and re-call costs the price of the tools is invaluable.   At the same time, tools can be introduced gradually and can scale with an organization's needs; many are modular, and role- specific, so that you don’t have to buy a “one size fits all” type of product. Also, the leading tools have become much easier to deploy lowering the cost of ownership by providing plug-ins to popular IDEs like Eclipse

Maybe Its Time to Take Second Look:

The expectations for software are higher than ever and development teams that don’t deliver safe, secure and reliable software will put their organizations at competitive disadvantage. Given this reality and the availability of high quality static analysis platforms there is no longer a good reason not to deploy this technology. The savings that you will achieve in the long run far outweigh the initial expense. More time and money will be spent sorting out bad code over the long run than getting it right in the first place.

 And If you're still not convinced perhaps you should check out the whitepaper

How IoT is Making Security Imperative for All Embedded Software

Why embedded software development needs to change and what organizations can do to improve software security while reducing development time