Introducing DevSecOps to your business — 3 considerations

DevOps emerged from agile software development, a methodology that itself emerged as a group of developers sought to gain control over the product development lifecycle.

They wanted to break down the walls between them, their technology, and the customer, cutting out the middleman in order to create and deploy better products faster.

That was back in 2009. Today, as competition continues to grow in the technology industry, DevOps is a commonly employed methodology aimed at driving lower costs, flexibility, agility, and fast application delivery. Red Hat’s chief agilist, Jen Krieger, told us, DevOps is about “getting to the true ‘nuts and bolts’ of software development and putting power back in the hands of the people who actually own that process […]”

This process — done right — fosters the rapid-release cycles for application development and deployment now central to most large businesses.

More recently, however, the issue of security has joined technology as a central business tenet, by necessity. Cyberattacks are now the biggest threat to businesses. As our organizations become increasingly digitized and reliant on the rapid production of apps and software, DevSecOps has emerged as a bridge to the gap that frequently exists between development and security teams.

Or to use a unique analogy: if DevOps is viewed as something of a 3D printer — machine-like and quickly able to create new solutions — the aim of DevSecOps is to ensure cybersecurity is added to the polymer.

Software developers used to release new applications every few months, or longer, and that provided ample time for code to be tested for quality and security by separate teams. In the last decade, however, public clouds, containers, and microservice models have created granular and complex IT architecture, all of which is being deployed at such a pace that security must be baked-in, or risk being overlooked.

“Looking back to the start of DevOps around 2009, there were certainly some companies that already had a security mindset,” said Patrick Debois, director of DevOps relations at Snyk. “However for many, the main focus was on getting the continuous delivery pipeline going between Dev and Ops.

Debois continued: “Now, as companies continue to undergo rapid digital transformations, security teams are faced with greater demands and often become more of a bottleneck. By embracing a DevSecOps culture, security is brought into the DevOps fold, enabling development teams to secure what they build at their own pace, while also creating more collaboration between development and security teams.

“This allows these security teams to become a supporting function, offering their expertise to increase developer autonomy but also still providing the oversight the business needs.”

DevSecOps, according to Debois, is for every business where security is a bottleneck to the development and deployment process. And while it’s particularly important to large financial companies holding vast amounts of sensitive personal data, it’s equally important to small startups scaling fast, that could otherwise be swiftly derailed by an opportunistic breach.

“DevSecOps is becoming part of writing good code, but embracing it is also a journey that doesn’t happen overnight. However, being aware of the need for a DevSecOps culture is already a step in the right direction,” said Debois.

For organizations who are ready to embrace a DevSecOps culture, Debois recommends considering three ‘pillars’ for implementation.

Collaboration rituals

Every business’ tech transformation has its own technical collaboration ritual. Agile had Test-driven development (TDD) and Scrum, DevOps had configuration management and post-mortems, and now DevSecOps has threat modeling, the conversation around where vulnerabilities live in architecture and the impact they have.

“I would say this is a good place for companies to start when implementing a DevSecOps culture, as it brings people together […] an agile DevSecOps culture can only be enabled through collaboration instead of siloed thinking,” said Debois.

DevOps and security teams should work together to enable innovation and security.

Start simply

The ‘typical’ process starts with DevSecOps teams getting buy-in to do a proof-of-concept. Debois recommends choosing something simple to start that brings real value, to be able to build on initial success moving forward.

“Once you have built some success, you can start to roll it out to different groups, while still measuring and demonstrating success to the business, said Debois. “As this process moves on, you start to standardize the procedure, so when the next group comes on, there is a standard way of onboarding.”

Initially, the threat modeling process would have been more ad-hoc, but as experience is gained it can become automated and end up being self-servicing.

“This is important,” continued Debois. “In order to embrace DevSecOps culture, employees must be actively supported to participate in a new culture and a new way of thinking.”

Automation

There are, of course, solutions that can better accommodate DevSecOps into the delivery pipeline — often through automation — which ensure security is integrated from the very beginning, and ensure the needs and requirements of developers are placed front and center.