Erlend Oftedal -- What You Require, You Must Also Retire

0:00Chris RomeoHey folks, season 4, episode 14 of the Application Security Podcast. On this episode, I had a chance to travel to Norway, of all places. I was speaking at the NDC TechTown conference there, and I happened to run into the guy who runs the OWASP Norway chapter out of Oslo. And it turns out he's also the author of a tool called retire.js that I had heard about before, but had never had a chance to meet the author. So in this interview, we talk about the OWASP Norway chapter for a minute, and then we get into what is Retire.js, how does it work, what would you use it for, and all the things that a developer needs to know about it and how to use it the first time. The Application Security Podcast. Here we go. Hey folks, this is Chris and I am in Kongsberg, Norway at the NDC conference called TechTown. And this is a gathering of software developers, and it's a conference right now that has a focus on product in regards to language, meaning C and C++, a bunch of different topics, and security just happens to be one of them. And that's why I'm here chatting about security. I'm actually joined today by Erlend Oftedal, who is a number of different things in the world of AppSec, and we'll kind of get into that. But Erlend, I want to ask you, What is your security origin story or how did you get started in the world of security?

1:54Erlend OftedalI started out as a developer, but at some point I picked up on things like Hack This Site and similar things like that. And I started working on that and I found that this is really fun to do. And at around the same time, we started kind of a security group within the company I was working. And so I joined that group. For a couple of years, I was also the head of that group where what we basically would do was to build our— learn stuff about security to help us become better developers and help our projects and the other projects that the company was doing. And so I started out as just a normal developer, but then I gradually moved into more and more security stuff. working on developing secure solutions or the security controls for solutions. Eventually started doing pen testing, security testing, security code reviews, and things like that. So that's basically how I got started, I think.

3:04Chris RomeoSo this is all within one organization or were you doing consulting as you were kind of transitioning from developer into security person?

3:18Erlend OftedalI was always a consultant. I started out as a consultant, but as a developer. And so the projects I was doing where I started to do security assessments and things like that was for other clients of the same company. So I would, like, on a day-to-day, I would work as a developer, but every now and then one of the other projects would ask me to come and I would come and review their code or do some security testing on their code.

3:45Chris RomeoOkay. And I want to ask a follow-up question. I'm fascinated by this idea that you said you were learning about security with the desire to make you and your team better developers. And so that's not the normal path that— I talk to a lot of different people that have started careers in security, and it's normally the other direction. It's not developers saying, I want to learn more about security so I can be a better developer.

4:13Erlend OftedalRight.

4:14Chris RomeoIt's developers that are saying, okay, I see an opportunity to transition into a security role in a central function in whatever organization I work for. So kind of what, I guess, what led you into going down that path and saying, we're going to learn about security because we want to become better developers?

4:31Erlend OftedalI started reading books, reading blog posts, reading all kinds of stuff around security, realizing that a lot of the applications that we put online are really insecure. And I think we've seen that a lot the last years, but it's been like that forever, of course. But things like, simple things like SQL injection and things that are, in my opinion, quite easy to avoid, was still everywhere.

4:58Mm-hmm.

4:58Erlend OftedalAnd so as a part of being a good developer, I thought, well, we should build solutions that are secure and robust. We can't keep building this stuff and just putting it online without any thought for security. So I really didn't have any intention of going into a full-on security role at any point. It was more as a part of being a developer, a specialization of a developer, so to say.

5:24Yeah.

5:26Chris RomeoAnd that's certainly something that I'm passionate about is how do we take developers and layer security on top of what they already do instead of the other side where everybody's always like, let's push security on top of the developers. Let's kind of let them lean into it a little bit and see the value in it. So that sounds like you've had a similar path as far as kind of what got you into security there. So you're, from what I understand, you're involved with OWASP Norway. And as our listeners of the podcast know, we're gigantic OWASP fans because we talk about OWASP almost every episode. Once in a while, we We take a break, but we're always talking about OWASP. So tell me a little bit about the OWASP Norway chapter and kind of what's happening here.

6:11Erlend OftedalYeah, we started the OWASP chapter 10 years ago. It was a security company in Norway that initiated it, and they asked around for people who wanted to join in and start the chapter. And I was one of those that joined, and we started it 10 years ago. So we have a 10-year anniversary anniversary this year, which we're going to celebrate by having a single-day conference in Oslo at the University of Oslo. So we call it the OWASP Norway Day. We've tried to have like bimonthly meetings, chapter meetings, with speakers either from Norway or from Europe, or if there are any famous speakers that happen to be in Norway for a conference or things like that, we usually try to pick up on that and ask them if they want to come talk at a chapter meeting.

