---
title: "Liran Tal — The state of open source software security"
url: https://appsecpodcast.com/liran-tal-the-state-of-open-source-software-security/
date: 2019-09-05
duration_seconds: 2040
guests: ["Liran Tal"]
topics: ["Software Supply Chain", "Cloud and Infrastructure"]
audio: https://www.buzzsprout.com/1730684/episodes/8122628-liran-tal-the-state-of-open-source-software-security.mp3
transcript: true
---

# Liran Tal — The state of open source software security

*September 5, 2019 · 34 min*

with [Liran Tal](https://appsecpodcast.com/guests/liran-tal/)

on [Software Supply Chain](https://appsecpodcast.com/topics/supply-chain/), [Cloud and Infrastructure](https://appsecpodcast.com/topics/cloud-and-infrastructure/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122628-liran-tal-the-state-of-open-source-software-security.mp3)

## Show notes

Developers may want to own security, but what helps them turn that intention into safer software? Liran Tal joins Chris and Robert to examine Snyk's 2019 State of Open Source Security research. After sharing how running a bulletin board system sparked his curiosity, he explains the report's mix of survey responses, dependency data, and public ecosystem information. They discuss vulnerable libraries in popular container images, why updating a base image can matter, and the hesitation developers feel when dependency changes might break an application. Liran also explores how vulnerabilities can remain unnoticed for years. He closes with three priorities for improvement: make security accessible, treat it as part of product quality, and celebrate developers who find and fix problems.

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 Liran Tal:  
→ [LinkedIn](https://www.linkedin.com/in/talliran/)  
→ [GitHub](https://github.com/lirantal)

Mentioned in this episode:  
→ [2019 State of Open Source Security — developer ownership findings](https://snyk.io/blog/81-believe-developers-should-own-security-but-they-arent-well-equipped/)  
→ [Docker Hub](https://hub.docker.com/)  
→ [Node.js](https://nodejs.org/)  
→ [Libraries.io](https://libraries.io/)

Chapters:  
00:00 Introduction  
01:23 BBS roots and early computing  
04:38 Finding a path into application security  
06:41 Curiosity and learning by building  
11:00 The data behind the open-source report  
12:11 Combining survey and ecosystem sources  
12:40 Developers want to own security  
15:13 Vulnerabilities in popular container images  
17:32 Base images, trust, and practical fixes  
20:13 Updating dependencies without breaking the application  
23:59 Vulnerabilities that remain dormant for years  
26:23 The window before discovery  
27:52 Three priorities for improving open-source security  
31:43 Connecting with Liran

## Transcript

*5,796 words · assemblyai*

**0:01 Chris Romeo:** Laurent Tal is a developer advocate at SnykSec and is the author of Essential Node.js Security. He takes open source and protecting the web very seriously. Laurent and I start by geeking out about BBSs in the days of old.

**0:15 Robert Hurlbut:** Can I get a Sysop page, anyone?

**0:17 Chris Romeo:** Then we go into the state of open source security based on the report that Laurent contributed heavily to and discuss many of the key takeaways from that report. including the developer response to open source security, security vulnerability rates in Docker containers, and the length of time that vulnerabilities lie dormant in open source. We close out with the 3 things Laurent would do to improve open source security if he could only do 3 things. We hope you enjoy. Security Journey and the Application Security Podcast are attending Global AppSec DC. Stop by our booth to talk about the podcast or participate in our Battle of the Black Belts laptop sticker contest. We've created unique and amusing stickers, and every few hours we'll have a new battle going on. Just to give you some perspective, the first battle is Daniel versus Johnny from The Karate Kid with a bit of security humor thrown in. If you stop by, we'll even provide you a demo of our culture-influencing security belt program that your developers will love. We look forward to connecting with you at the OWASP Global AppSec DC.

**1:23 Robert Hurlbut:** The Application Security Podcast. Here we go. Hey folks, welcome to this episode of the Application Security Podcast. We're joined today by Laurent Taal, and we're going to talk about all things open source security and even the state of open source security as it stands right now. But just like everybody else, we're going to start with our question we always ask, and that is, what is your origin story? So Laurent, tell us how you got into security, Go back as far as you want into your history. You know, if your history started as a toddler and you were toddling around going, I want to break stuff, if that's what it is, we'll go that far. But wherever you want to start from.

**2:31 Liran Tal:** Awesome. Lovely to be here. Thank you for inviting me here. And yeah, we can go back like almost, I think, like 2 decades for that. So I'm just reading a book, Cult of the Dead Cow, the origins of that. And That brings me back into the days of bulletin board systems. I used to run a BBS. That's how I entered into the world of, I would say, networking, freaking the whole world of cybersecurity. Around that, the early underground of 1995 internet and BBS.

**3:06 Robert Hurlbut:** 1995, where does that put you as far as High school, college?

**3:12 Liran Tal:** Yeah, that's high school for me.

**3:14 Robert Hurlbut:** That's high school. Okay. And so, you're running a BBS and you're using that as a way to kind of enter this world of getting to the network. Now, was this a BBS with a feed for internet messaging?

**3:29 Liran Tal:** Yep. So basically, I guess my childhood at that age or teenage years have been around this bulletin board system, which I've been running for like 6 years. So, I started from '95 till around 2000, 2001. I've been just bringing it up using a couple of friends. It was based on remote access at that time. I've been using that as just a feed for file downloads. One of the most, I think, familiar sounds to me from that back then is paging the CSOP, the system operator, and people chatting back with you. That's been an amazing connecting experience back then when connecting with people was not that easy.

**4:15 Robert Hurlbut:** Yeah, yeah. So I also ran a bulletin board system in the same timeframe that you're talking about. So you're speaking my language, man. This is like—

**4:24 Liran Tal:** Amazing.

**4:24 Robert Hurlbut:** Bringing me back to the good old days. Now, yeah, I could probably talk to you for 30 or 60 minutes just about bulletin board systems in 1995, but we gotta move forward a little bit. So now was this a— Sure.

**4:38 Chris Romeo:** So, how did you get to security then from that world of—

**4:41 Robert Hurlbut:** so, I understand the foundation of how you kind of got into tech just by telling me you're a bulletin board person, but how did you then get to security?

**4:49 Liran Tal:** I've always been fascinated by those things. So, I actually even named the bulletin board system THC, which used to stand for the Hacker's Choice, which was, if you remember, that was a very popular, very common software hacking group back then. So, it was named after that. And I was fascinated by this world of being just— I think hacking back then was around being curious into what the world had to offer, what systems had to offer, how did things work? And that drew me into 2600, the magazine, the community around it, some hacking groups as well. I wasn't taking an active part in this specific arena, let's call it, but I used to hang around those people and been doing back and forth a lot of that. Surprisingly enough, I haven't done that through that, like my entire career wasn't security focused. It was very software engineering, programming from doing Linux, back then, Linux system administration, going into IP telephony in my career. So a lot of Asterisk and Linux and stuff like that. Then into a bit of embedded and kernel development around like 2, 3 years around that. And from that, like a 180 change into web development and the whole web infrastructure into it. So recently going into joining Snyk was actually very much realization of the childhood that I had been grown up You know, it's like being on kernel mailing list for Linux, you know, being much involved with security back then. So it's now like, I feel like I'm closing the circle or connecting back to like the root origins of my teenage years.

**6:41 Robert Hurlbut:** So how did you gain the knowledge that you have then as someone who's a developer and has made this path between development and ultimately into security? What do you attribute your success to?

**6:56 Liran Tal:** That's a really good question. I think a lot of it is curiosity. So, I was always very determined and curious to do stuff. So, those 2 things go hand in hand. So, I wouldn't call myself the most brilliant software engineer either, but I was determined to do things. I was determined to bring up a BBS to run it. I was determined to build some applications. And for that, I needed to learn some stuff. So I would just borrow books from friends or, you know, whoever had them, or just find it, you know, wherever I could and, you know, just learn what I needed to do something. So I think that is what made it very successful for me.

**7:34 Robert Hurlbut:** Yeah, and I think those are 2 qualities that folks that are new getting into this field need to understand is you do have to have a certain amount of curiosity about the technology that we're protecting.

**7:50 Chris Romeo:** This is—

**7:50 Robert Hurlbut:** I don't feel like this is an industry where you can be successful where this is just your day job. Like, yeah, you know what? Security, I don't really like it that much, but man, it pays a lot of money. It really pays the bills for me, right? That's not— those people are never successful.

**8:04 Chris Romeo:** Mm-hmm.

**8:05 Robert Hurlbut:** It's the people that have the curiosity to say, I really want to know how this works, but also the determination to say, I'm going to make something happen here, and I love the tech that sits behind it. So, Yeah, that's great. Great to understand kind of your perspective and where you're coming from. And so, let's talk about this big problem that we're going to discuss today, the state of open source security. And I almost frame it as a problem because we know we haven't solved it yet. So, there's the— I should have said spoiler alert.

**8:35 Chris Romeo:** Sorry.

**8:35 Robert Hurlbut:** Anyone that was listening that thought we had this thing figured out, I hate— I'm sorry to to break through.

**8:41 Liran Tal:** Far from it.

**8:42 Chris Romeo:** Far from it.

**8:42 Robert Hurlbut:** So, let's start out with, I know that you were an author of this thing called the State of Open Source Security Report. Let's start by just tell us a little bit about what that is and why it's important.

**8:55 Liran Tal:** Cool. So, as you said, I think framing open source in general as well is very outreaching in terms of all the layers that, you know, it touches. So, it is both the application languages that we use. So, whether you use .NET, you know, PHP, JavaScript, Python, all of those language ecosystems, but it's also more than that, right? It's the operating system as well. So these are containers and operating system-based vulnerabilities that we have, and application-level vulnerabilities. So it kind of extends and lends itself because open source is a lot, you know, and I didn't even talk about open source hardware, which is, you know, it's— I'm not gonna even go there, but we have that as well. So all of it is kind of open source and security applies to all of it. So that's really the big thing that we've been trying to kind of take a good look at and examine. You know, what is the state of that in containers? What is the state of that in application security? As in, are we seeing more vulnerabilities? What are they like? What is the rate of finding them? Are they diminishing? Are they increasing? And part of, I think, the interesting point of this report, it's like 50-something pages, but it's mostly data-oriented. And it's mostly like stuff that we took from what we know, like as Snyk scans a lot of open source projects, not even open source as well, so like all of customers' data. And we only look at manifest files, so we only know what packages you're using. We don't care about the code itself at this point. So we can take all of that and figure out where are we finding most of the vulnerabilities, which is what I'll talk about today in terms of kind of key takeaways and key points that we should probably pay attention to. But aside of that also, A lot of the reports really got into survey, right? So asking people, you know, how do they, you know, do developers want to take ownership of security? And this is, I think, by itself a very interesting question, not to, you know, talk more about the, you know, the answer for that, which is, you know, I think more surprising and optimistic. So, yeah, it's been a very encompassing report.

**11:00 Robert Hurlbut:** And so the data for this report comes from just to make sure I understand, comes from the manifest files. So, it's customers that are using Snyk to scan their binaries and scan their applications and things that they're doing. And so, you're able to get a feed of that data in an anonymous way and then determine where the actual vulnerabilities lie. And so, this report is based on real data, real-life information from applications that are running all over the place.

**11:33 Liran Tal:** Yeah, we basically scanned that. The other source of data that is not survey or Snyk related is GitHub, like public repositories data that we had access to. GitHub has this data on GitHub Archive, so we can just query BigQuery for that or Libraries.io. We can just generally just reach a lot of ecosystem-related package managers that provide us the data so we can ask other questions, not even security related, but Are we seeing more packages added to RubyGems or Go? So we know how the ecosystem evolves in general and then apply some security questions around it.

**12:11 Robert Hurlbut:** Was it difficult to put this data, this set of data together from all these different sources?

**12:17 Liran Tal:** It took a bit of work. I wouldn't say difficult, but yeah, I think it was more interesting to figure out what are the interesting areas to look at to pile together all the data. So like, what are the interesting questions? What are the interesting outcomes that we would be, you know, very wanting to kind of, you know, expose outside and, you know, share them with everyone else?

**12:40 Robert Hurlbut:** So before we kind of walk step by step through the findings, what's the— what's kind of the most controversial thing that you discovered in this, in going through and creating this report and going through the data? The thing that I would say, I don't— controversial might not be the right word, but the thing that you let— you least expected. that kind of surprised you the most where you're like, oh wow, I didn't really know that? Is there any one thing that you can kind of point to?

**13:08 Liran Tal:** Yeah, I'll point maybe 2 items from 2 different data items so we can talk about them more in length. One is from the actual survey. So, this was a surprise, a good surprise for me. So, we asked people, you know, the question of, you know, who is responsible or, you know, do developers want to take responsibility for open source security? which is not very likely that people will say yes because developers take, especially with the rise of the full-stack developer terminology, they are in the midst of everything. They maybe make up their Dockerfiles for containers. They worry about frontend, they worry about backend, they worry about deployments, about performance, about accessibility. So many things that developers own as responsibility for their apps. So, when you ask, are they going to be responsible in taking ownership for open source security? I was pretty surprised to know that 81% of them said that they would be, are the direct ownership for that. And that's very astounding for me in a very positive way that I know that to have this feeling that developers actually wanna make open source security good, right?

**14:15 Robert Hurlbut:** What's the sample size on that to get to that 81% number?

**14:20 Liran Tal:** Hundreds of developers. So, it's not too big, but I think we had somewhere between 500 or 600 developers answering that.

**14:29 Robert Hurlbut:** Okay. That's statistical significance for me. So, it makes sense. It's big enough that, I mean, if you told me it was 3 people over lunch, it'd be more of a stretch. But—

**14:40 Liran Tal:** Yeah, I know.

**14:41 Robert Hurlbut:** 500 to 600 devs with 81% of them coming in with that. That's actually, yeah, that's a really positive point that really should challenge a lot of people, what a lot of people believe.

**14:53 Chris Romeo:** I agree.

**14:54 Robert Hurlbut:** I agree with it. It makes sense to me. And I've had the chance to see that same impact. in some different things I've done in my career where developers really do want to care about security if you connect with them correctly. But I think that's gonna challenge a lot of people's thinking, which is good, across our industry.

**15:10 Liran Tal:** Mm-hmm. Yeah, I agree, for sure.

**15:13 Chris Romeo:** What was it?

**15:13 Robert Hurlbut:** So, you had 2. That was— so, that's the first one that was surprising. What was the second one?

**15:17 Liran Tal:** Yeah, so, the second one was related to Docker and containers, and that one actually went pretty viral on, you know, Hacker News and Reddit and stuff like that. So, basically, what I was looking at was also, you know, Docker containers. And, you know, as Snyk is able to also find vulnerabilities in that, we would want to know the same thing as with manifest files is, you know, are we finding, you know, vulnerabilities, security vulnerabilities in those containers that we scan for customers? So this was actually just based on what we scanned and, you know, not external data, but that's a lot as well. So the takeaway was, you know, each of the top 10 most popular default Docker images that I just took from Docker Hub, so like the top 10 that I have there, that you would open the page, you would see the top 10 most popular, tens of millions of downloads, each of them had at least 30 vulnerable system libraries. That was pretty shocking. If you would, for me as a developer, before joining Snyk, having a very security-oriented mindset, but still a very developer mindset as well towards delivery and building stuff, etc., I would go with my team previously, I would edit, create my Dockerfile, I would do FROM node-something version, etc., and we take it. But I will probably not give a lot of importance or significance to which image I'm actually pulling, like Node, but which version, LTS or whatever. That would be something that people would just take a default and run with that because that's mostly something that they do not attribute security risk to. But the thing is, if you just pull that off, with Node, we actually— Node specifically, we found something like 400 or 500 system vulnerabilities, security vulnerabilities in system libraries. Even if you take all the top 10 that we had there, I'm not going to name names, it's all in the report, etc., but popular images like Nginx and MongoDB and MySQL, default images for those things, they would at least have, you know, 30 vulnerable system libraries. So that was pretty shocking. And, you know, as, as we kind of spread the news for that, that became a pretty viral, you know, top 1 post for, I think, a couple of days on Hacker News or something. So that has been, you know, kind of controversial if you think about it.

**17:32 Robert Hurlbut:** Yeah, I saw a number. And now it's all, it's all clicking for me here. There was a number of different news articles that picked that up, and I didn't realize you were the source of that. But that's great because people need to know. that this is happening and people think that, you know, especially with Docker and containers, hey, we're in this safe zone because the people maintaining the Dockerfiles are going to be taking care of this stuff for us and making sure everything is up to date. And the answer is actually no, they're not. You still got to check them yourself. That's great. So 2 different things, the developer's responsibility for open source security and then Docker and containers. containers. So, um, I guess what other key findings did you take away from this report, even if they didn't surprise you, but just in general, what were some of the other key findings?

**18:19 Liran Tal:** So, so continuing, continuing on maybe from, from containers, right, we also want to kind of, I think, uh, build a kind of a trust, uh, I would say responsibility, in terms of how we actually, actually not only report on vulnerabilities but actually fix them. So The thing is with that Docker containers and all of those top 10 is 40%, it's 44%, I think, of all those scanned Docker images that we had in the dataset, we could have fixed those known vulnerabilities just by updating the base image. So like if you would just move from node 8 to node 10 or 10-something, that would already remediate a lot of the vulnerabilities that you had. So this is, I think, like an important takeaway because as I see a lot of what's going on with open source security and general information security and application security is we are shifting into that state, I think for a couple of years already, that we do not just want to alert you, tell you that there's a vulnerability, we actually want to help you fix it. We want to take those who are empowered to fix it, which as we can see is developers, as they say for themselves, and we want to be able to help them to just remediate those vulnerabilities. The fact that out of those scanned images that we had, all of that dataset, almost 50% of that you could just remediate to a certain degree just by updating your Docker image tag. That's really important because I think this is something that we take for granted maybe for application dependencies. You update them, for sure you're going to remediate some security vulnerabilities, etc. But here with Docker containers, I think that while they are not long-lived in a term, as in you can kill them, they would come back up, etc., but I think not a lot of people are thinking about the actual base image tag that you are extending your image from. This has been, I think, a really big takeaway as well. Just the fact that you can fix it very simply, very easily.

**20:13 Robert Hurlbut:** Do you think that— I mean, I understand that completely, but do you also think that some people are fearful about doing that in terms of breaking existing systems or code?

**20:25 Liran Tal:** Oh, for sure. Yeah.

**20:27 Robert Hurlbut:** How do you communicate that, there's one maybe overrides the other in some cases in terms of the pain, ultimate pain.

**20:35 Liran Tal:** For sure. I think we can take it from the application perspective as well. If you had, for example, if some package was vulnerable and it's 1.00 and the fix was only in 2.00, so that's a major upgrade. People from SemVer perspective would be afraid or concerned to make that upgrade because they do not exactly know what APIs are going to break. From application perspective, it's the same thing. That is why it is beautiful when maintainers would apply security fixes as patch or minor fixes because you would convey that this is a security fix, but we do not break an API. It is easier for people to just upgrade and run with something safer. I totally agree, your question is spot on with containers as well because For that, you have other considerations that are less visible. As a developer, I know that if I upgrade this and that dependency, I probably need to check the API didn't break. But if you update the container image tag or something to a later version, you do not really know, even if you move different distribution for Linux, you do not really know if you're going to break something that as a runtime or as a system utility that the app needs would be required and that would break it. For example, If you're running some image resizing stuff and you base that in your app not on native libraries and you do that using something like ImageMagick, so you run a system command, convert something to resize it or scale it up or something, then yeah, if you're moving to a different image or a different runtime version, maybe that's not going to be even installed by default, so you're going to break the app as it is. We have the same idea of smart remediation, like smart fixing. You can consider it, if you're using Node:10, for example, we would give you an alternative base image which is very small change. You can move from Node 10.2 to Node 10.4, which is generally didn't really change a whole major version, it just use a newer version of that image. And that by itself could remediate a lot of the vulnerabilities that you have. And it's kind of a pretty safe bet. On the same kind of notion, you could also, we would give you advice of, you could also fix or make 50 or 100 vulnerabilities disappear if you just move to Node 11, or if you just move to a Node image that is based on Jessie or a different flavor of Debian or something else that has different vulnerabilities. Obviously, you want to check those stuff. I would say if you have a really good and healthy CI workflow, so you're spinning containers up, you're running some flows, maybe some end-to-end flows as well, you're testing things as you probably should before you're deploying stuff, then you can feel safe or empowered to change to a newer image that is more secure, but at the same time, you know, have this CI confidence or testing confidence that nothing, you know, broke or, you know, or you will find something broken and then, you know, you'll have to remediate to maybe a lesser version or something like that.

**23:59 Robert Hurlbut:** So I have another kind of item that I've kind of picked out of the report here that I'd love to get your perspective on. And that is under vulnerability identification, you found that the median time from when a vulnerability was added to an open source package until it was fixed was over 2 years.

**24:18 Chris Romeo:** Yeah.

**24:20 Liran Tal:** Yep, that's true.

**24:21 Robert Hurlbut:** So that's a little scary, but give us some context on that.

**24:25 Liran Tal:** Sure. So what does this basically mean, right? So as a developer, we write code and that code, it sometimes, you know, may be insecure, but, you know, until someone found out about it, anyone, whether publicly or privately, you know, at that point, you know, it has no meaning because, you know, no one knows that it's insecure. That statistics really talk about, I added that one line of code, that bad if, that bad logic, whatever, either like a bad use of an API for cryptography or something like that. It stayed dormant in my code for maybe 2 years. That's the median number for packages that we scanned. It stayed there like 2 years until a CVE came out or we found it in some other way that someone reported it as being vulnerable. So, yeah, so it takes, as you know, that phrase from The Cathedral and the Bazaar, what's his name? Eric Raymond, I think was that, around with enough eyes, all bags are shallow. So, you have a lot of people looking at open source, and that was paraphrasing Linux on the Linux kernel, et cetera, on the security of it. But we see it even with open source libraries. My dataset was not my own code or the company's code or something like that. It was open source libraries that we found vulnerabilities on that we had known about them in retrospect. We looked back at the exact commit in time that added that piece of code and we found that median time was 2 years. That existed for 2 years. If within that 2 years someone knew about it and took advantage of it without reporting, that's scary as itself. But still, 2 years for someone to actually also report it publicly, that getting disclosed, hopefully in a responsible disclosure manner, getting fixed, that's a long time.

**26:23 Robert Hurlbut:** Yeah. So that's almost like you almost were measuring the amount of time that it was possible to exploit the vulnerability. but with no consideration for whether it was ever actually found and publicly, or when it was found.

**26:40 Liran Tal:** Yes.

**26:41 Robert Hurlbut:** So, it's not as bad as I originally read it to be.

**26:44 Liran Tal:** Yeah. So, like we did, so like the endpoint in time was actually when a CVE or when a vulnerability became public, right? A publicly known one. So, these 2 years is basically the time between that code living in your code base. And the end of those 2 years is basically the, the day that the vulnerability got disclosed and someone probably raised the CVE for it. Yeah, whether us or someone else. Yeah.

**27:09 Robert Hurlbut:** Yeah, it makes, it makes me just remember the good old Bash bug and the fact that it was, what, 20 years in hiding inside that code before anybody actually found it?

**27:19 Liran Tal:** Was that Shellshock?

**27:20 Robert Hurlbut:** Yeah, Shellshock. Yeah, yeah, yeah. So I mean, it was, it was hanging around for, for quite a while without getting, uh, Without getting fixed. Okay. So, this has been a really good introduction to the report. And so, I'll say it now and then I got one more question for you, but just for our listeners to know, hey, we're just talking about the State of Open Source Security 2019 report. It's available for download from Snyk's site. So, you can Google it and there'll be links in the show notes to the actual PDF for the report if you want to check it out.

**27:51 Chris Romeo:** Yeah.

**27:52 Robert Hurlbut:** Laurent, to kind of change gears from stating what the problem is and measuring the problem to talking a little bit about the solution space, here is my challenging question for you. If you could only do 3 things to improve open-source security in the next 5 years, we'll limit you to 3 things though, what would those 3 things be?

**28:16 Chris Romeo:** This is your—

**28:18 Robert Hurlbut:** you're in charge of the entire technological industry. And you can just— this is almost like, what are your 3 wishes? I almost want to call them your 3 wishes. But if you could only do 3 things, what would they be?

**28:32 Liran Tal:** Sure. So, yeah, no pressure at all. I would say I would start first with something I've been thinking for a while, and that is democratizing security. And that's, I think, a pretty revolutionary statement in itself. You know, making security accessible to everyone, making it, you know, not something that is far-fetched, that is hard to do, that is, you know, far from people in general. I wanna democratize it. I wanna make it easy for people, developers, you know, SREs, you know, IT people, everyone understand what it is, you know, practice safe security, you know, make it available for them to know about problems, to fix them, to, you know, to just make really good quality software in terms of security perspective. So, I would say that as a first thing. Second thing would be, I think, awareness. So, a lot of— this is something that we're seeing as something that is just challenging in terms of if I went into a university and I studied computer sciences, I did not have a specific cybersecurity course telling me and teaching me about SQL injections or even just this whole thing about open source security, how important it is, what is the risk, data breaches that are happening all the time because of these things. I think awareness in general, not just as a DevRel for me, going and making this more a significant topic in the ecosystem throughout communities, etc. Not just that, but people actually taking that into account. I remember how it was like when I was a developer and a team lead, And we had security issues that needed to be prioritized, but it was always back and forth with product ownership or backlogs, etc., and kind of pushed down because it's a security issue. It's not something that we need to deliver. And I think that is something that we need to change, that security is part of the product quality that we're shipping. That's not something that we need to just postpone until we have time for it. So prioritizing that and accepting that this is something that should be baked into our product is definitely my— would be my second takeaway. My third one would be maybe celebrating or championing security. In general, I think that's a positive look at security as something that is not to be afraid of, not to fear from, not to be overly concerned about in an evil manner. but in terms, you know, celebrate it. So, you know, previously I used to have, you know, I used to like to make happen that we would have a security champion in our R&D organization. So they would go, they would find vulnerabilities, they would work with, you know, some tools, they would create, you know, cheat sheets for everyone. They would find something and remediate it. They would, you know, do kind of like a lunch and learn on what we did, what we found. So kind of, you know, celebrate security and, you know, kind of look at it in a very empowering way. And, you know, not something that you just, you know, just do, just close the vulnerability and continue on. So, you know, actually, like, I would even frame it as, you know, recognition, you know, for developers, you know, doing that.

**31:43 Robert Hurlbut:** Yeah. All these are security culture-related ideas for how we change the state of open source security. I think it's definitely doable. I mean, I think you're seeing in the analysis you did that, you know, these developers, they care, they want to have more secure solutions, and a lot of times they just don't know what they need to do to get to that secure state. So, that's all good stuff. Well, how can our listeners interact with you, Liran? Where's the best place for them to find you and continue the conversation?

**32:16 Liran Tal:** I'm on Twitter, @liran_tal. You can— I'm really happy to mentor, help, you know, whatever you need that I can help with as time allows to be there. But even actually more important and better, we have the Secure Developer Community. So actually, literally thesecuredeveloper.com. You can go, you can find webinar episodes with individuals. We have a Slack community which I hang out on, help people, we discuss a lot of stuff. They help me. We talk a lot of stuff around security in different contexts, which is even more interesting. So you can join that as well. That's kind of about it, I think.

**32:56 Robert Hurlbut:** All right, well, thank you so much for sharing your expertise about open source security with us and with our audience. And we definitely look forward to having you back here in the future to talk about Node secure coding, because that's something I told you right at the top of this. I was like, hmm, I really want to change this up and just talk about— after I saw your profile. But definitely want to have you back to have that conversation as well. So Laurent, thank you for taking the time today.

**33:22 Liran Tal:** Awesome, and thank you for having me.

**33:24 Chris Romeo:** Thanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Born and TJ, and our outro music is Southern Delight by Stefan Kartenberg. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @Chris @EdgeRoute, and Robert, @RobertHurlbunt. Remember, security is a journey, not a destination.

---

Source: https://appsecpodcast.com/liran-tal-the-state-of-open-source-software-security/