DevSecOps in a complex world

Being a cyber security consultant, I receive mixed messages. On the one hand, I see data that shows more organisations being breached than ever before, the cost per breach rising year-on-year, supply-chain attacks rising, and the number of incidents per organisation rising. Yet, at a recent trade event, I was presented with security companies claiming their products are solutions that stop breaches, reduce the cost of breaches (such as ransomware), and give organisations total transparency on current incidents so you can stop them in your tracks. So the message is: spend money on our tools because we are successful in solving your security problem; while the reality is the complex and messy state of cyber security is worsening. What’s going on?

I would argue that cyber security is not a problem to be solved — there is no ‘solution’; it is a complex, uncertain and indeterminate situation that needs to be managed. We cannot ‘solve’ security, we can only try to improve it. Maybe that’s what security companies are trying to do but their message is not articulated as such. But I go further to posit that organisations do not have the necessary collective knowledge or understanding to find ways of improving security and so have become more reliant on technical solutions rather than an appreciation, knowledge and understanding of the systems we are trying to secure.

I often see references to the DevSecOps infinity loop in security company literature claiming their products fit into the various parts of this visual representation of DevSecOps. I struggle with this concept. Why? Because the infinity loop is linear in its nature. It shows a linear migration from phase to phase such as design to develop, from testing to deployment and maintenance, back to design again. In addition to this the term ‘shift left’ has become ubiquitous. It suggests we do security nearer the design phase of the loop rather than towards the deployment and maintenace phases, which again hints at a linear construct. Yet I do not believe software engineering is linear. It consists of complex systems with multiple feedback loops, varying degrees of human interactions, different technologies and frameworks, and conflicting perspectives. Therefore, the reductionist approach of aligning technologies to the infinity loop does not provide the requisite variety associated with complex systems.

To demonstrate my concerns, I will explore the nature of running security scans to identify potential vulnerabilities within a package, whether it’s an image or a third party library. Traditionally, security scans are run as part of a build process after an engineer has submitted artefacts to a local repository or local container registry. This could be considered an activity within the ‘build’ phase of the DevSecOps infinity loop. If the build scripts that triggered the scan were run after a period of time following the engineer’s submission of code, there is a likelihood that the engineer has moved onto the next piece of work and is now working within another phase. Yet, we need to factor in that the engineer has not moved from one phase to another but is now practicing in multiple phases. For example, while engineers may be in the build phase discussing scan outputs with other engineers or prioritising fixes with the product owner, they are also likely to be in a development phase making code changes. In this situation, we now have the product owner in the design phase with the engineers, perhaps designing a fix for a previous vulnerability identified during a scan. Or the product owner is in conversations with some clients and has asked an engineer along for some technical advice. Which phase is the engineer in now? In reality, there are many different relationships and interactions at play; individual members of the team are involved in multiple parts of the lifecycle simultaneously. They are involved in multiple decision points, each decision based on different variables from different parts of the system; and there are multiple touch points within the software engineering processes itself. At any one moment, practitioners such as an engineers, product owners, and architects are involved in different parts of the ‘möbius lifecycle’.

I believe that cybersecurity practitioners, including security companies who sell technologies proclaiming their solutions solve security problems, should take an approach that’s more empathetic to the challenges organisations face in integrating security into their development practices. Security is not uniquely a technology problem that can be solved by aligning products to a development phase, it is a humanistic system with complex relationships between technologies, processes and people. Although many security companies offer managed services in addition to their technological solutions, offered as part of a package sold to an organisation. However, in my experience, this service is usually associated with training staff on how to use the security vendor’s product, or assisting their clients with the installation and configuration of their product, or providing ongoing technical support.

However, I believe that managing the complexity of security goes further than knowing how to use or configure a security product. Other factors are at play such as prioritisation, risk management, vulnerability management, security knowledge, engineering skills, power and conflict, and so on. Indeed, managing the complex nature of cybersecurity requires a collaborative approach involving multiple stakeholders, each with their own traditions of understanding and worldviews.

The word ‘DevSecOps’ has many different meanings to different people, and in my experience, it is a term reflecting our understanding of technology. A very unscientific straw pole on the meaning of DevSecOps returns terms such as ‘cloud security’, ‘container security’, ‘application security’, ‘secure pipelines’, ‘security tooling’ etc. But for me, DevSecOps is about managing complexity. Donald Schön references the swamp, a low ground where there’s uncertainty, complexity, and messiness that needs to be navigated. It is here where DevSecOps resides rather than in the high grounds where there’s clarity, deterministic solutions to clearly defined problems. It is only through accepting that a paradigm of managing complex situations through sociotechnical methods rather than solving problems with technology that we can reverse the failings of the cyber security industry.