Best Practices for Tackling Security Early in Software Development

According to a 2009 survey from Software Productivity Research LLC, poor software quality costs more than US$500 billion per year globally in financial, competitive, and brand equity losses. Not surprising, given that software is at the heart of operating many of the products that we use every day.

Whether direct and obvious, or indirect and hence harder to realise, there is real business value associated with software quality.

The news headlines related to security breaches, stolen user data, and unauthorised access can often be traced back to common programming mistakes and defects in code introduced during software development Errors, bugs, defects--whatever you wish to call them--can add up to major financial and business costs that just cannot be ignored.

In addition to the software created internally, a big source of unsecure code is from different sources of third-party software.

Consequently, software organisations are realising that it is crucial that the software they develop in-house or acquire from third parties must be secure. Developing, deploying and using software without addressing the security vulnerabilities is a big risk not worth taking, especially considering the cost-effective options available.

Here are several interesting points about the increased exposure that comes with global connectivity and some best practices that organisations should consider to minimise that risk:

- Security should be integrated into the product lifecycle. Quality improvement is the end-result.

- Management needs to be aware that security is a serious commitment and investment.

- Adopt secure coding standards for your target development language and platform.

- Leverage a solution like static analysis to not only facilitate the discovery of security defects, but to assure the overall product quality.

This week I want to focus on the the first point on the list. Security integration into the product lifecycle is the most important step that companies can take to mininise risk.

As we all know, security breaches in software and mobile devices are always making headline news and costing companies millions in lost revenue and damage to brand equity. As more people conduct increasingly sophisticated and sensitive transactions on their mobile devices and over the web, the stakes around software security are rising.

Plus, the software and platforms themselves are becoming increasingly complex with multiple components coming from multiple providers. Companies often have little visibility into the security or quality of the third party code-which can introduce multiple points of failure and blame. Traditional approaches to security are no longer sufficient.

For too many organisations, security is left to an isolated security audit team with limited resources and is conducted at the end of the software development lifecycle. And the later the issues are raised in the lifecycle, the more expensive and time consuming they are to address.

Compounding this issue is the fact that security audit and development teams have different goals. Security audit teams are focused on risk- meeting audit and compliance requirements by ensuring vulnerabilities are identified and remediated prior to release.

Development teams, on the other hand, are driven by speed and innovation- deliver new products to market, fast, at the least possible cost. This is what all too commonly happens: a security audit is performed at the end of the development cycle, with tools purpose-built for a security auditor.

Then, a PDF report containing a long list of security vulnerabilities- without context or guidance of where they exist in the code and how to fix them-makes its way to the developers desk as they are racing to get the product out the door on-schedule.

If the information isn't actionable, isn't presented in the developer's workflow, and isn't addressed throughout the development cycle as the code is being written, security isn't going to be effectively addressed.

To properly address security risks and vulnerabilities without jeopardising speed or cost, companies must bring security into the development process in the same way quality defects are managed today. This means adapting security to the way the developers work, not the other way around.