Evolution of SDL practices: from custom to product to service
The increasing visibility trend discussed in Part 1, of course, is impacting the current cybersecurity practices, in terms of maturity of evolution, also toward a “service”.
Organisations consist of value chains that are comprised of components that are evolving from genesis to more of a commodity. It sounds fairly basic stuff but it has profound effects because that journey of evolution involves changing characteristics.
Following is a Wardley Map (product evolution/visibility graph) comparing Penetration Testing (PT, more a reacting activity) and SDL (preventing vulnerabilities):
The previous example is a comparison over time (name it: 10 years) of one of the most common practice in cybersecurity. Penetration Testing (PT) went form a custom made exercise, to a product and shifting to a commodity (as a service PT, crow found style bug bounty, etc…) whether the ‘Prevent’ activity: SDL, is gaining the shape of a product and finally more visibility that, by the way, means money.
Pushing security left in the lifecycle, but also pushing up in visibility
Pushing left like a Boss series explains it very well: how to prevent better, but the map of the evolution of the SDL shows also the point discussed in Part 1 of the article: the visibility value on having an SDL.
The birth of a new language is the result (for some the cause) of this “pushing left”. DevSecOps is nowadays term to express this fact. “Threat Model” is another term gaining traction.
DevSecOps imply that the “security guys” will be working together with the developers and also that the developer will be more involved in the security practices. I think this is a real advancement in the SDL field, of course, vendors will overload this term with fancy product associations, that is always expected…we know that Dev*Ops is more a principle/value more than a bunch of products.
On the contrary, PenTest (black box testing, often disconnected to the SDL, non automated, single points in time activity link) will have hard times in the near future in an educated SDL environment. Will rules-based compliance follow this trend soon? Don’t know this answer. But if you think you need PenTest…most likely you need even more to mature you SDL!
Security says yes!
DevSecOps values push toward software evolution (CD: continuous delivery of new features), automation and quality (continuous integration). It is a fertile ground for increasing the maturity of the SDL. Investing in SDL means also more functional products in the short/medium term too, not only more secure and less risky. Of course, the challenge is to transform a legacy product/team to this more integrated approach. Intrinsic problems like lack of specific expertise in the market are still plaguing the cybersecurity and SLD sector. It is also something that cannot be implemented in “few weeks”. Defining a custom plan, called also programme or roadmap, based on maturity models like OWASP SAMM and OWASP 5D, made up of incremental enhancement over time have been successful in several organizations. It may take years but there are not many shortcuts.
