What is devsecops and why should your business care?

Source – techcentral.ie

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.

Senior principle consultant at Synopsys Meera Rao agrees, adding that many organisations consider acquiring a tool, or a set of tools, as the primary step in transitioning to agile or devops.

“Tools aren’t a catch-all solution,” Rao says. “Devsecops can’t be simplified solely by automating a set of tools. However, when tool automation is implemented well, its merits are irrefutable. When it’s done poorly, development, operations, and security teams will waste time, effort, and budget as a result.”

While some developers might be au fait with the various strands of security at the top level, they will generally want to be focusing on writing and testing software. It’s great if they are security aware and mindful of this in their day-to-day jobs, but not everyone will be or will want to be.

“I love security, but not everybody does, and you don’t want to be saying to every developer: ‘you now have to become a security expert’ – because that’s a lot to take in, and it’s never going to happen,” Bursell said in a previous interview with Computerworld UK.

“But if you say on the other hand, I have particular people or roles whose responsibility it is to ensure our polices are automated into the processes, then we just make sure people follow the processes and we can manage by exception, then it starts to make sense.”

The risks
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% 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.

IDE – Integrated Developer Environments are applications to help build apps, usually including a code editor, compiler, debugger, and build automation tools to automate out the tedious tasks.

SDLC – Software Development LifeCycle – a SDLC comprises a few distinct phases and is usually illustrated in a circular chart – typically the stages are analysis, ie, what is the application for, design, implementation, testing, and evaluation.

Static application security testing/SAST – Gartner defines these as a “set of technologies designed to analyse application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities”. In other words, combing the design of an application for potential bugs, holes, or vulnerabilities.