Technically Speaking series decodes DevSecOps

Enterprises are becoming more nimble with DevOps workflows to take advantage of container and cloud technology, which can also lead to an increase in the attack surface of their systems. Monolithic, single-perimeter security approaches don’t work with cybersecurity threats like ransomware and supply chain attacks becoming more common. How can organizations revamp their security approach while continuously deploying applications?

Liz Rice, Chief Open Source Officer at Isovalent, has a few thoughts on core DevSecOps technologies that can help address these concerns. She joins Red Hat Chief Technology Officer Chris Wright in “DevSecOps Decoded,” a recent addition to our Technically Speaking series. 

The series features conversations between Wright and a rotating cast of industry leaders as they chat about what's on the horizon for technology. Here are some snippets from Wright and Rice’s conversation.

Developers don’t need to be security practitioners to be involved in the process

As organizations have embraced DevOps methodology, they’ve found ways to deploy code quickly with better collaboration between developers and operations. But, security has often been an add-on at the end of that process. 

“We can't be waiting for security patches just once a month, twice a month,” says Rice. “We have to be applying security processes, all the time continuously—just the same way that we do continuous testing.”

DevSecOps has emerged as the next phase in the evolution since security shouldn’t be an afterthought in application development. DevSecOps aims to enable more secure apps without requiring developers to be security experts, while still including them in the security process.

Wright notes, “We really have to think about everybody participating in building more secure code, from the developer writing code through to the automated testing, and even understanding what we put into production.”

Automating vulnerability scanning at runtime

We’re seeing more continuous delivery and more complicated applications that are broken apart into a collection of services. Teams in the pipeline need to shift left and place an emphasis on security early in the software development life cycle so that potential issues can be resolved before they become major problems. 

Vulnerability scanning is important to building more secure code in your continuous integration/continuous delivery (CI/CD) pipeline. The good news is that there are automation tools that can scan your dependencies for known vulnerabilities. Rice shares two recommendations to leverage automation tools in building secure code:

• Make sure that you're using known base images that have been agreed upon between developers and your security team. Developers might want to have all the bells and whistles in the base image, but from a security perspective, the smaller the image, the smaller the attack surface. Getting an agreement on what really needs to be inside a base image is a good best practice. 

• Think about how you inject credentials and secrets because you don't want those secrets baked into images. A certain service might need a password or token to be able to access a database. There are tools that can help you inject those secrets into images at runtime.

Wright adds, “Automation is really key and making this a part of everybody's jobs so that it scales as we put more code into production.” 

Shifting left with eBPF

As Rice describes in the video, “eBPF makes the kernel programmable. And we can use this for so many powerful things in terms of observability.” This can include spotting what may or may not be malicious behavior and things like unexpected network connections or unexpected executables running in your environment.

The Extended Berkeley Packet Filter (eBPF) helps us see things from the kernel’s perspective, which means move visibility into everything that’s running on a system in a really performant way. Rice sees eBPF as a powerful basis for the next generation of security tools. 

She says, “With the kernels that support eBPF becoming much more widespread in production use, people are going to be adopting those eBPF-based networking, security, and observability tools over the next year or two pretty prolifically.”

With eBPF, you have observability built into the kernel so you can see everything that's happening across the system combined with programmability so you can actually do some of the enforcement. eBPF itself is very low-level, but the new generation of tooling provides abstractions that are easier to use, like simple declarative policies.

Old-fashioned security processes won’t cut it

If you’re going to ship code several times a day, old-fashioned security processes may not keep up. DevSecOps is all about infusing a security mindset across teams. But to truly integrate security into the pipeline, new technologies like eBPF and automation tools for runtime security will come to the forefront. 

“By sharing responsibility, establishing more secure workflows with automation, and being open and transparent in our code, we can begin to connect our runtime protections and secure development practices to improve software security everywhere,” says Wright.

You can technically find more on YouTube

Want more DevSecOps content? Each episode of Technically Speaking sheds some light on a technology trend, and we’ve got not one, not two, but three recent videos focused on integrating security into your processes. 

Head to our YouTube channel and find “DevSecOps Decoded,” “SREs on a Plane” and “Unlocking zero trust supply chains.” Don’t miss another episode of Technically Speaking - make sure you hit subscribe!