7:07Yeah.

7:07Chris RomeoSo you've been the chapter lead for 6 or 7 years. What do you think is the most difficult thing about running an OWASP chapter? Because I've had a lot of people ask that are kind of excited about wanting to do something with OWASP, maybe perhaps in their area. And so I'm just curious, you've been doing this a lot longer than I have from a chapter perspective. And so what's the hardest thing that you have to overcome?

7:33Erlend OftedalWell, I think consistency has been the hardest part, like actually having one every month or every other month. I think for a while we thought that we would be able to do it every month, but then we figured out that that wouldn't work. But of course, if you can do it at a high enough pace, then people will join and people will find it interesting. But if you kind of forget about it for a while because that happens. People are busy, they have their normal day jobs, and then they forget about the meetings. And so if you have, let's say, poor quality meetings, or if you wait, the delay from meeting to meeting is too long, then people will lose interest, I think. And it's also really, I think, what's boosted our chapter is the fact that we can sometimes get some famous speakers from abroad that come in for a conference, and then we get them to speak at the chapter as well. It usually brings in a lot of people. We had Troy Hunt and Scott Helme visiting last year, and that was by far the highest attendance we've ever had. I think it was just under 300 people.

8:43Chris RomeoOh wow, that's a gigantic chapter meeting.

8:46Erlend OftedalYeah, usually we were around, yeah, I think we're around 50 or, yeah, somewhere between 30 and 50, sometimes up towards 100. It's not a big chapter, but it's a good group of people.

9:00Chris RomeoAwesome. Thank you for continuing the OWASP message. I know 6 or 7 years is— I've been doing this for maybe a little bit more than 1 year. I know it's a grind sometimes to say, okay, how are we going to get this meeting? How are we going to find somebody and get this meeting put out there? I have to tell a little bit of the backstory here about the next thing that we're going to talk about. Here at the conference, Erlend and I were chatting in the hallway and he mentioned something about this tool called retire.js. And I was thinking to myself, I'd heard about this because I had an opportunity to work with Jim Manico and Katie Anton and Jim Arnold on the Proactive Controls 3.0, and we had a lot of discussion about the dependency checkers and things and tools that were available. And I remember Jim Manico talking about this retire.js tool and mentioning this guy who was an OWASP person who was actually kind of the author and the primary maintainer of this tool. And lo and behold, I'm standing in the hallway here and Erlend is that guy that is the primary maintainer and the— we'll call you the architect and everything else in charge of this tool called retire.js. So Erlend, what— first of all, for our listeners who may not know anything more than maybe they've heard a single sentence about it, or maybe they don't know anything at all. What is RetireJS?

10:27Erlend OftedalSo the idea of RetireJS was that we need some way of figuring out what JavaScript libraries we're using and if those versions of the JavaScript libraries that we're using have any known vulnerabilities in them. So this basically started with— I actually checked today, and it's exactly 5 years since the first commit on RetireJS. So it was in August 2013. It started out with me working as a developer on a project where we were looking into Java, the Java libraries that we were using and which ones had vulnerabilities in them. And we were looking into finding solutions for automated scans. And then I started thinking, hey, we're also using a lot of JavaScript libraries, but there aren't really any scanners available for this. And I was talking to one of my colleagues, and he said, yeah, I think most websites, they have the jQuery version that was available at the time the website was first built. Which is probably quite right, I must have to say. So I decided to build this tool, and it was intended as a command line utility that you could use to scan your source code folders, just looking for JavaScript files and then trying to identify them by looking at comments, by looking at the code, by looking at the name of the file and things like that. Eventually, it also— we made a Chrome extension for it, and someone contributed a Firefox plugin as well. And then later, someone also created a Burp plugin, a ZAP plugin, and a Maven plugin. So there are quite a lot of versions of it right now. So what we have is basically a central repository a set of JavaScript libraries that we're monitoring, where we have a list of vulnerabilities connected to them, and we have some ways of identifying each library and each version.

12:34Chris RomeoAnd so what is the— so you mentioned it's a command line utility. So I guess from a developer's perspective, if they want to use this tool, they can run it from their local machine where they're doing their development. Can you also plug this thing into like a DevOps pipeline? And have it break the build if there's a vulnerable version, just like dependency check does?

