Have you heard the one about when a developer, operations and security walked into a bar? The developer bought a pint for themselves, and two halves for the others. The bar staff asked who was paying and the developer pointed to operations and walked away. The punchline being that security says I could have told you that would happen if only you’d asked. All joking apart, DevSecOps should be a part of corporate culture by now instead of still providing comedic relief for geeks. So, what’s gone wrong and how can it be fixed?
Friction-free and baked in
The concept of DevSecOps, a seamless integration of security tasks into the DevOps workflow, is a no-brainer. At least, it should be. The days of siloed security teams working apart from, rather than being a part of, both the development and operational process have been numbered for at least a decade. So why do we, in 2021, far too often still see security not being baked into all aspects of the software development lifecycle and instead added as some kind of tack-on component way down the line?
Friction, or at least the perception of friction, plays a large part. “Security teams are often viewed as erecting roadblocks to development to achieve the fictitious ‘100% secure’ system,” says Michael Foster, a technical marketing engineer at StackRox. Indeed, an expectation from security teams that developers should adapt their tools and processes so as to work with existing security tools can often add to this friction. It’s not difficult to see how this can be turned around, by literally turning around that expectation: make the Sec in DevSecOps as invisible, as frictionless, as possible. Adapt security tools, fort testing and compliance, to best integrate with those that are present in the DevOps toolchain wherever it’s possible. Just as the concept of 100% secure is never going to happen, neither will a totally frictionless contribution to DevOps. Which doesn’t mean we shouldn’t work towards a position of least friction, so to speak.
Shift left in silence
So, how do you go about achieving a near silent security contribution? By shifting left, yes, but doing so in such a way as to not to impact the applications at high velocity DevOps mantra. “Automation is the key to enabling DevSecOps,” Foster continues, “ by giving direct feedback to developers without hampering development speed.” This doesn’t have to change developer culture, after all code functionality testing is already there, adding automated security testing should be straightforward enough. Running such testing early and often, on the basis of more eyes and less fear, uncertainty and doubt equates to better security, doesn’t have to impact on development speed. Quite the reverse, in fact, as it should save time by spotting mistakes early in the process allowing them to be corrected without fuss. Think of it as an extension to the principle of DevOps continuous delivery to include continuous security. I’m not leaving operations out of the equation here either, as testing on a virtual machine can be automated with server configurations defined as code, so as to prevent potential security-based schedule stalling at the production stage.
Autonomy and automation
Culturally, this requires trust across the development and security landscape within the organisation. In turn, this requires better communication, training, learning and acceptance. Collaboration is key, and although it may seem at odds with arguing against the developmental siloes of old, autonomy also. Autonomy, that is, for DevSecOps teams to be in charge of their own decision making destiny, for their judgement in choosing the right tools, the right processes, for the job to be trusted. Whatever shortens the feedback loop while empowering the roles of developers, security and operations alike, must be seen as the way forward. Which brings me back, once more to automation.
An embed early and embed often approach to security control can only be achieved through the integration of automated tools within the continuous integration and deployment pipelines. The earlier the better, in fact, to enable the kind of automated feedback that is required to ensure developers can adapt to this new way of doing things. By increasing the efficiency of workflow in this way, there should be no slowdowns caused by security issues. After all, in effect they become just another bug in the code to be squashed as the development process evolves. Which isn’t to say that developers, nor operations for that matter, are expected to become security experts overnight. The whole point of a low-friction and automated approach to DevSecOps is that they don’t need to be, they just need to be part of a newly expanded security team that includes them.
Given the right tools to make building a security culture into DevOps a painless, and rewarding, option, the next time a developer, security and operations walk into a bar they will not only already know what each other wants to drink but the order will be ready and paid for. Which makes for a poor joke but much more secure applications.