---
title: "Jeroen Willemsen -- Security automation with ci/cd"
url: https://appsecpodcast.com/jeroen-willemsen-security-automation-with-ci-cd/
date: 2021-08-06
duration_seconds: 1942
guests: ["Jeroen Willemsen"]
topics: ["Security Testing", "Software Supply Chain", "Cloud and Infrastructure", "DevSecOps and CI/CD"]
audio: https://www.buzzsprout.com/1730684/episodes/8986929-jeroen-willemsen-security-automation-with-ci-cd.mp3
video: https://www.youtube.com/watch?v=Jwu-lPEAgP0
transcript: true
---

# Jeroen Willemsen -- Security automation with ci/cd

*August 6, 2021 · 32 min*

with [Jeroen Willemsen](https://appsecpodcast.com/guests/jeroen-willemsen/)

on [Security Testing](https://appsecpodcast.com/topics/security-testing/), [Software Supply Chain](https://appsecpodcast.com/topics/supply-chain/), [Cloud and Infrastructure](https://appsecpodcast.com/topics/cloud-and-infrastructure/), [DevSecOps and CI/CD](https://appsecpodcast.com/topics/devsecops/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8986929-jeroen-willemsen-security-automation-with-ci-cd.mp3) · [Video](https://www.youtube.com/watch?v=Jwu-lPEAgP0)

## Show notes

Jeroen Willemsen is a Principal Security Architect at Xebia. Jeroen is more or less a jack of all trades with an interest in infrastructure security, risk management, and application security. With a love for mobile security, he enjoys sharing knowledge on various security topics. Jeroen joins us to unpack security automation in a DevOps world. We discuss categories of tools, typical quick wins, potential downsides, and how dependency management specifically plays into automation. We hope you enjoy this conversation with... We hope you enjoyed this conversation with Jeroen Willemsen. Are you trying to build a security champions program? Everyone is these days. One challenge of rolling out security champions is how do we educate all these new folks?

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

About Security Journey  
Jeroen Willemsen is a Principal Security Architect at Zebia.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Jeroen Willemsen:  
→ [Xebia](https://xebia.com/)  
→ [OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/)

Mentioned in this episode:  
→ [Xebia](https://xebia.com/)  
→ [OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/)

Chapters:  
00:00 Meet Jeroen Willemsen: Security automation with ci/cd  
02:21 We'll stay with your original name. No problem there. So we  
04:54 Just diving in here, one of the things I think we're  
07:35 Between SAST, DAST, SCA. You didn't even mention like IAST and  
10:20 That's probably— they're probably stuck on that level of— and so  
13:10 Yeah. And in the danger of creating a monster fight on  
15:29 Like, yeah, yeah, too far back to even remember. Well, I  
17:39 You mentioned one. I had heard most of the ones that  
19:22 Let's flip the table a little bit now. So, we've talked  
22:16 Yeah, I see that. You know, when you're talking about false  
25:27 I have a whole talk on that exact topic on developers  
27:14 I'm going to do something different here for the conclusion of  
29:35 Yeah. All right, you heard our key takeaways, so now it's

## Transcript

*5,822 words · assemblyai*

**0:01 Chris Romeo:** Jeroen Willemsen is a Principal Security Architect at Zebia. Jeroen is more or less a jack of all trades with an interest in infrastructure security, risk management, and application security. With a love for mobile security, he enjoys sharing knowledge on various security topics. Jeroen joins us to unpack security automation in a DevOps world. We discuss categories of tools, typical quick wins, potential downsides, and specifically how dependency management plays into automation. We hope you enjoyed this conversation with Jeroen Willemsen. Are you trying to build a security champions program? Everyone is these days. One challenge of rolling out security champions is how do we educate all these new folks? Security Journey has your answer. We provide a security dojo environment with level-based security education that gives your newfound champions a path to follow. And the best part? It requires almost zero administration by you. Visit www.securityjourney.com securityjourney.com to set up a demo and learn how you can use the Security Dojo to connect with your security champions. Hey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey and co-host of said podcast. I'm also joined by Robert Hurlbut today. Hey Robert, how's it going?

**1:26 Robert Hurlbut:** Hey Chris. Yeah, Robert Hurlbut. Uh, good to be here. Threat modeling architect. and really interested in our topic today.

**1:35 Chris Romeo:** Yeah, and we've spent a lot of time, I would say, in the last year talking about things that intersect in the DevSecOps world. And so we're gonna continue down that channel or that path today in talking about security automation in continuous integration, continuous delivery, maybe even a little bit of continuous something else. But we're joined today, and I'm gonna say your name and then you're gonna correct me because I practiced For seems like minutes, but Jeroen Willemsen.

**2:07 Jeroen Willemsen:** How did I do? Very well pronounced, sir. Jeroen Willemsen. But yeah, it's typical Dutch name. So yeah, if everybody knew we working on non-Dutch podcast or anything else, we probably call me Jay.

**2:20 Chris Romeo:** Well, we'll stay with your original name. No problem there. So we always like to start by asking our guests What is your security origin story? If there was a comic book that described your career in security, what am I going to find in episode number 1?

**2:38 Jeroen Willemsen:** There you will find a poor kid not having any money for playing at a computer, and then with a mischievous friend working out a VBA virus to take over some controls at the school network to be able to play Quake with each other.

**2:52 Chris Romeo:** There is a story. I need more details in that story. I'm sorry, I can't. That is It's a fascinating idea that you wrote a Visual Basic, I'm guessing, macro that generated some amount of control. You must tell me more. I have to know more about this story.

**3:12 Robert Hurlbut:** Yeah.

**3:14 Jeroen Willemsen:** So what basically happened, most of it was written by that lovely friend of mine. Let's not call any names right now. But I basically joined him and figured out a few of those registry keys that we had to manipulate in order to take off some control and then be able to Open a few more network spaces towards each other, so we could see each other in the computer from a direct connection, and then we could play games together, basically. And then we also had some funny buttons written as part of a VBA interface where you could launch Quake and stuff like that. Really silly, but it worked. And on the very next page, you'll see the same poor kid hustling around with smartphones, wanting to play games again because I'm a gamer. Um, and because the games just didn't run on my budget smartphone, I had to go all the way trying to understand how these custom ROMs worked in the early Android days and how to further, um, kill off stuff that I didn't need and how that worked in general. What did it mean security-wise? And then all of a sudden, at one of those forums, you saw a lot of weird things going on in terms of what happened with keywords and whatever you typed in there. And that's what got me interested even more. And that's how we got into mobile security in the first place.

**4:28 Chris Romeo:** So, is that what you say? Is that kind of your primary specialty right now is security in the mobile space or general AppSec, or where do you land today?

**4:36 Jeroen Willemsen:** I think it's general AppSec, but I always have a big interest for mobile because we always wear our smartphone with us and do funny stuff on that thing. So, yeah, always caught my interest basically.

**4:54 Robert Hurlbut:** So just diving in here, one of the things I think we're talking about today is security automation. And I know that, you know, in my own development career, one of the things that we always focused on was how can we automate? How can we automate? But what do you mean by security automation? What does that mean?

**5:14 Jeroen Willemsen:** So security automation is a very broad category of a lot of things that you can automate nowadays. I think most people already in the DevOps world are familiar with the old type of things like applying your SAST, your static code analysis on whatever you have landed there. And then of course you have your third-party dependency checks with something like Dependency Checker. Then of course you have your dynamic analysis. And on top of that, you can have your analysis of the containers you run, of the compliance posture of your cluster where you run your applications on, whether that's on the nodes that serve them or the cluster as a whole. If you talk about Kubernetes, for instance, then you have your cloud compliancy posture automation, however you want to call that, because there's different names to that depending on which vendor you ask, you'll get a different name. But the idea is, of course, to see, hey, are we doing stuff secure enough, or are we compliant with some sort of security standard that postulates what you have to do out there? And then the very next step, of course, is automating offensive playbooks to see if you can actually simulate certain types of attacks towards that stack that you just tried to get your fingers on in an automated fashion. And then, of course, there's the whole automation you can have in triaging findings that you have, security enumeration, vulnerability analysis, the whole vulnerability management in general, as in get insight on whatever you have out there and how you're going to triage that all over your systems and different tickets. So that's more of the— well, what you normally focus on with secure automation, if you talk about that. And then there's this small part where you can do beautiful things like assisting developers developers whenever they create a ticket to work on something. You can also do a lot of automation over there, but I think that's more process automation, I guess. But yeah, that's all the stuff that we talk about when we talk security automation nowadays. And of course, incident response, automated SOAR, blah, blah, blah, all that stuff. So it's very broad nowadays.

**7:08 Chris Romeo:** Yeah, it's a pretty broad grouping. And I'm just realizing, like, because the 3 of us, we play in the AppSec space, we're very engaged in DevOps and DevSecOps and understanding all these pieces. But if I think about how somebody's going to receive that list that's new to— maybe they've studied DevOps, but they haven't really thought about how security goes in. That's a pretty complex equation that you just described, right?

**7:34 Robert Hurlbut:** Yeah.

**7:34 Chris Romeo:** Between SAST, DAST, SCA. You didn't even mention like IAST and RASP. You might have, but those are another potential play. And then you got into the compliance and the container checking and vulnerability management. Like, how do we make this easier? Like, how do— why is this so complex? Why is security automation such a complex problem?

**7:55 Jeroen Willemsen:** That's because we made our software stack a complex problem. You get so many running components before you have any software running nowadays. And then that software itself comprises of many components as well. And for us, to the best of my knowledge, there is no tool that covers everything and just tells you, oh, this is your complete security posture for all these components together. So in order to be able to analyze any of these running components, you need a tool or a process that fits for that given component. Because the component changes, so does the risk with that component, and therefore how you have to detect that. So the security complexity just reflects what we did as software engineers to make stuff also complicated.

**8:37 Chris Romeo:** So we're passing the buck, right? As security people, we're saying, we didn't make this problem. It was the software stack that we inherited that made— we just had to secure on top of it. bit, which you brought us complexity. You should have brought us simplicity.

**8:52 Jeroen Willemsen:** Yes, and possibly budget, because you could have had budget to focus on multiple components altogether. And we see some tools doing that and being successful at it. Then you see the price tag. And if you then go as a developer to your boss saying, I want this tool, your boss will say, wait, what? Why so much? That's an interesting conversation. Yeah.

**9:14 Chris Romeo:** And if you think about that space, like, There really isn't anybody that, to your point about there's no super tool that solves this problem from end to end. Like, there's some vendors that have a SAST play, an IAST play, a RASP play, maybe even an SCA play, but they're kind of like, those are almost like the table stakes of the secure software pipeline. Like, those are the ones that, the categories everybody knows. There's been a million webinars about those and there's a million products that cover those. And so, there's a few vendors that have a a consolidated approach to those, but they tend to not have— you have to almost go to a point vendor to get to container security. Nobody's got a single package that solves all of this. And so, I think that's some of the struggles that we have in implementing this because to my original point, you think about this as someone who's brand new and they're probably stuck asking, why do the people in AppSec have 4-letter acronyms for every tool that they use.

**10:18 Jeroen Willemsen:** Yes, yes.

**10:19 Chris Romeo:** That's probably— they're probably stuck on that level of— and so I think one of our challenges that security automation needs to help is it's not only automating and making things simpler and more repeatable, but there also has to be an angle of how are we making things less complex? Because, you know, I've been hanging around the world of security for, I just realized, almost 25 years at this point. And one of the principles I learned on day one that I've tried to live the whole way through is keep it simple. Simple equals secure. Complex equals insecure or broken. And that has held true throughout my career as I've watched everything happen. I've watched the level of complexity grow to this monster that we have. And you can attribute a lot of security problems to complexity because if there had been a simple answer, then someone would've been able to make the secure choice. It's the fact that they had 27 different things that were all feeding into it and they missed one of them. And then we got a breach, we got an incident that comes out of it. So that's, I guess, my soapbox moment on complexity and security.

**11:24 Jeroen Willemsen:** Totally agree there. Can't agree more to that one. Yeah. So to simplify it a bit is to always look at the context you're operating in. If you're a software engineer, like a DevOps engineer focusing on writing certain code, let's say you're in the Node ecosystem and you're writing TypeScript stuff for a backend and doing stuff like that, then there is a given set of tools that can help you to secure your configure— to validate the configuration of your Node deployment, of the container that's having that, of your dependencies in there, because that's already packaged with the latest version of npm, like npm audit. So, you have some basics. And there's a basic set of tools you can always use to start. If you're one of the guys at something we could call a platform team or site reliability engineering team or the cloud team that basically needs to get these teams that have these Node applications up and running, then you have your own problem space that comes with their own security tooling. The, the, uh, and that separation has always been there. You hardly see SRE teams saying, we'll write better JavaScript code than you do. Um, and you should possibly also not say, we'll be able to better wield your security tools than you do. Just let somebody use the tools that work for their problem space and keep it small. That doesn't mean it's getting less complicated. It just means we can focus on the complexity that's offered to us at this point in time. Unfortunately, I don't have a better answer. I rather would like to say, okay, let's use language X that doesn't have this. There is no such language to the best of my knowledge that is used outside of scientific papers on modeling something scientific without doing anything, unfortunately.

**13:10 Chris Romeo:** Yeah. And in the danger of creating a monster fight on social media, I'm going to share an opinion based on my own study and some people that work with me that have been influencing me in thinking about given languages. And so, the language that some of our developers here at Security Journey have gotten really into is Go. And one of the things they're saying about Go is, and I'm not a Go, you know, don't come after me and say this guy was like, saying that Go is the only way you could do stuff or anything. But what they've shown me is there are some patterns in Go where it's very difficult to have an insecure option because Go is locking you into, nope, you can't even do an ins— you can't even do what you want to do insecurely. Like you, there's, cuz like you, you think about like frameworks, modern web frameworks, there are, there's a lot of good web frameworks that have good secure options by default, but they always give you a way. But we've got this extra routine here for, Workaround. Yeah, the workaround, so that if you have legacy code and you don't want to deal with security properly, you can enable this. And I love, like, is it React that has, like, React has a funny name for it. It's like insecure or whatever, like something like that. And so, to your point about, like, there is no language, when I think of Go and I think of the future, I think that's where our languages and our frameworks need to go to limit complexity is to say, Let's bake those secure defaults in and say, if you want to use our language, this is what you're getting. There is no way to pull the pin and make it insecure. You want an insecure option? Go use PHP. Why is it still the number one language on the internet? That's a conversation for a different day.

**14:54 Jeroen Willemsen:** Yeah. What I really like about Go indeed is that they put it that way. The only problem is not everything that the world's using is available in Go. So, you'll see people linking C-compiled stuff and C++ compiled stuff into Go libraries, and then the whole thing goes back to 1995, which is great because it's a great year, but it might not be a good day for having no security vulnerabilities in your total codebase.

**15:23 Chris Romeo:** It was a great year. Robert and I were both young men at that point.

**15:29 Robert Hurlbut:** Like, yeah, yeah, too far back to even remember. Well, I can remember, but I don't want to remember right now. So far away. Hey, in terms of somebody getting started, they've never done this, they're trying to look at what they can do and switch over to start using security automation. What are some quick wins, typical quick wins that somebody might see when they get started?

**15:57 Jeroen Willemsen:** So it kind of depends on the role you're at. So if you're a Typical software developer creating an application that consists of some code yourself and having those dependencies in, start having a look at your dependencies with open source tooling like the OWASP Dependency Checker and see if you can use that tool to see whatever is going on with your dependencies. Or look at which tool has already been out there for your given language, for instance, like npm audit for Node tools. And there's a few other languages that have their own Typical vulnerability third-party package analyzer as well. Start with those. Keep it simple. Look at if you have a given language, like for instance Java. Start first with actually not rather the security of things, but the quality of your code, so it becomes readable. And after you got the readability figured out, then start looking at extra plugins for those for to check for security vulnerabilities. If you are a typical infrastructure guy running containers, then start with something like Claire or Trivia. Or whatever to start container scanning, just to keep it simple, as lightweight as possible, no complicated client-server technologies. So Trivy would be the way to go nowadays. If you're on— trying to get something done within AWS or another cloud provider, have a look at Prowler or Scout Suite and just start looking at an overall analysis of your cloud security posture. So those are 3 typical things you could get started. to get a little bit of an idea of how well you're running, how well stuff is looking. And then from there on, you can continue growing forever, similar like your codebase might be doing nowadays.

**17:38 Chris Romeo:** So, you mentioned one. I had heard most of the ones that you mentioned. I'm aware of most of them, like Clair and Trivy, from a container security perspective. And one point, just to kind of second something you said, One of the things that we've done in our approach to secure coding is we always make sure we're teaching, you know, the value of linters, the value of prettiers. Like, it's not really a security, it's more of a quality issue, but the higher quality your code gets to, the more secure it's going to be. Like, that's just, that's just common sense. Um, but you mentioned— I've never heard of Prowler. What is Prowler?

**18:15 Jeroen Willemsen:** So Prowler is similar like ScoutSuite, is a tool you can use to, uh, do analysis on, uh, I think right now at least, uh, AWS in terms of your cloud security configuration. It has certain modules to test the security posture. It also has certain modules to aggressively try to exploit given vulnerabilities, for as far as I know. And it's relatively easy to script and to parse the output in that sense, similar to Scout Suite, where Scout Suite is just a few single commands away to get yourself started. Prowler, you can do a modularized approach, for as far as I remember.

**18:54 Chris Romeo:** So it's going to be checking like my AWS, it's going to connect and then grab a bunch of information about the services I'm using and the configuration and then try to give me some— point out some things like, hey, you've got an S3 bucket that's public and wide open to the world. Don't ever do that, please.

**19:10 Jeroen Willemsen:** Exactly. Yes, exactly.

**19:13 Chris Romeo:** I'm going to take a look at that. That's one I'd never heard before. So this is why we do this. I'm here to learn.

**19:19 Robert Hurlbut:** You learn a lot. You learn a lot.

**19:22 Chris Romeo:** So, let's flip the table a little bit now. So, we've talked about a lot of positive things. You gave us some case studies of early wins that we could do from a security automation perspective. But what are the potential downsides of automation?

**19:37 Jeroen Willemsen:** So, the first thing is that automation gives you a lot of data, not necessarily information. The difference is, for instance, if you're new to AppSec in the first place and the tool starts telling you there's a CSRF vulnerability with the given library if you enable the following option, then the first thing we need to ask ourselves, what's a CSRF vulnerability? And B, where did I, or did I never enable that option? And C, if I didn't, did it enable it by itself? That's a whole lot of things we need to research before we can continue. That's not just for one finding, but for many findings. And we know if we don't and it's enabled, then people might be able to exploit that CSRF vulnerability in our web application. We're in trouble. So we're kind of forced to start doing that. Before that, we could run away and move ahead. But the amount of information that comes from this, or first day like this, is huge. And then we'll see a lot of, for instance, false positives that tell you like, hey, there is this vulnerability reported on this binary you have in your Docker container. And the only reason you're having that, because you're having some sort of fat container that used this binary to install something else, and then we removed it. But yeah, given that your tools only look at layers and not at the total composition of things, we got this reported. And before you figured out that when you try to find a tool inside your container, you're a day ahead finding out it's not there, you start wondering why, and, you know, the whole thing that happens with typical container security. And then you realize, okay, we can suppress this false positive. So there's a lot of work That comes from triaging, and we also have to make a lot of more tougher decisions. Like hey, this is a typical vulnerability that I found, and with this sample exploit code that you can sometimes find on the web on certain vulnerabilities, I see I'm vulnerable right now, but the maintainer says not my problem. I'm not gonna patch this ever. What are you gonna do? That's a whole different subject again. So. We shift from not knowing at all to understanding we got trouble. It's actually quite similar for most dev— for most DevOps. So when you start building your first code as a typical script kiddie without doing any actual testing, and the moment you start ramping up your end-to-end tests, your integration tests, your unit tests, you find out, ooh, my code might not work as I intended. That's a lot of work. And now we do the same thing in the security space. We find out we might be in trouble, have to find out whether we are for real, and then fix it. So we just got a lot more work out of that. Work that's useful, bringing value, but a lot of work depending on your stack.

**22:15 Chris Romeo:** Yeah, I see that. You know, when you're talking about false positives, you're talking about care and feeding of the secure software pipeline. Those are things that are definitely downsides to implementing security automation. So who do you see as the people that have to deal with that care and feeding? Is that the SRE, the site reliability engineer? Is it the security engineer? Is it a cross-platform collaborative-style team that's doing that care and feeding? Or what's the source, or who's providing the resources there?

**22:47 Jeroen Willemsen:** It heavily varies and depends on how you organized your DevSecOps organization in the first place and depends on how much freedom a team has to do stuff. But the higher you start, the better it is. I mean, we can focus all over the place on typical vulnerabilities in our application code running inside a container that might allow for privilege escalation. But if we have this running on Kubernetes and we just basically made sure that nobody can run as root and that there's no readable file system and we lock down all of the privileges that could possibly be there, yeah, good luck running as trying to escalate. Where are you going to escalate to? There's nothing to hold on to. Um, have fun. Um, we'll just ditch the container every now and then and move ahead. At the same time, that doesn't mean that there's no problem. It just means we localize the problem to that given container. So yeah, we should start high, but it doesn't mean we shouldn't do the lower-hanging fruit as well, because eventually we want to make sure we get proper control over the process which is currently vulnerable for being— well, for having its control taken over. So yeah, we start with SRE for the— again, focusing on the tools that they have to wield to secure their posture as a security team, that is. And then together with, for instance, platform teams or others, trying to create similar tooling for the DevOps team. And sometimes you do that with the teams because they have the freedom to run this themselves. And then you have to look for which team is capable to do this because you do need to understand the stack you're running with. And that varies per developer, what do they know. Sometimes I get people at my desk saying, oh yeah, it's my first year as Java developer. I didn't even know that this part existed. And then we just, you know, direct them to Java experts, not to the security team, but to Java experts first. Because like you said yourself, clean code, Good coach starting point. It's not the security team. But after that, you know, you have to find teams that you can collaborate with to develop those parts of the pipeline in a way that it's sensible for the developers. Because the moment you do this belly staring as a security team, takes a little while before some of those parts of the pipeline might be discontinued, or they find bypasses or other funny things. So yeah. Try again to collaborate in the space where the tool is aimed at. So, you know that the moment you have to do the carrot feeding, you can do it in a sensible way that actually speaks the language of the user. Because otherwise, it's a lot of discussions and thou shalt because I'm security. That's not how we build relationships right now, I hope.

**25:27 Chris Romeo:** I have a whole talk on that exact topic on developers dislike security. That's what it's called. And it's— you summed it up there in that one statement. It's us as security sitting there going, well, you know, we're security and we know what we're talking about. You know what? That's an antiquated look at the world. And for most of my career and Robert's career as well, that's what we've seen. That's even what we did. But there's a number of people that are opening their eyes and realizing, like, it's about collaboration. It's about empathy. It's about working with these developers. and seeing how can we work together versus saying, oh, I'm from security, of course I have the answer. I don't have all the answers. You heard it here first, right? I'm from security and I don't have all the answers.

**26:11 Jeroen Willemsen:** Right. In fact, in these conversations, if you put it like this and you keep it close to whoever you're working with, a security team, you'll learn so many cool things. I've seen the evolution of Java through the eyes of Java developers. I thought I knew Java a bit, Turns out I do a lot more now, still have a lot more to learn. But overall, it's been a beautiful journey to work with them, similar to the guys who, you know, moved from Java to the Go ecospace and figured like, let's do this more natively because, hey, scratch containers, that's easy to maintain. Let's do this stuff. And it has been a beautiful journey. I wouldn't have learned this myself. And I really hope that most people that have a directive position like security or architecture or whatever mid-level management in terms of operation lead, out there will eventually do the same thing because it's the guys typing the code that actually know. It's that simple. Or eventually know. You know, everybody has to start somewhere and grow, blah, blah, blah, but eventually you'll get there basically, and possibly faster than we security people do.

**27:14 Chris Romeo:** So, I'm going to do something different here for the conclusion of our episode. Robert, I'm going to go first, but I'm going to come to you next for a key takeaway. We're each going to share a key takeaway, and this is completely off the script, but hey, sometimes we just got to mix it up and try different stuff. And I would say that the thing that I really took away from this conversation was the complexity that security automation does bring. I don't know why I just hadn't thought of it from that perspective until we went down this road and I started thinking about this through the eyes of somebody who is not a security person, is perhaps maybe like, let's say, a mid-level developer, someone who's been coding for 5 years. They're, you know, they're still early in their career. They're still trying to figure out how everything fits together. It's like, that seems like it would be so overwhelming, all of that security stuff we just piled in the back of the dump truck and dumped over on top of them. I'm just envisioning this developer stuck underneath this pile, you know, of all these tools and technologies and things. And so that's really opened my eyes to say, how do we break it down? How do we make it more simple? So that's my takeaway. Robert, what's your takeaway before we go to back to you, Ron.

**28:22 Robert Hurlbut:** Yeah, I would say similar. I mean, one of the things that was mentioned was about data versus real information. I can remember that would be as a developer or working with developer teams is, okay, here's your list of all the things we found. And out of that list, maybe, you know, 20 out of 1,000 or something like that might be real vulnerabilities they need to look at and think about. But you give them the 1,000 list or they receive the 1,000 list and they look at it like, what do I do with this? And so yeah, it really calls out that we've got a lot of great tools and we should look at it, automation, because it really does bring some value. But we also need to think about how do you parse that data into real information that can be usable and actionable by those developer teams to, to do some, some good work. And, and they want to. I mean, most developers I know, uh, being one for many years, you want to do good work. But if you're not given something that you can actually act on appropriately or quickly or understandably, then yeah, it's just, it's just noise.

**29:34 Chris Romeo:** Yeah. All right, you heard our key takeaways, so now it's time for the call to action here. So, Jeroen, what do you want our audience to take away? Like, what do you want them to go do now as a result of our conversation?

**29:48 Jeroen Willemsen:** 2 things. First thing is for all the DevOps people out there that don't have that many tools in there yet, start looking at your operating space. Start looking, just putting the terms into Google, as in if you're an SRE engineer, You heard Scout Suite, you heard Prowler. Start Googling it, see if you find alternatives. If you're just one of the guys that creates Docker containers, start looking for this Clarity, this Trivy, and other stuff. Just start looking for the different tools out there. If you're a security engineer and you're listening, other than reducing the signal-to-noise ratio, make sure that you also secure the pipeline that you use to actually use these tools. Skipping might be one problem. Don't forget about the massive problems that you have when actually attackers take control over that pipeline as well. So don't just let other people use the tooling that you want them to use. Use them yourself first. Make sure you're in good shape. Otherwise, we're in a far deeper pile of poo than we would have been if your developer forgot something.

**30:52 Chris Romeo:** That's very helpful. That's— those are some really some call-to-action items that you can really sink your teeth into. Go look at the tools and, you know, for security people, understand the pipeline, understand what you're putting people through, because that's, you know, you have to understand it before you can ask other people to do it. So, Jeroen, thank you so much for sharing your knowledge with us today, with our audience, about automation. And I know you've challenged my thinking on a number of different things, and I'm going to go check out Prowler because I've never— somehow I've never heard about this tool. So, I love the fact that that I learned something new today about a tool that I didn't know even existed. So thank you for, uh, for being with us, and we'll invite you back sometime in the future in another episode to talk about something else in regards to DevSecOps. Or maybe there'll be something new by that point. Maybe there'll be some new methodology, who knows. But thank you once again for your time and have a great rest of your day.

**31:46 Jeroen Willemsen:** Thank you so much for having me here. It's been really an honor and it's been a pleasure. Thank you so much.

**31:53 Chris Romeo:** Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast and on the web at www.securityjourney.com/resources/podcast. You can also find Chris on Twitter @edgeroute and Robert @RobertHurlbut. Remember, with application security, there are many paths, but only one destination.

---

Source: https://appsecpodcast.com/jeroen-willemsen-security-automation-with-ci-cd/