12:55Erlend OftedalYeah, you can. And I think a lot of people are doing that. I checked the download numbers just earlier today, and I think we have around 18,000 per week downloads of the tool from npm. And I think most of that is probably people that have it installed as a part of a CI pipeline. So it gets It gets installed, and then they run it, and then it just gets deleted again. You can get reports in different formats, like JSON, or just to standard out, or whatever. And you can also set which kind of exit code you want, because that helps you if you want to break the builds, and you need a proper exit code for the build to break. But if you're running it as a part of, say, a Maven build, then there's a Maven plugin for it as well. make that one break it. Of course, as a part of that, we also need a way to ignore vulnerabilities because sometimes you have a vulnerability in a library that doesn't actually affect the application. So we've added things like you can add an ignore file that says we ignore these types of vulnerabilities or these CVEs basically because they don't affect our system. You can't really integrate something into a pipeline without having a way to ignore stuff that that isn't relevant.

14:16Chris RomeoYeah, yeah, as long as that doesn't get used as a crutch to— which I'm sure there's no DevOps pipelines out there where people have things ignore star, and then they say, yeah, we're doing dependency checking, but wait, no, you're not. You've got everything ignored.

14:32Erlend OftedalTrue. I think that happens a lot. Like, people, they will think that they're not using a vulnerable part of a library, but they are actually using it anyway. It's just sometimes hard to understand. what parts of the libraries you're actually using. And then maybe at the point that you ignored it, you weren't using that part, but then 2 months later.

14:50Chris RomeoAfter the break, Erlend explains what RetireJS looks like for a developer the first time they use it. 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. securityjourney.com to learn how you can teach and empower your developers using a new kind of security training. Erlend continues with what a developer should expect the first time they use Retire.js.

15:29Erlend OftedalIf you're just running like Retire and without no command line arguments, it's going to scan the current folder and all subfolders and it will list all the files that it finds that has vulnerabilities in them. So it depends on like if you're If you have the same libraries in all kinds of build folders and things like that, it's going to find all of them. One of the things that it also does is it will sometimes find files that are in, let's say, test documentation and things like that, which aren't really relevant. So you might get a few— they're not really false positives because they have identified— because Retire has identified the file correctly, but it's not really relevant for the build per se. But that's easy to ignore, like add a path rule that says, yeah, don't look in this folder, we don't care about that one. If you run it on a Node project, or if you have a modern frontend with Webpack and things like that, it will sometimes find the same types of files within the node_modules, some test folder somewhere. which is also something that you can safely ignore. Currently, RetireJS can scan for JavaScript libraries that are just a copied file onto a disk, but it can also scan a Node project. So if you're using Webpack and you have a frontend and you have declared all your dependencies in package.json, you can use RetireJS to scan that as well. But with the new version of npm with audit, I think we'll eventually remove that part because npm is probably going to be better and more updated than Retire is. So I think we're probably going to focus mostly on the file identification and URL identification and things like that, that aren't necessarily easy to find with other tools that are just looking at these declarations like package.json and pom.xml for Java projects.

17:30Chris RomeoYeah, and that certainly makes sense to focus your efforts. I mean, the npm, there's going to be a big team behind that that's going to be investing a lot in that audit, that new audit feature.

17:44Erlend OftedalMm-hmm.

17:45Chris RomeoSo then once the developer runs this RetireJS and they get this list of problem or vulnerabilities that exist, so then the next step is for them to go And upgrade all of those libraries, right? That's the solution. And then run it again to see if you can get it to go green.

18:02Erlend OftedalYeah. And sometimes upgrading a library is super easy. It's just like download the new version, install it, and then you're done. But sometimes, like, if you have an old version of jQuery, for instance, and then you might have to change your code as well because the new versions have different ways of doing things than the old versions. But I mean, this is exactly the same that we see for Java libraries. Like, a common example there is HttpClient 3, which didn't really have an upgrade path to HttpClient 4. You have to rewrite a lot of stuff to upgrade, and HttpClient 3 had a big SSL problem. So you might see the same thing for some JavaScript libraries, but for the most part, you just bump them up to a newer version and it works.

18:46Chris RomeoAnd so you also mentioned that So RetireJS is looking at URLs. So if I specify, if I do basically include a JavaScript snippet from, I would say I use a cloud or a CDN version of jQuery.

