Jixiao Wang has already introduced the Agile concept in an earlier blog entry on the value of Agile development. As a follow up, I would like to share my insights on what will soon become a best practice in software development. In the first post of this two-part series, I’ll be discussing the crucial need to build security into the entire software development life cycle. With the Internet of Things and Industry 4.0 coming to the forefront, there are many new products being introduced to the market that are completely connected, but are not as intelligent as they should be. These new products pose security threats and vulnerabilities because security is not baked into them, but is bolted on later. At the beginning of the software development process, the cost to consider potential vulnerabilities and attack-vectors is low. However, the cost to consider these factors at a later point in time can be as much as 60 times higher. These high costs can include anything from having to redesign and redevelop, to having to do regression testing on the product.

As such, with so many security warnings published and shared by reliable sources, building in security should be the first thought. But, is it?Day-to-day practice and analysis of both software and embedded/firmware show the opposite. Most development companies choose lower cost and fast delivery over the security of their partners, users and clients.It goes without saying that this choice is not made with bad intentions. It is part of a mindset that is in line with the Agile manifesto, which states that only features which carry business-benefits are worth developing. Or, as the manifesto puts it, “Simplicity–the art of maximizing the amount of work not done–is essential.”

In the case of data and information security, as noted above, this can be counter-productive and costly. Think about a banking app with a known vulnerability, which allows customers’ funds to be stolen. There is no such feature in any given feature list as “Make sure the application/software is not exploitable.”

Feature lists only contain items with a positive business value.If we introduce vulnerabilities as a negative business value and try to maximize the total, the situation changes. It would then become essential for a vulnerability assessment to be done as part of the feature discovery process. Once these vulnerabilities have been assigned risk-values, they may be entered accordingly as a prioritized item in the feature list.In the next post for this series, I’ll be diving into processes and frameworks that support or could support secure software development. I will also play devil’s advocate and take a look at what happens if you chose to ignore this advice and wait to consider the potential security vulnerabilities later on.

Published first in: Security in Software Development: Part 1 | Shinetech Software