I can’t pinpoint the moment I heard the term devsecops the first time. But I specifically remember thinking that this is someone’s bad marketing attempt to hijack or attach their own sidecar to the DevOps movement. All the while selling their flavor of a tool and a process.
But I was wrong.
Though DevSecOps from my perspective never gathered as much steam as anything labeled with just devops or agile back in the day, it opened my eyes to few blind spots that I had in my thinking. The whole security thinking and modeling could be shifted more to the left in the development lifecycle. Clear practices and patterns could be used to more effectively create a culture and environment where people have better shared understanding about different types of risks facing the success of their products and services.
I have had the positive experience of working in environments and with people who either intuitively or under the old monikers of sysadmin, ops or devops practiced and advanced principles discussed within the devsecops community. For me, most of the good things had already been diffused into the practice of devops. What was perhaps missing was a way or viewpoint to think and talk about security holistically as one natural and integrated aspect of the whole software development lifecycle.
And that was just a problem that I had with my own developer identity.
As a developer, I was always chasing the next milestone that would produce the benefit we thought we were after. Our goal was always to strive for quality, but the quality is a multifaceted term that means different things to different stakeholders and almost any decision is always a compromise. And as we are imperfect humans, we have many illusions about the code, how people will behave and how the system as a whole will work.
Good testers are great at breaking those illusions and feed good information and insights back into the development process. They help the whole team to refine shared mental models and see places that could be risks to the success of the product in any potential way - including risks in security.
But those skillsets are often kept in their own silos within the development processes or brought in to do only a specific contained testing mission. So some of our assumptions stay unchallenged until we learn about their breakages in production.
DevOps culture changed our perception regarding the operational side of the software. Responsibility for operational thinking shifted closer to design and development. As developers would be on call to answer for outages and problems in production, a sudden urgency emerges to think proactively how the system would behave live and what kind of observability would be needed.
Bearded and non-bearded sysadmins became trusted advisors to developers - sharing the goal of keeping systems running and chasing value. Instead of just saying no and protecting the stability of shared systems, we were collaborating on jointly making efforts to enable and achieve whatever was needed.
Our professional silos can help us develop and refine our skills and identity, but we must also be ready to let them go and grow beyond their limits.
Alistair Cockburn says something along the lines of not getting stuck in a shu-box ( sounding like a shoe box ) - with the reference to Shu-Ha-Ri model ( https://martinfowler.com/bliki/ShuHaRi.html ). It is a silly pun but nicely captures how some practices, tribes or thoughts can become limiting factors that slow us down or prevent us from doing what is the right thing. We get stuck in debating about recipe details when we should taste the soup and figure out what ingredient would balance the taste.
Each one of our tribes has their own culture, lingo, methods, practices, certifications and career paths - and very distinctive identities too. But we have the shared responsibility to build and operate something great.
Our world is changing and old organizational models, where disciplines that used to stay in their own lairs, dungeons or studios are finally trying to play a common game and move together faster. We are not there yet, but silly hashtags and like #DevSecOps, #DesignOps, #DevTestBizOpsSec or # DevSecBizDesignOps can help us move towards something better. ( See more about DesignOps here. It is a real thing. https://www.designbetter.co/designops-handbook/introducing-designops )
New technologies are enablers that can seriously disrupt or transform how we think about different activities in our different disciplines. Fundamental thinking and skills will stay, but how we use them for something good might look quite different. Something new, something old - and definitely something borrowed. And we all need to accept some trade-offs.
As an engineer, the move to the cloud computing has been a refreshing look at the world of computing and how we design systems to be resilient. To start without illusions and accept failure and no trust as the foundations.
Or as Verner Wogels put it: “Failures are a given, and everything will eventually fail over time.”
What would the organization look like that builds and operates services with that mindset? And how much that differs from the ones where we currently work.
There is already a plethora of research into the subject and high-reliability organizations provide good examples and insights into what kind of mentality and culture will be expected in the future more and more. For those who are interested in the subject, I highly recommend to read more about the subject and challenge your own thinking ( see more for example from here http://high-reliability.org/Weick-Sutcliffe ).
For me, this means that I have to keep my mind open and challenge my assumptions regularly.
We do not know what is the best way to design, develop and operate connected businesses that run with software. Our environment is changing - on multiple different levels - and we are still learning how to think, mitigate and live with new risks these changes bring. Naturally, risk management professionals disagree and say that they have been doing their work for decades and there is nothing new, so bear with me when I say we. With we, I refer to software professionals with a background in non-mission critical or life-threatening systems, where behaviors and practices have been quite different.
I see good things in the future. No matter what the hashtag.
We will need to talk and think more about the culture, not just structures, processes and phase gates.
We need to think about data and behavioral analytics more to be able to automatically make better sense about complex and complicated systems and interactions that happen in those systems.
We need to think about how we can be better in reacting to changes quickly - and how can we adapt to larger changes that persist.
Data, feedback loops, sense-making, learning, and resilience.
It will be challenging.
But it will be fun.
Let’s enjoy the ride.