DevSecOps isn't a trend - it's what your organisations needs to be thinking about from the start
Although tacking on another three letters to the already heavily abbreviated 'devops' has the uncomfortable aura of word soup, 'devsecops' is a logical, essential continuation of the devops mindset.
Devops is loosely defined as the process of breaking down 'silos' within organisations so that developer and operations teams are working side by side, and using automation wherever possible, with the aim of working towards common goals and releasing better, more stable software at speed. Bringing security into that process from the start is just sensible.
Security often requires highly specialised workers, so the danger with a devops strategy that excludes security is that it leaves these talented individuals out of the equation until the pre-release or, worse, post release stage - with consequences that could range from mildly irritating to potentially catastrophic.
According to Red Hat's chief security architect Mike Bursell, devsecops is really in fact about getting devops right from the start.
"If you're doing devops but not putting security at the centre of your process you're not doing devops properly," Bursell tells Computerworld UK. "This isn't to say that security should take over everything you do, because if that is what's happening then you're heading for paralysis, but that you should design security into your devops cycles. That's devsecops."
Bursell added that a good devsecops approach brings together tools, process and culture. "Engaging your security experts, making them part of the team and getting them to embed their various areas of knowledge into the process allows you to automate security into your devops model in a way that everyone benefits from their expertise," he added.
Excluding security at the start puts companies at risk in a myriad of ways. Some scenarios could be:
The security team finds a release is full of holes and sends it back for patching
An insecure release makes its way into the wild, which the security team then finds is full of holes and sends back for testing
An insecure version is released into the wild, attackers compromise your or your customers' network, data breaches happen, systems are hobbled, the entire company suffers irreparable reputation damage, massive fines, everyone is sacked, and finally, bankruptcy.
That last scenario is, obviously, an exaggeration, but the comparatively low effort of restructuring how you work to bake security in from the start is surely preferable than taking that risk.
Doing devsecops right
What does an organisation 'doing' devsecops 'right' look like?
It's a journey with no end. You're never done. If that sounds Kafkaesque, well, we're sorry, but that's just the way it is.
Some things you might like to consider:
You'll probably want open channels of communication between all relevant parties. You'll want everyone in the know through collaboration tools showing which projects are at what stage - all of this will help to loosen friction between teams.
Synopsys' Meera Rao says: "In doing so, application security teams should choose the most appropriate tools, technologies, and processes that support close collaboration," she says, adding that getting these steps right will help to break down those traditional silos between development, operations, and security teams.
Strong auditing tools and process should be in place too, with comprehensive changelogs and change capture points if you need to roll back to any point quickly.
"Creating a repeatable and auditable process is important for devsecops teams to rely on and establish a budget around," says Rao. "Enabling security activities that adapt quickly to meet the challenges of changing business goals and continuous, evolving threats facilitates collaborative change within a devsecops programme."
Research director for information security at 451 Research, Daniel Kennedy, says that if an application security program is working, defects are resolved "farther 'to the left'" in the software development life cycle.
"If SAST-type capabilities are being put in the hands of developers, as well as developer education components relevant to the code problem identified, less vulnerable code should make it into the builds," Kennedy explains. "A later regression test or security audit should see a lower number of security defects.
"There are a couple of ways to measure this, the most obvious is the reduction of security defects identified by an application security tool. But the continuous improvement piece comes in if you can start to introduce defects at a lower rate - and fix them earlier in the SDLC. Thus, they're touched by less people, early in the cycle, and have the least impact/cost to fix."
There are some standards of metrics organisations can look at to measure the success of the change programme. Quarterly reviews can help ensure that your business is on the right path. Rao suggests:
Where are we in implementing devsecops today?
What are some of the challenges we're facing and how can we overcome them?
What is working well and how can we resolve shortcomings?
These can be taken in the context of both short- and long-term progress.
Now, of course, nothing can be 100 percent secure, but having security embedded with everyone else means critical issues are more likely to be ironed out early on, saving headaches later on.
DevSecOps Jargon Buster:
CI/CD - Continuous Integration, Continuous Delivery is widely considered essential to a successful devops programme. It refers, predictably, to combining continuous integration and continuous delivery, with the aim of releasing stable code quicker.
Continuous Integration refers to the practice of bringing code changes back into the main code branch frequently, which can then be tested with automation. This, Atlassian points out, helps developers avoid the "integration hell" that happens when developers wait until release day to merge all code into the release branch.
Continuous Delivery refers to automating application code out to the various infrastructure environments, such as development and testing.