RosRed orange. Lemon yellow. #ff4500. #6699cc. Whether using pigment or light, when it comes to creating colours, the second word in the colour is the primary colour, and the first word is the descriptor. In “red orange,” it’s an orange colour with red; “#6699cc” is a grey with blue added.
It’s the same idea when talking about culture. For “DevSecOps culture,” culture is the primary word and DevSecOps describes that culture. I’m going to talk about culture first.
CULTURE
What is culture? There are innumerable definitions floating around the ether, but here’s one I’ve adapted for use here: How people in an organisation handle situations and people. Culture is powerful. And as for making such a short definition, it reminds me of what Louis Armstrong, the jazz legend, said when asked, “What is jazz?” He replied, “If you have to ask, you’ll never know.” It’s impossible to precisely define culture because it’s abstract instead of concrete.
The instant you try to nail it down, the definition either doesn’t capture the full sense, or the process of defining culture kills the culture. (On a sidenote, I think this is one reason that so many people are hesitant to write policies and procedures. When done improperly, the culture is at least stifled, if not destroyed).
There are two driving points for any organisation: Strategy and Culture. It might have been Peter Drucker who said, “Culture eats strategy for breakfast.” Regardless of what corporate leadership might have in their strategic plans, the corporate culture will win over all those strategies.
Most of the time, culture – of any kind, not just corporate – grows organically. It just “becomes,” not developing because simply someone started with “we’ll wear this, and say that, and buy only from these vendors, and sell only that product.” It stretches and expands to fit the character, capabilities, competence, and charisma of everyone involved – not just those characteristics of the leaders.
The power of culture is perhaps most keenly felt when there is a sudden shift in culture. In business, we see this when companies merge. Whether it’s a merger, acquisition, affiliation, buyout -whatever it’s called, the dominant culture – which is the culture of the company who won the merger – wins out. If you’ve ever been through this, it’s distressing for everyone, detrimental for some. Culture is mighty.
DEVSECOPS
Enough about culture and on to DevSecOps. What kind of culture allows it to thrive?
- An important aspect is having a better understanding of the motivators of and detractors in each element. I won’t review those here because they are covered well in this article: https://www.stackrox.com/post/2021/02/devops-vs-devsecops-heres-how-they-fit-together/ But I will say that this topic brings to mind the Stephen Covey quote, “Seek first to understand, then to be understood.”
- Another cultural aspect is that the model requires people to “fail fast.” Failure must be allowed. It’s not the kind of failure that leads to company ruin, though it may might be personally embarrassing. You know that main network cable that leads to your office, the one with the sign “Do not unplug!”? I’m the guy who accidentally unplugged it. I’m also the guy who returned a laptop without an RMA: it got lost on the return trip, so we never got our money back. I’m the one who worded something poorly in a policy and was glad that someone caught it before it went out. People make mistakes. The allowance of failure will actually lead to encouraging people to fail, born out of the idea that the more they do, the more they’ll fail AND succeed.
- The culture also has to engender the attitude of “a failure is an event, not a person.” As I referenced earlier – we’re not talking about allowing failures that destroy companies and reputations; I’m talking about failures such as “Oops! I deleted that section of code because I didn’t think it was needed. I’ll get it back ASAP.”
This kind of culture leads, not to diminishing returns, but to cohesion in the team and growth in technical acumen. Do those failures get pointed out and documented? Of course – the team doesn’t really want to spend another 4 hours on another night correcting the same mistake. The person doesn’t get called out, but the failure gets pointed out.
- The collaborators must be able to expose a vulnerability, have it prioritised, and get it fixed. No naming and shaming, because the goal is not a person’s desire never to fail, but to provide a secure and well-working product.
DevSecOps culture also lends itself to letting those doing the work determine what works best for them, which empowers them to be better professionals. Over time, the team notices patterns in failures and successes, and knows best what product or service would overcome those failures and automate successes.
- There needs to be ample maker time, so DevSecOps needs to be free from an interrupt-driven culture. There’s a creative aspect to DevSecOps that requires time to think. Anyone in the arts knows that about the sliding scale of concentration (though they may not call it that). On one end is complete focus on a task, but this extreme focus removes the emotional element. On the other end is the emotional scale, but this extreme leaves out the technical part. Toward the middle is the proper mindset, where there’s a free-thinking and open sensitivity required for being creative, in addition to keeping the boundaries of the techniques and protocols, provided by business requirements, customer demand, etc.
Perhaps you aren’t currently part of a corporate culture for proper DevSecOps to thrive, for whatever reason (e.g., current management attitude, a change in leadership). You could work on creating a subculture. You might have a co-worker with whom you can work to make improvements while not negatively impacting the current speed of production. Or you have some leeway to introduce a tool that can help slightly.
- Technology changes frequently, and those making things happen need to stay up-do-date with training. Embrace it, incorporate it as part of the incentives, make it part of the day, make it happen.
- DevSecOps are people, and they need rest. There’s only so much and so fast that people can work, and that’s why we use technology. In DevSecOps, technology does not replace people, but enables them to perform their various duties at the speed of light.
- Metrics have to be as concrete as possible. How does management determine if personnel are doing things right and doing the right things? Judging success by hearsay and feeling is never a rational metric
Regardless of what else it’s called – DevOps with a security focus, DevOpsSec, Secure DevOps – the end result is to have Development, Operations, and Security work together to iteratively create a good and secure product that is delivered timely. When the culture adopts these elements, DevSecOps will flourish.