19:04Erlend OftedalHmm.

19:05Chris RomeoSo RetireJS is actually going to pick up that I'm including jQuery x.y.z from the URL, and then is it going to advise me at that point that there's vulnerabilities in what I'm including from the website?

19:19Erlend OftedalThe command line scanner is not going to do that. But if you use the Chrome extension, it's going to pick up on that. Because what it does is it looks for anything that's being downloaded. And it sees, is this— does this have the JavaScript content type? And if so, it tries to identify the file. So I even built like a scanner so you don't have to install it. It's called retire.insecurity.today. That's the URL.

19:43Okay.

19:44Erlend OftedalAnd you can go there and you can plug your URL in and it will scan it for you and report on it. So, and I also built, I don't think I ever released it, but I also built like a PhantomJS scanner version of it. So you could say, okay, I want to scan this URL and it would run it locally. And I used that to scan a lot of Norwegian websites, a lot of Fortune 500 companies and things like that, just going to the to the main URL of the company and just see what's being downloaded. And at least the first times around, I think 77% of the Fortune 500 had JavaScript files with known vulnerabilities in them. And it's been going up and down the last years, but I think it's still above 50%, which isn't all that good really.

20:32Chris RomeoAnd the thing about that is that it's a passive scan. So you're not even breaking any laws or anything at all. I mean, a lot of times you could argue whether somebody who's running a port scan is actually breaking a law, but we'll leave that for the legal podcasts out there to argue about. But in the case of your Chrome extension, you're just using the website and collecting data about what versions of software are running. You're not doing any type of active scanning into it, right? Exactly. You're just looking at, here's what my browser is downloading as a portion of this website. being delivered to me, and then you're analyzing that data and then saying, okay, here's the vulnerabilities that exist in these.

21:13Erlend OftedalOkay. Yeah. But as I mentioned, that doesn't necessarily mean that the website is vulnerable because it depends on how you use the library. But there was an interesting instance a couple of years ago where LastPass had a suspected breach and they published a blog post about it. And then on that blog post, they had a, They had jQuery pretty photo and they had jQuery pretty photo in a vulnerable version. And if you have jQuery pretty photo in a vulnerable version, then you have a cross-site scripting vulnerability. And of course someone picked up on this. I think it was Troy Hunt. And there was someone else who scanned their website with the tool that I think at the time was called Dominator, which is like a DOM XSS scanner as well. And they found this bug. But that could easily have been found using RetireJS if they had only been using it. But of course, at the time, they weren't, and I don't know if they are at the moment.

22:05Chris RomeoYeah. So how does RetireJS fit with dependency check, OWASP dependency check and dependency track? Are these complementary to each other, or are they competitive with each other?

22:19Erlend OftedalRight now, I think dependency track has its own way of scanning JavaScript libraries, at least Node libraries. So, dependency— the difference kind of between dependency check and dependency track is dependency check scans your current folder right now and sees what's there and creates a report, which you can also import into dependency track. But dependency track is also more built around the concept of bill of materials. So, you can just basically say, these are the dependencies I'm using.

22:54Okay.

22:55Erlend OftedalAnd it will keep track of which ones have vulnerabilities. So it will scan them every day or at a frequency. So you don't have to remember to scan your application. It will just do that because it knows what kind of libraries are used in your application. So what I did when, like, the new version of Dependency Track came out was I built a way for Retire to export a bill of materials that could be imported into Dependency Track. So, now they're kind of complementary, because I don't think Dependency Check necessarily can pick up on, like, JavaScript files that are just left in a folder somewhere, unless there's, like, a clear naming, or— I don't really know how well Dependency Check can find JavaScript files. Okay.

23:48Okay.

23:48Chris RomeoWell, no, that's cool that they're complementary to each other, and that's a great idea that you had to be able to export what's coming out of Retire.js. I mean, we should be working to figure out how all of our tools can interact and work together versus somebody saying, okay, well, I'm going to rebuild that functionality in a different OWASP project. I mean, it's hard enough to get what we have working now working, right?

24:13Erlend OftedalYeah, exactly. Because the dependency checking and dependency track are really complementary and work really well together. And so I just wanted to add Retarget.js to the same thing and be a part of that, because I think dependency track looks really promising with the new version.

