---
title: "Julien Vehent -- Securing DevOps"
url: https://appsecpodcast.com/julien-vehent-securing-devops/
date: 2018-08-14
duration_seconds: 2055
guests: ["Julien Vehent"]
topics: ["Security Testing", "DevSecOps and CI/CD"]
audio: https://www.buzzsprout.com/1730684/episodes/8122677-julien-vehent-securing-devops.mp3
transcript: true
---

# Julien Vehent -- Securing DevOps

*August 14, 2018 · 34 min*

with [Julien Vehent](https://appsecpodcast.com/guests/julien-vehent/)

on [Security Testing](https://appsecpodcast.com/topics/security-testing/), [DevSecOps and CI/CD](https://appsecpodcast.com/topics/devsecops/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122677-julien-vehent-securing-devops.mp3)

## Show notes

Can security become a normal part of DevOps without turning every release into an audit? Julien Vehent, author of Securing DevOps, shares what his team learned protecting Firefox services at Mozilla. He explains why security engineers belong inside product teams, how short checklists translate large security requirements into work developers can actually complete, and where creativity still matters. Julien challenges the idea that everything must be automated, showing how automation frees specialists to investigate the problems that require judgment. The conversation follows real examples involving Content Security Policy, bug bounties, website security grades, and testing in delivery pipelines. He closes by describing continuous security as a feedback loop that turns operational lessons into better requirements, controls, and engineering practices.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Julien Vehent:  
→ [Julien Vehent’s website](https://j.vehent.org/)

Mentioned in this episode:  
→ [Securing DevOps by Julien Vehent](https://www.manning.com/books/securing-devops)  
→ [Mozilla HTTP Observatory](https://developer.mozilla.org/en-US/observatory)  
→ [ZAP](https://www.zaproxy.org/)  
→ [SSL Labs Server Test](https://www.ssllabs.com/ssltest/)

Chapters:  
00:00 Securing DevOps with Julien Vehent  
01:54 Julien’s security origin story  
04:51 Defining DevOps as engineering practices  
06:33 The practical story behind Securing DevOps  
07:32 Making security a natural part of building software  
10:28 Putting security inside the product team  
13:11 Turning security requirements into checklists  
16:11 Leaving developers room for creativity  
17:15 Where manual security work still belongs  
21:23 Mozilla’s experience with CSP and bug bounties  
25:12 Observatory, SSL Labs, and pipeline testing  
26:35 Continuous security as a feedback loop  
30:31 Learning security by building real systems  
32:39 Room to improve DevOps security

## Transcript

*5,548 words · assemblyai*

**0:03 Chris Romeo:** Hey folks, in this episode of the Application Security Podcast, we're joined by Julien Vehent to talk all things DevOps plus security. Julien's new book is called Securing DevOps: Safe Services in the Cloud. It's his story of the journey he went through building security into DevOps in his job. The thing I love is that it's based on real-world experiences. We're excited to announce that we're giving away four digital copies of Julien's book. To enter the giveaway, quote one of the tweets about this episode and tell us what you learned. Don't forget to include the hashtag #AppSecPodcastGiveaway. Winners will be chosen on Monday, August 20th, and announced via the AppSec Podcast Twitter account. One more thing: the good folks at Manning Publications, publishers of Julien's book, provided. AppSec Podcast listeners a permanent 40% discount code on any books on their site. You can find that code included in the show notes and on the AppSec Podcast website. Enjoy. The Application Security Podcast. Here we go.

**1:37 Robert Hurlbut:** Hello friends, and welcome again to another episode of the Application Security Podcast. We're into our 4th season, and I'm joined here with Chris, and we have also our guest today, Julien Vahint. Thanks for joining us, Julien.

**1:52 Julien Vehent:** Hi, pleasure to be here.

**1:54 Robert Hurlbut:** So one of the things we do when we get started is that we ask those who, who join us if you could tell us your security origin story. How did you get into security?

**2:05 Julien Vehent:** Right, um, well, I got into computers in, in the '90s, you know, like, uh, like most kids, um, who were done using a Nintendo and started using computer to play video games. And it's really until I got into college that I got interested into programming and networking, mostly because I started using Linux. And at the time, Linux was the controversial choice. And I was working in a government agency, and I tried to plug a Linux box there once and almost got fired for it. But it got me very interested, and I started looking into the guts of Linux more. And I got really interested into the way Linux was doing packet filtering, so iptables. And that got me really into programming as well. So C code and network security and a bit of cryptography. And I continued my studies and continued around the world of network security. I did my master's thesis on honeypots at the University of Maryland. And then I went back to France and worked for banks for a while, got into application security there, essentially working on web portals for banks. And I came back to the US in 2010, and at that point, I really wanted to work more closely with operations. And I took a couple of jobs at smaller companies in helping operations teams integrate security. And that's when I discovered the world of DevOps. And I started working on automation, infrastructure as a service. These were the early days of AWS adoption in a lot of those companies. That's when I got to learn a lot of the tools and techniques that we still use today. And now I've been at Mozilla for 5 years, and I've done a bit of everything at this point, from remote forensics in Go, TLS auditing, hardening cloud infrastructure, etc. And lately I've been working mostly on the Firefox backend infrastructure, so the services that Firefox browsers talk to, and the release engineering platform that takes the Firefox source code and compiles updates. And my team is focused on securing that entire environment and providing, say, secure cloud services to all the Firefox users.

**4:17 Robert Hurlbut:** Okay, great. I like how you, when you got started, that you said there was, you tried to put Linux into the IT environment and then it almost got you fired. It's interesting how that propelled you to learn other things.

**4:33 Julien Vehent:** Yeah, I mean, that was bad. If you remember, that was a day where Microsoft was heavily marketing against Linux, like essentially considering it harmful. And yeah, I remember that discussion with my boss. That wasn't a comfortable one, but I don't know, maybe I was stubborn, but I had a feeling that this was the future and it turned out to be correct.

**4:51 Robert Hurlbut:** Yeah, it seems like it's done well for you and led you to many other good things. Well, you mentioned the word DevOps, and so that's what we're going to be talking about here today. That's a topic that we've sort of touched on with a few of those that we've had on the show before to just to talk about DevOps here and there. But let's dive in today. We'd like to know, what is your definition of DevOps? What is it to you? What does it mean to you?

**5:20 Julien Vehent:** That's a very interesting question, because if you ask 10 different people, you'll have different answers. Everybody defines it depending on what they care about and what they need. I think my perception of DevOps is that it's really a collection of engineering practices, and it's not one set of practices specifically. It's more of a set of concepts to make it easier to manage cloud services or services on the internet in general, reduce the cost of bringing those services to the internet, and reduce the cost of managing them long-term. In the book, I define it as the process of continuously improving software products through rapid release cycles, global automation of integration and delivery pipelines, and close collaboration between teams. That's a bit of a mouthful, but I think it captures the 3 areas that are really important to DevOps, which is fast release cycles, automation, and collaborations. That really is DevOps at the core. Often, we only talk about the technical aspects, but I think the aspect of collaboration between teams, the Dev and the Ops talking to each other and working together, is really critical.

**6:33 Robert Hurlbut:** Right, yeah, I've heard quite a bit about, you know, culture. There's that communication, there's— it's not just a technical aspect of DevOps, but also the culture, the community working together. You mentioned a book, which— what is your book that you're working on?

**6:47 Julien Vehent:** Well, so it's called Securing DevOps, and it's basically the summary of all the work we've been doing on the Firefox Services side trying to bring security and high security to these cloud services that we build every day. I wanted to teach, to write a book that actually will teach developers or junior security engineers or ops people how to integrate security into their DevOps processes. The book is a very practical, essentially almost like a class, almost like a course, on how to integrate security into a DevOps infrastructure.

**7:32 Chris Romeo:** And so, Julien, I know there's a lot of different terms that get thrown around here, and so before I ask you this next question, I actually have a confession to make. Not a bad confession, but I've actually been using a tweet of yours in a talk that I do about application security and DevOps, and I've probably presented it 25 times at lots of different conferences And I kind of knew who you were, but now I'm actually talking to you, which is pretty cool. But it's the one where you said, can we stop the SecDev, SecOps, Sec naming foolishness? Just call it DevOps and focus on making security a natural part of building stuff. And so, just wanted to tell you, I love that tweet. I've used it 25 times at this point, but I think it really just gets down to the essence of what I think your book is talking about and also what people need to do when they think about DevOps and security. So, tell us a little bit about this alphabet soup thing.

**8:23 Robert Hurlbut:** Yeah.

**8:24 Chris Romeo:** that can be an issue?

**8:24 Julien Vehent:** Yeah, I think it's always an interesting discussion to have. I mean, the old joke is still true here. There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-one errors. And that's really what we're focusing on when we debate DevSecOps versus SecDevOps versus whatnot. There is an interesting— so the sarcastic answer is that I think security people felt left out and really wanted to integrate security in the middle of DevOps. That's DevSecOps. SecOps thing. So there was a bit of a knee-jerk reaction by security people, but there's probably a deeper problem here that we had to address a few years ago. And that was also part of the motivation for me to write the book, which is that security people were very, very slow at changing the way they approach integrating security into complex DevOps infrastructure. I've had a lot of discussions with security engineers who were still stuck on technology that were very popular in the early-mid-2000s but don't play well once you're in a full DevOps environment or you're running your infrastructure in the cloud or things like that. A lot of people who had adopted DevOps and started thinking about how to do this right needed kind of a marketing term to change the mindset of the rest of the security community. why the DevSecOps, SecDevOps, and everything took over. I actually don't use any of those names in the book, kind of on purpose, because I didn't want to make it about this. I think part of the problem with these names is that they focus— when people say DevSecOps or SecDevOps, they focus mostly on testing automation. That's only a small part of what DevOps security is about. There's a whole lot more to it.

**10:19 Chris Romeo:** Yeah.

**10:21 Julien Vehent:** That's also why I don't like to use the term because I feel like it's often misused and it covers only a very, very small part of the problem.

**10:28 Robert Hurlbut:** That makes sense. In terms of continuing on this understanding of security combined with DevOps, tell us about some ways that you can integrate security with DevOps. Right.

**10:47 Julien Vehent:** When we talk about security in DevOps, it really means that your security team needs to be a member of the product engineering team, not a separate entity that shows up 2 hours before launch and requests a mandatory security audit. If you look at modern product teams in fast-paced organisations, they're usually composed of product managers, developers, SREs, security, QA, user experience, etc. All of these engineers may belong to different teams and different groups, but they get together to form a product team that will work on building a specific product. This is where security needs to be embedded in that product team. What we're really looking for when we want to integrate security into DevOps is that collaboration aspect. If you have X number of security engineers in your team, make sure they are embedded with product teams, that they are part of these engineering discussions very, very early on so that they can advocate for specific security controls. And they can also start doing security work for these products very early on. Like, for example, the developers may decide to start writing some functionality of the product. The security engineers embedded with that team can start writing security tests for it or can start doing code review. or can start running through a security checklist, etc. That way, the security verification of the product happens as it is being built. When we get to launch day, we only basically do a final checkup saying, have we done all of our security work on this? If so, then great, let's go, let's launch this thing. That's really, to me, the security in DevOps approach. Then we use a number of tools like automated testing, integration in CI/CD pipelines, etc., to achieve this. But the key component is that the security team needs to be part of the product team. That ties nicely into what DevOps is initially, which is developers and ops talking to each other and working together as opposed to being in 2 separate departments and communicating through ticketing systems, for example. DevOps broke that Chinese wall between those various teams so that people could ship products more efficiently. Security in DevOps is basically the same thing. Take your security people and go put them in those teams, So that they can work with them better.

**13:11 Chris Romeo:** So I got a specific question about something you said that I think is interesting to people who maybe are coming from more of a classic or traditional AppSec background where maybe they started on waterfall, maybe they were working on agile, but they're just now coming into DevOps. So you mentioned checklists. And so when I think of checklists, I think of checklists as a more refined or an easier to consume version of security requirements. But when you say checklist, what do you mean by that?

**13:42 Julien Vehent:** Yeah, I think that's a good definition. You need security requirements that are probably going to be very long documents that explain why we want to do something and what are the security concepts we want to attach to a specific problem. But those are only really useful to security teams themselves. You're not going to give a 200-page security principle document to developers and say, go implement this. To me, the checklist is the practical implementation of this. It's the practical implementation of those requirements in a specific environment. So what we do with our checklist is we will have, for example, a web application security checklist that says that every website that goes out must have a content security policy, and the default CSP must be this particular value. And then developers can tweak it, but the base value, the default one they need to launch with, is mandated by the checklist.

**14:35 Robert Hurlbut:** Okay.

**14:38 Julien Vehent:** We use checklist as a way to communicate very clear security requirements to product teams so that they know from the very beginning what they will have to implement. So we probably have 20 to 30 items in there that we discuss, that we change over time to match what we currently think that the security needs are. And they will be very tactical, very like, for example, sign your Git commits. Yeah. Integrate this particular single sign-on protocol with your admin panels, put your admin panels behind VPN, implement CSP, have a TLS that matches the Mozilla Modern guidelines, etc., etc. And they are very tactical items, very short documents that we put in GitHub issues as markdown with checkboxes and whatnot, and developers and operators can go through them very quickly and make sure they're compliant with our security principles.

**15:31 Chris Romeo:** After the break, we'll continue discussing checklists and how they apply to DevOps and security. The Application Security Podcast operates with support from Security Journey. A security belt program provides the 3 pillars of successful AppSec training: learning, application, and experience. Visit us on the web at www.securityjourney.com. journey.com to learn how you can teach and empower your developers using a new kind of security training. Julien picks back up answering, do developers have freedom in how they approach security checklists?

**16:11 Julien Vehent:** I think in order to be successful, you always have to allow room for creativity. I mean, developers are very creative People, they will always come up with a use case that doesn't fit the checklist. So you always have to be flexible. The question then is, how do you test for things? Because you want to allow them to have, for example, a CSP that works for their very crazy new type of website, but at the same time, your testing logic doesn't cover any of this. So there's a balance here, and that's usually when we end up trying to find a middle ground with the devs. And if we— we use essentially risk assessments. If the site is very, very risky and they want to use a technology that doesn't support our security controls and ultimately that creates new risks, then it's a discussion and maybe we change our mind, maybe they change ours. There is no clear answer here. It's really a matter of do we have a communication channel to talk about these things before it becomes a problem, before it becomes a live service.

**17:15 Chris Romeo:** Okay, and that makes sense that, uh, you know, from, I guess, from the, yeah, the perspective of the, of the devs, they've got some ability to be creative there. And, and that certainly, certainly makes sense because you don't want to stifle their ability to, uh, to be creative. Um, so I'm gonna throw another question out here that it, in regards to kind of the categories of security, but it's, it's more of a principle, or I guess I'll call it a myth. that you'll hear people say that are involved with DevOps, and they'll say, in DevOps, there is no such thing as manual. You can't do anything from a manual perspective. Everything has to be automated. And so, in your experience, how does that fit with things like design time activities that aren't necessarily part of the build pipeline, or it's hard to make them part of the build pipeline?

**18:05 Julien Vehent:** I think the goal of not having any sort of manual operation is a good one. It's more of a strategic goal. It doesn't hold up to reality at all. Even in— like, we see it when deploying new infrastructure, maybe 90% of the infrastructure is deployed programmatically, but you will always have that 10%, this one service that requires manual intervention, etc. Same thing with security. You will probably be able to do— 90% is optimistic. I think at this point we're about to do 30-40% of our work automatically, programmatically, and that's good because we can repeat those tests. But pen testing is a completely manual operation. We have a lot of testing that happens manually because they require user interaction on a web page that has a special type of authentication that none of our tools can replicate. I think the goal of being fully automated is a good one, but it's also important to not dilute the security testing to the point where, sure, you're fully automated, but you're not testing anything useful. To me, the real value of security in DevOps is automating everything that can be automated, the low-hanging fruits, so you can free up time to actually go manually test or implement the complex stuff. As opposed to 10 years ago, we were doing automated tests essentially manually every month on every application. That was very slow, very time-consuming, and we had no time to focus on the smart stuff. Nowadays, we can automate those tests. We can run tests that are very Boolean, pass or fail. For example, is there a CSP? Is there HTTPS, etc.? And so, we can automate those. We can automate the reporting and the regression handling and the notification to developers so that we don't have to worry about it anymore and we can go do other stuff manually.

**20:09 Robert Hurlbut:** So it can really introduce, like you said, some assistance to be able to focus on the things that matter most and that you may have more time to spend now instead of, as you said, in years past where we just didn't have that time and we were focused more on the things that we're trying to— or we should be able to automate now. it sounds like.

**20:29 Julien Vehent:** Yeah, and if you, if you look at how most teams operate their, you know, web application scanning, for example, in, in a traditional world, uh, it was heavily dependent on the engineer running the, the web application scanning. And, uh, 2 engineers running the same tool would report different findings, uh, because of their sensitivity, because of the thing they had in their brain. And the idea, uh, with security in DevOps is that You make it repeatable. You take those tests, you script them, you automate them. Some of it is not scriptable at all, but a lot of it is, so that even if your engineers rotate, you have a turnover, then your tests continue to run the same way. That's the same idea that pushed operations teams to automate their deployments, that they weren't dependent on specific people in order to deploy specific services. They wanted everything scripted and repeatable.

**21:23 Robert Hurlbut:** You know, I hear quite a few stories, have heard a few stories about different companies that have switched to DevOps, but do you have any particular case studies that you know about where this particular model, certainly integrating security into DevOps and so on, has done well?

**21:39 Julien Vehent:** Well, I can talk about my own experience at Mozilla on Firefox Services.

**21:48 Robert Hurlbut:** We—

**21:49 Julien Vehent:** I have 2 examples for this. The first one is addons.mozilla.org, so the site that serves Firefox add-ons to all of our users. And we have been running a web bug bounty program on this site for a long time. And about, I think it was a year and a half ago, 2 years ago maybe, we decided to integrate Content Security Policy on it because we were getting way too many cross-site scripting attacks and we had to pay a whole lot of bounty on it. And we implemented CSP, which took a lot of effort because it's an old website and there was a lot of stuff to modify, to change all these scripts to move and CSS and whatnot. But eventually we got it right and we mitigated pretty much all of our XSS reporting and all of our XSS vulnerabilities on addons.mozilla.org. But the difficulty of this is keeping that CSP in place over time. And this is where integrating your automated testing as a regression test is extremely useful. We've spent a lot of time— I work very closely with Simon Bennetts, who leads the ZAP project. He works in my team. We've been working together for years. And we spend a lot of time on this idea of the ZAP baseline test, which is essentially very small unit test type stuff that we run in ZAP. And some of them are, you know, verify that the CSP is in place and functioning properly. And we've run those, we've implemented those for addons.mozilla.org, and that helped us guarantee that the CSP has not regressed since we put it in place 2 years ago. And I'm 99% certain that if we didn't have that type of regression testing in the CI/CD pipeline, it would be gone by now. Because we tried this in the past, and those features didn't stay in place for very long. And nowadays, we have enough automated testing in the pipeline and we work with the developer well enough with our checklist and our integration collaboration that we can guarantee that new services that go out actually have all of our baseline security features in place. So I don't know if you've ever looked at observatory.mozilla.org. It's a site that scans your web app and tells you if you have your security headers and various security controls in place. But if you have, then you probably have looked at, you know, tested a couple of sites and got a bad letter grade, like maybe a C, a D, or an F if it's really bad. And our goal was to get all of our services out with an A+. So everything in place from day one, which if you've done security in any sort of organization is really difficult to do because you need to motivate your devs to do it early. And last year is really when we launched Firefox Send. The first time that we managed to launch a service was an A+. And since then, we've managed to launch all of our new services with A+, meaning that our testing and our integration of security into the DevOps process is good enough that we have security in place the moment we go live. So that's our experience. Other organizations— Netflix, Airbnb, Google, Facebook— have all talked about similar stories, integrating early enough in the pipeline to get that kind of security in place before they go to production. So I think there is enough evidence in the industry to show that it works if you do it right.

**25:11 Robert Hurlbut:** Right, yes.

**25:12 Chris Romeo:** What was the name of the tool that you said gave you the letter grade on the web apps?

**25:18 Julien Vehent:** observatory.mozilla.org.

**25:21 Robert Hurlbut:** Okay.

**25:22 Julien Vehent:** That's a tool that April King at Mozilla has been working on for a couple of years now. And I helped. There's an HTTP scanning part and a TLS scanning part. And I helped with the TLS scanning and she handles the HTTP scanning.

**25:36 Chris Romeo:** Okay, very cool.

**25:37 Robert Hurlbut:** Okay, yeah, I was going to say, uh, I've seen similar sites that do something like that. I know there's securityheaders.io that Scott Helm put together where he checks for some things on CSP and so forth, but that sounds like another good site to add to the list.

**25:54 Julien Vehent:** Yep, that's right.

**25:55 Robert Hurlbut:** Excellent. Okay, great.

**25:57 Julien Vehent:** SSL Labs is another one. I mean, we— right, I think the, the letter grade aspect is, uh, got adopted by the industry a couple of years ago. And it's good to have, of course, more than one tool. Like, for example, we use Observatory for a lot of our testing because it's nice, it has a UI, the developers like it. But then in CI/CD, we will use Zap in Jenkins to run kind of the same tests, but not exactly the same because Zap will be able to spider all of, you know, an entire website and the subpages where Observatory just looks at the landing page. So it's good to have multiple tools that do different things so you can assert your security in different ways.

**26:32 Chris Romeo:** Absolutely.

**26:35 Robert Hurlbut:** So one of the things you talk about in your book, from what we understand from the table of contents and so forth, is that you talk about continuous security. What does that mean? And, you know, what are some aspects of that?

**26:48 Julien Vehent:** Right. Continuous security, think of it as a feedback loop. That helps you improve the security posture of your organization over time. So it's basically the continual improvement lifecycle that you find in Kaizen or ISO 9001, but applied to gradually making an organization's security better. And it works like this: you start with building your basic security requirement, the stuff that you know, you know, by experience or by, for example, following the OWASP Top 10, is needed. And you write some tests and you run those tests against your services. They're going to fail at first, of course, because nobody has ever done security. But it gives you a starting point to start implementing security in your organization. That's test-driven security. That's phase 1. And you start implementing that and you cover maybe 5% of the entire security scope. You run those services then in production, your production services, and it's the internet, they're going to get hacked, they're going to crash, you're going to have to do incident response, you're going to have to look at your logs to block attacks, compromises, etc. So your services will have to live, and you can collect data on how they get compromised. Essentially, that's phase 2, just essentially handle the stuff that's running in your environment. Phase 3 is take the data that you get out of your tests, Take the data you get out of handling and protecting the services in production. So all of your test data, all of your fraud data, your attack data, and feed that into a very basic risk management framework and build your security posture. What are you exposed to? What is your organization concerned about? What should you be protecting? So for example, if you're running a health insurance website, maybe you're concerned about password management and people reusing their password, which puts user accounts at risk. That will probably bubble up at the very top of your list of concerns. Then you're going to start working on password management, change your requirements, and start writing security tests for it. Maybe you go look at how applications handle passwords, etc., and you run this test in your pipeline. So you go back to phase 1, Test-driven security, and this time you focus on password management, etc., etc., and you loop over that. The next iteration, maybe you'll focus on something else. The idea is you do fast iteration, like in DevOps cycles. You don't try to fit like 50 different tests at each iteration because they're all going to fail. It's going to take you two years to get everything to green, and your your your iteration cycle is going to be way too long. So what you want to do is is add a new test. every time you do a loop over this cycle and make sure that everything goes green so you can flag it for regression if it ever goes back to red. And that's how you iterate very, very quickly, and that's how you gradually improve your security over time. So that's the idea behind continuous security.

**29:57 Robert Hurlbut:** Okay, makes sense. So I noticed that your book looks like it's coming out— we're talking here in August 2018, it says due out in August. So does it come out soon? on the shelves?

**30:11 Julien Vehent:** Yeah, I'm actually being told that the book is being printed right now, so I should be receiving the first paper copy in the next couple of days, hopefully. It's been a couple of years of work, but I'm excited to finally have the copy in my hands and be able to share it.

**30:30 Robert Hurlbut:** Fantastic. Congratulations.

**30:31 Chris Romeo:** I have another question as well. So I know there's a couple of different books that have been written out about security and DevOps and how they come together. And I'm just curious from your perspective, the author. What can our listeners expect? What makes your book different than some of the other things that are out there? Why would somebody, one of our listeners, want to pick up this book and read it?

**30:54 Julien Vehent:** I think the differentiating factor of Securing DevOps is that it's a very practical book. We learn by doing. That's how I learn. I'm always happy to read about new security concepts, but ultimately I need to write some code or build some server or something like that to learn about the new security concept. And that's how the book is designed. So the first part of the book, the first few hundred, a couple hundred pages, are really focused on taking a small web application, putting it in AWS, and it's going to be completely insecure at first. But then we spend 4 chapters looking at each area of security, the infrastructure, the application, the pipeline itself, the HTTPS layer, etc., and actually implementing security on it. So it's kind of a lab as well as a book. So the readers can really set up their own environment in the free AWS account, for example, there's a free tier, and follow along. And there's still a lot of concepts that are discussed in the book, but all of these concepts are backed by actual examples. One of the concerns that people had rereading the book was that it was very specific to one environment. But what we discovered is that the environment we picked is fairly generic, and it's fairly easy for anyone who, for example, doesn't run in AWS but has an infrastructure in a data center to take those concepts and take those techniques and apply them to their own environment. I'm hoping that The selling point of the book is that it's a very practical manual to implementing security into DevOps.

**32:39 Robert Hurlbut:** Okay, great. Well, we'll look forward to seeing it come out and available. Well, Julien, we want to thank you for joining us today. Are there any last thoughts maybe that you'd like to share with our listeners?

**32:51 Julien Vehent:** No, I think that's great. I think the The important aspect of DevOps security is that there isn't a specific manifesto set in stone, and everybody can bring their ideas on how to do things better. We're only starting to scratch the surface. A lot of organizations that talk about implementing security in DevOps have probably done like 10 or 20% of what needs to be done in order to cover everything. There's a lot of room for improvement, a lot of room for new ideas, And I would invite everyone, developers, operators, security people, or even outside of engineering groups, to contribute their thoughts on how we can make this better.

**33:37 Robert Hurlbut:** Thanks again.

**33:39 Julien Vehent:** My pleasure. Thanks a lot. Thanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a favor and visit the iTunes store and give us a 5-star rating. Our intro music is 8-Bit Kung Fu by Born and TJ, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @AppSecPodcast or on the web at www.appsecpodcast.org.

---

Source: https://appsecpodcast.com/julien-vehent-securing-devops/