For this particular post, I would like to share a white paper I recently came across summarizing a major research on the security of various types of software from off the shelf to custom built applications either by in house or by 3rd party developers.
As a software architect, looking back from my own experience over 20 years, I can easily agree with the results in this paper. While it's foolish to think any software is 100% secure, it's undeniably true, aside from financial sector, business software is many times built with minimal focus on security. In fact I would go as far and add, the levels of security obtained in the software is many times directly related to the level of experience the developer or team involved has.
In a room of 3 developers, with 1, 5, and 10 years of experience each, each would claim to have developed good and secure software based on the scope of their knowledge at the time. All three can develop a sound solution meeting the functional requirements from the perspective of business or product owner. However, as with any practiced discipline, the developer with 10 years of experience will usually build some additional safe guards for security or at a minimum is aware of certain of advanced topics such as code signing, etc. where such is unbeknownst to the less experienced developers. Consequently the level of security in each is starkly different and is not easily measurable without explicit validation.
How do we apply metrics and quantify the level of security? A business owner, unaware of programming details, is not able to measure this. A manager similarly, would be primarily concerned about timely delivery of functional aspects over any security needs which may delay the actual deliverable. Furthermore as the paper mentions, less than 20% "of organizations surveyed view security as the most important criterion when developing custom applications internally or when having customer software developed by third parties".
As a result, a concerted effort must ensue for education on secure development. Similarly a concerted effort must ensue to adopt patterns for security validation much like we have validation for functional requirements. Some can be automated while some require human validation similar to automated unit tests and manual human tests of functional aspects in software.
In this day and age, its abundantly clear the software we write for the web is directly exposed to thousands and even local software running on computers or devices, is indirectly accessible by just as many -- security should be at the forefront moving forward.
Here is the white paper, which although shocking, I vouch for it's factual findings and is a worth while read for anyone in the business delivering quality secure software.