24:27Chris RomeoI do too. I think it's going to push the envelope on a lot of the commercial providers out there that are charging a lot of money to provide that same thing. And now I can go download something that's almost feature identical between very expensive commercial product and OWASP open source download and plugin. So yeah, so that's good to know about dependency check and dependency track. What about if we look, if we think about how does Retire.js stack up against some of the commercial providers that are out there? And I don't want to talk about who they are, but let's just talk about them in general as a blob of—

25:08Mm-hmm.

25:09Chris RomeoA blob of commerce out there that's focused on JavaScript?

25:14Erlend OftedalI noticed at some point, I mean, this was started in 2013, and I noticed at some point that some of the vendors started to add JavaScript scanning capabilities. And I'm not going to name someone, but I did find the RetireJS repo in packaged version of a scanner at some point without any reference to the license or anything that it came from RetireJS. But at least some of the more, let's say, the companies that are really working on this as one of their main products, what they will have is probably a better list of vulnerabilities than I have, because I mean, they work on it every day. This is, for me, this is something that I do in my spare time. But luckily, lately I've been getting a lot of pull requests from other people that will contribute stuff to my vulnerability repo, RetireJS's vulnerability repo. And also, at least one of the vendors have kind of open-sourced their repo as well. So you can find stuff there if you want to, which is a nice thing to do. And that same vendor used to use RetireJS as a source and said so on their website.

26:27Chris RomeoOkay.

26:28Erlend OftedalSo now they've kind of switched it around and say, well, we're releasing it as well, which is nice. we can kind of work a little bit together. But I think the main thing where some of these commercial companies are better than the open source scanners is that they, some of them have researchers that are actually looking for vulnerabilities. And so they try to have an improved feed and then they will kind of delay releasing that feed to the rest of the world so they can have like, their clients can have a bit of an advantage. But I think probably a lot of CVEs in libraries come from these researchers and of course other security researchers online.

27:12Chris RomeoAnd so, I mean, those are all positive things of having researchers who are looking for vulnerabilities and publishing those. I mean, it's not quite a positive thing that they're potentially holding some of those vulnerabilities back. But I think the downside of that is they charge a lot of money for those tools too. And so not everybody has multimillion-dollar application security tool budgets. There are some companies, there's quite a few companies out there that do, but I think there's more organizations that don't have that amount of budget. And so that's why I love things like Retire.js, Dependency Track, because those are things that— Dependency Track, those are things that people can go out and—

27:54Erlend OftedalMm-hmm.

27:55Chris RomeoEven if they don't have a huge budget, they can figure it out. They can be doing something towards checking for vulnerabilities in the builds that they do. It may not be as perfect as if they had spent $500,000 on it, but if you don't have $500,000 to spend anyway, it doesn't matter. You might as well move. You might as well do something to make your build environment a little bit better, probably a lot better using the OWASP tools.

28:20Erlend OftedalRight.

28:21Chris RomeoYou know, it's— I guess it's how far does it get you? Is it 75% of the way? Is it 50% of the way? I don't know.

28:28Erlend OftedalI think it's probably quite a high— I think it's pretty— that they're doing a pretty good job. Both RetireJS and Dependency Check are doing a pretty good job at this. So, I don't think it's— I think they'll take you quite far, and that's really, as you said, that's a really good thing. that a lot of people can now benefit from that. And I mean, the main goal of this was to like help people secure their stuff. And so being a part of that, and yeah, that's why it's— I never made it a commercial tool. It was always meant to be like a free scanner that people could use. Yeah.

29:07Chris RomeoSo I guess our action then for our listeners out here is if you're not using Retire.js or if this is the first time you've heard of it, Go take a look at it, install it, run it against your code bases, see if you're in trouble, because then you can quickly patch and run it again till it goes green. But we just wanted you to be aware of this tool that's available, and I love the fact that it's part of— it's an open source project, and it's something that doesn't have a huge barrier to entry. It may take you a little while to figure out how to use it, But you don't have to write a check to be able to install it and start doing some dependency style checking of your JavaScript library. So I guess our call to action is go take a look at it, install it, make it work. Erlend, thank you for spending some time with us and explaining this cool tool. And I'm just glad I can now add it to my list. And I can tell you this, I will be recommending it far and wide as, as what when I meet different people who have a need for new tools. So thank you for taking the time today.

30:11Erlend OftedalThank you for having me.

30:12Thanks 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.com. AppSecPodcast.org.