DevOps: 'Test everything, everything is testable!'

Aubrey Stearn, interim head of DevOps at the Solicitor's Regulation Authority explains how to ensure your DevOps culture results in secure releases

"Test everything, everything is testable!"

That was one of the opening statements made by Aubrey Stearn, interim head of DevOps at the Solicitor's Regulation Authority in her talk at today's DevOps North Live event from Computing.

Stearn explained how to engender a DevSecOps strategy, dicsussing the entire development cycle, and finishing with some general tips of how to foster a DevOps culture.

"Over the last ten years we've seen a huge increase in the adoption of open source software, with more people coding, and more people writing software. And there's a huge focus on doing a better job, and trying to tackle security earlier," she said.

Stearn described the large number of different attack vectors in any piece of software, starting with the machine on which the code is first written.

"It all starts with your machine. Even if it's a brand new machine and you've just got it out of its box, it may already be compromised. Then there's your development package like NPM, NuGet or GEMS, we've seen each of them compromised."

She also discussed Docker, stating that in 2016 nearly 80 per cent of images hosted on the service had high vulnerabilities.

She said that the first time for coders to "save themselves" in testing code is pre-push.

"You have to test pre-push. You can't push code unless testing coverage is 100 per cent. Then your second chance is when pushing it to GitHub. You can run SNKY or Greenkeeper for vulnerability scanning. And lock down your packages so they're a fixed version. They should be immutable. If you're constantly pulling in new stuff, you don't know if you're safe."

The next opportunity to find problems, she added, is in the pipeline.

"You can do a code analysis, look at the quality, testability and maintainability of the code, and if there are any known vulnerabilities in it. Clair for example is a Docker scanner. If you've got containers running around with known vulnerabilities, it'll tell you."

She also advocated Detectify once code is released into what Stean described as "the scary real world" of AWS, Azure, Google or others. "Detectify will tell you if there are any deltas between what should be there, and what's actually there, " she said.

Stearn continued: "One of the fundamental problems with Docker is the lack of mantra in their journey to have testing in the container. Some work really needs to be done around that."

Firms should also look at a content security policy, she argued.

"That lets you say what content should be pulled and from where, and all the major browsers support it. If you're in a position to say where data should be coming from, you absolutely should be using a content security policy."

Stearn went on to give some general tips around implenting a DevOps and agile culture.

"Agile is a way of accruing credit based on the things you build. You can't do transformation without trust, it's like a currency. You build confidence in the things you're running and you can use that on experiments. So you'll then have the autonomy to do the things you want to do."

She recommended smaller builds where possible.

"I like the deconstruct challenge, so you do one week rather than two week sprints. You need to tell a story, so you get something new out every day, and by the end of the week you have the full story told. Devs get off on that, they don't want to get to the weekend with things still hanging over them."

Stearn added that having successful releases to show the rest of he business can be invaluable.

"If you want to make progess, and if building something like a Docker container, this is a piece of work I can popularise and PR the hell out of. My team built a Docker container, which means I can show the business that it's something we can consistently deploy over and over again. That gives me credits I can use to go do something else."

And when showing progress to the business, prioritise the C-suite, she said.

"C-level buy-in is incredibly important. Sometimes you need smaller projects to earn trust with your company, to show you've been successful working at a smaller scale.

"The key is to have the execs come down to you, to look at way you're working and see why it's succesful. Also imagine how powerful it is for your team to have someone from the C-level come down to your team to say 'Hey I've heard you're being successful I want to see it for myself.' That's so powerful," she concluded.