Search
English
English

Select a language

Log in Account
Log in / Register Account
Websites

Video

Developers Discuss: DevSecOps

About this Video

Whether you call it DevOps or DevSecOps, one thing is certain: security has changed in the age of container-based, continuously delivered applications. 

We asked Red Hatters Mary Johnston Turner, Director of Management Software Evangelism, and Kirsten Newcomer, Senior Principal Product Manager, to discuss the role of security in enterprise DevOps initiatives. For example, now that apps involve many container images instead of one .JAR or .TAR file, what tools do you need in place to scan those images? See what they think, and how Red Hat’s product portfolio can help. 

Learn more: https://www.redhat.com/en/topics/security/container-security

Run time
4:50
Date
December 20, 2018

Transcript

[Mary] I've talked to more than one developer who really sees security as getting in the way of getting to market.

[Kirsten] A lot of developers don't learn about security principles even if they've been in the industry for a long time.

[Mary] What I find interesting in the DevOps space, particularly as we start to move to container-based applications, it seems like some of the things we've always known about security, really are starting to change.

[Kirsten] When we think about DevOps, just DevOps, no matter what the application delivery or deployment target is, it really needs to be DevSecOps and that was the original intent but it gets lost sometimes. One of Red Hat's customers, and, I'm not allowed to mention their name but one of the big changes they made in adopting DevOps and this happened to be in a containerized environment, they needed to start thinking about security as code. You want that integrated right at the beginning.

[Mary] Every organization has, historically, had scheduled down time, right? And they went through these patch cycles and they did the updates. I think what we found is that the nature of the threats keeps accelerating.

[Kirsten] With a containerized application, what you need to be patching is the application, but it's the container image that you use to deploy the application. You restart at the beginning of your pipeline and you patch the application and you rebuild the container image. Depending on the severity of the newly discovered vulnerability, I may decide that I'm gonna continue to leave it running until I get this rebuilt container image ready to go through all my security gates, through all my testing and ready for deployment. And I can slowly move traffic over from the old, the already running container, the previous version, to the new version so I don't have any down-time at all.

[Mary] The reason that many of our customers have partnered with us for so many years is because we do such a great job, on working across the industry, whether it's hardware based or other sorts of vulnerabilities and risks and then getting that out to our customers very quickly. From a more traditional operations view, there's many tools and processes that are well-proven to do that. How do we integrate all that into this container world? 

[Kirsten] It's a great question. Because, again, so a containerized application, is made up of many pieces. So, instead of pulling down a JAR file or a TAR file from my database or an RPM, I'm pulling down container images. So I need to know that these are a little bit more opaque. I need to be able to have the tools in place to scan those images but ideally, also, I'm working with content from a trusted vendor. So, Red Hat has the Red Hat Container Catalog. Where we have vetted versions, containerized images for a lot of the open sources that our developers need. And when new vulnerabilities are discovered, we update the images and there's also a technology built into OpenShift called Image Streams that helps our OpenShift users track and be notified of newly updated images in order to help streamline that build process, right? Again, I'm not patching in place, I am rebuilding my container image and redeploying.

[Mary] One of the initiatives that we've just recently done at tech preview of on the Ansible side, is Ansible security automation, trying to take event analytics and actions and link them across some of those different things. Because, again, you can't operate in silos anymore. You've gotta have the integration, you've gotta have the speed of execution and reaction but also something that you can report on. Because that's the other side of security is the compliance and reporting.

[Kirsten] Traceability. Auditability. And that's one of the reasons that, again, when we think about the compliance as code and the automation, infrastructure is code. The more you automate, the more you have actual documentation that you can share with your auditors and demonstrate: here's how I'm complying. Here's what I've implemented. Here's the log files.

[Mary ]Well, security is gonna continue to be a top priority for DevOps whether you're a developer, whether you're on the operations team, or whether you're a business or security analyst. I'm really excited because I see Red Hat making investments in so many of these different domains and trying to address the whole lifecycle of security across Dev and operations.