Shea Stewart from GigaOm recently joined an episode of our Perspectives in Leadership podcast to share his insights on evaluating DevSecOps tools, the value of a cloud-native environment, how to implement Zero Trust without bringing workflows to a halt, and more. Shea’s experience in networking, infrastructure, solution architecture, and open source cloud native technology gives him a unique perspective on what it really means to unite people, processes, and technology. 

As Shea shares in the podcast episode, “It’s very good to do the ol’, ‘Rah, rah, we’re all for this. We all want more secure applications.’ It’s people, process, and tooling, and that’s all of it all the time. There’s no DevOps product. There are tools that can help facilitate that but it’s still people, process, and technology.”

Shea shares the nitty-gritty of what it takes to find the right DevOps security tools for your organization. We highlight some of our favorite takeaways from the episode below. You can get the full range of insights from the self-proclaimed DevOps tech nerd in the podcast episode.

Listen to the full episode:

What is the value of cloud-native technology?

Shea shares that one of his passions is seeing teams become more effective and innovative. Cloud-native technology fits in perfectly with this passion and he explains, “I like to see teams become more self-sufficient. That was predicated on self-service delivery, which ultimately to me is what cloud native tech became about. It stopped the email chain of Word docs and moved us to that sort of instantaneous feedback and experimentation loop, which allowed the true geeks to nerd out a bit more and say, ‘How can I break something in a number of different ways?’”

What CSOs Should Know About Development and Deployment Pipelines

When it comes to development and deployment pipelines, there are several common challenges that Chief Security Officers (CSOs) face. Shea sees the following obstacles across industries and organizations:

• Inconsistent policies and tools: Teams often use different release engines, security gates, checks, languages, and stacks. This makes it difficult to knowledge share capabilities or updated processes across teams. CSOs and engineering managers can’t standardize or see how their teams are performing through development and deployment pipelines. Because it’s different for every team, it becomes more of a quarterly exercise just to get information and read reports. 

• Verifying the authenticity of artifacts before release: Shea notes this challenge is a huge issue for CSOs. It might look like being unable to verify if an internal employee who is on their way out has a bad taste in their mouth or, more commonly, if the libraries you’re using are dependent on open source, upstream things may have vulnerabilities or may have been compromised. “Once that library ends up in your package, you can't verify the authenticity. All of the sudden, it's running in production after making it through your general checks and balances,” explains Shea. 

• Not noticing security issues until they’re in production: Recognizing security issues once a system is in production presents serious challenges. Shea referenced a Canadian government system that had to be taken offline due to a vulnerability and was down for a week. “If we can catch that earlier, it’s much better. Until we actually put more tooling and processes into pre-deployment, we only know at runtime that there's going to be a problem. Usually, it's been there for quite a while,” says Shea. “I'm hoping in the next five years of my career that we're not talking about unpatched systems because we have the capabilities now with automation and DevOps security tools. That can't be an excuse. We should be continuously patching.”

The Importance of Planning and Inclusivity When It Comes to Security 

It’s not enough to say everyone should be responsible for security. For this concept to actually work, organizations must go back to people, processes, and technology. Planning and inclusivity come into play by including the security up front instead of mid-way through development or at the end. 

Going a step further, security teams can be placed into core application and platform teams from the start. Shea says, “That allows communication to normalize between what the security team needs and expects and what the application or platform team needs and expects. That normalized communication will break down a ton of barriers as well. It’s a useful exercise because it starts to create shared understanding.” Using the same tools helps to improve the workflow and enhance collaboration. 

Does Zero Trust Hamper Productivity?

It’s been said that the core challenge of Zero Trust is tightening access without bringing workflows to a halt. That change is always difficult, and in many cases, people will find themselves without access to tools, servers, and platforms they should have never had access to in the first place. 

Shea explains what Zero Trust means in a more granular sense, “What Zero Trust means to me is don't assume anything about the target environment. It used to be I would say, ‘I don’t need to worry about the network, but we can broaden Zero Trust wider than the network. If I assume my network team has taken care of that, then great. Then I don't have to do anything. This is a shift in that mindset. This is largely because if you actually look at the communication breakdown between teams, it's not that things are misconfigured, but that they're misunderstood.”

Tools and Technologies for DevSecOps Implementation

GigaOm’s radar report for subscribers evaluates DevSecOps tools for key criteria areas. Shea notes there’s a range of DevSecOps tools and services available in this space that perform everything from a simple fix to human-based coaching to provide education around security. There are a few things he recommends organizations keep in mind when looking at tools and technologies for DevSecOps. 

First, consider the tools you’re using. If you’re a GitHub user instead of a GitLab user, you may have two different approaches as to what other DevSecOps tools plug into that source code management system. Look at the vendors you’re already using. For example, if you’re already consuming RedHat, review what they have as far as DevOps security tools that may be easy to add to your existing support agreements. They can provide one piece of the puzzle.

Ultimately, know that there are a number of places where these tools fit, and there's not one vendor or tool that will do all of it. As Shea notes, “You're going to have at least three or four DevSecOps tools in a healthy pipeline, maybe a little more. There's lots of free stuff you can use today to start with. And that's always better than nothing.”  

For more insights into evaluating DevSecOps tools, check out the entire Key Criteria for Evaluating DevSecOps Tools report from GigaOm.