Malware attacks are scary, so preparation is keys. In this episode, the Jabberers talk with Feross Aboukhadijeh, a developer who’s redefining malware detection to help you prepare for the next assault.

“It’s awesome that such small teams can make complex code, but it’s not enough to just scan for vulnerabilities.”
-Feross Aboukhadijeh

In This Episode

1) This SCARY trend in supple chain malware attacks (and how to prepare)
 2) Why tools like Socket are VERY different from common malware detection
 3) How companies in 2022 are addressing their security (and what they’re looking for in developers to help them)
On YouTube
Supply Chain Security - Part 1 - JSJ 524

Sponsors

Links

Picks

Special Guest: Feross Aboukhadijeh.

Sponsored By:

CHARLES MAX_WOOD: Hey everybody and welcome back to another episode of JavaScript Jabber. This week on our panel, we have Steve Edwards. 

STEVE_EDWARDS: How are you from Portland? 

CHARLES MAX_WOOD: AJ O'Neill. 

AJ_ONEAL: Yo, yo, yo. Coming at you live from the box card children's den. 

CHARLES MAX_WOOD: Right. We also have Amy Knight. 

AMY_KNIGHTS: Hey, hey from Nashville. 

CHARLES MAX_WOOD: We've missed you, Amy. 

AMY_KNIGHTS: I have missed you too. 

CHARLES MAX_WOOD: I'm Charles Max Wood from Top End Devs. I just scheduled a whole bunch of workshops for the next several weeks at topendevs.com slash workshops. So go check that out. We have a special guest this week and that is for Ross, a Bucca DJ. What's new with you, Ross? 

FEROSS_ABOUKHADIJEH: I started a company working on supply chain security, and I got engaged.

 

Hey folks, this is Charles Max Wood from Top End Devs. And lately I've been working on actually building out Top End Devs. If you're interested, you can go to topendevs.com slash podcast and you can actually hear a little bit more about my story about why I'm doing what I'm doing with Top End Devs, why I changed it from devchat.tv to Top End Devs. But what I really want to get into is that I have decided that I'm going to build the platform that I always wished I had with devchat.tv and I renamed it to Top End Devs because I want to give you the resources that are gonna help you to build the career that you want. So whether you wanna be an influencer in tech, whether you want to go and just max out your salary and then go live a lifestyle with your family, your friends, or just traveling the world or whatever, I wanna give you the resources that are gonna help you do that. We're gonna have career and leadership resources in there and we're gonna be giving you content on a regular basis to help you level up and max out your career. So go check it out at topvendevs.com. If you sign up before my birthday, December 14th. If you sign up before my birthday, you can get 50% off the lifetime of your subscription. Once again, that's top end devs.com. 

 

CHARLES MAX_WOOD: So, uh, I don't know how much value people are going to get out of an engagement announcement, but it's exciting. So let's talk about web security. 

FEROSS_ABOUKHADIJEH: I don't know. You asked what happened in those are the, those are the, 

CHARLES MAX_WOOD: no, those are the big things. That makes sense. 

FEROSS_ABOUKHADIJEH: Yeah. 

CHARLES MAX_WOOD: Good deal. So yeah. So web security. Now you've been working on this stuff for a little while, but, and this is something I'm just going to set a little bit of the stage here because we've had conversations about this on adventures in DevOps, but specifically about SolarWinds, which is supply chain security, which is what we're talking about here. Unless I'm wrong, right? Somebody got in to their build system and effectively inserted malware into their client when they built and that compromised all of the other stuff. I've been hearing about this more and more lately where people are, yeah, they're injecting stuff either into the packages you're using or they get onto your machine and do it there. Or you use a Docker container that has the malware on it as your base and then you build from there. I mean, this, this is kind of frightening stuff because before it was just, you know, I just got to harden this thing so somebody can't get in on port 80 80. Yeah. So what are you seeing? Yeah, go ahead. 

FEROSS_ABOUKHADIJEH: Yeah. I mean, everything goes out the window with the sort of traditional defense stuff when you start dealing with supply chain attacks because now you're actually worried about the contents of the code and the dependencies that you're using. And so it really makes you question your assumptions about what you're using and where you're getting all this code from. And most applications, most open source apps, most people's web apps are composed of 90, 95% open source code. So there's just so many dependencies in the way that we write software. Things have really changed and people are no longer writing an application and using a couple of dependencies. You know, the standard these days is that you usually have at least a thousand NPM dependencies, and that's just for a Hello World app. You know? 

CHARLES MAX_WOOD: No, right? 

FEROSS_ABOUKHADIJEH: Yeah, I mean, it's both a blessing and a curse because by having so many wonderful open source packages out there, it helps us build software so much faster than we could before. So you have really small teams now able to build really powerful and complicated applications by just grabbing all these open source packages off the shelf. It's like a buffet. There's all these open source packages out there. You can just grab as much as you need and slap it all together. And then you add your little bit of custom code on the top, which really makes your apps unique. And so you can have a team of like two or three people build something really, really amazing. But yeah, it comes with some downsides for sure. And security and supply chain security specifically is definitely one of those things. 

CHARLES MAX_WOOD: So just tell me which packages not to use and then we can get off the call.

FEROSS_ABOUKHADIJEH: Yeah, I wish it was that easy. The problem is, say you actually want to vet a package completely before you use it. You want to read every line of code. First of all, that's just really hard to do. I mean, that's a thing that usually you have to have some. I mean, the reason why you're using an open source package is usually because there's some complicated problem that you don't understand. You don't really want to have to go learn about and understand. You kind of want to just grab it and use it as an encapsulated abstraction that you can just grab and use. And so even auditing it. to look and see what it's doing is actually a thing that requires some amount of skill that you may not have. And then on top of that, there's the amount of code that you'd have to audit. So some of these dependencies are really big. The sheer number of them is a problem. And then you also need some idea of what to be even looking for here. So we're not just interested in vulnerabilities, in other words, accidental bugs that the maintainer has introduced. We're also worried about malware and intentional attacks being added. And that's, I guess we can talk about some of the examples of that that have happened recently, but that's, that's the real thing that you're looking for. You know, you want to look for changes in kind of what a package is doing. And a lot of these attacks, you'll see a package, a package's behavior suddenly change. And whereas before it may have never talked to the network or read files on your computer, suddenly a new version is published that's reaching out to the network and sending your data off to some random server or running a cryptocurrency miner. And this is such a departure in behavior that if you were actually to look at the code, you would see that, right? If you really fully looked at every line of code. But it's just not feasible on most teams to actually do that. Not to mention the number of dependency updates that are flying around these days. So I don't know if you've ever installed Dependabot or Renovator, one of these bots that try to keep your dependencies up to date, but I get like five pull requests per day basically. And it- So even if you did that dependency really well, it's, you're merging like five updates per day. And so the code that you're actually running has changed so, potentially changed so significantly. And so that's kind of why it's just a really hard problem. It makes sense. 

AJ_ONEAL: So my first question is, of course, are there really 1000 problems that people have that they can't solve? Cause I feel that we're, I mean, the issue that I think that you're trying to address is an important one. 

STEVE_EDWARDS: At least.

AJ_ONEAL: which is that people already made this decision thinking or not thinking. But I think it's kind of like preventative care. If you don't want to have a heart attack, you might want to start exercising. Right. If you don't want to have all these problems, maybe learn how to program. I don't know. 

FEROSS_ABOUKHADIJEH: Yeah. I mean, you're preaching to the choir. Like I'm totally on board with the idea of reducing dependencies, picking very, your dependencies really carefully picking a package that does the bare minimum that you need and not like more than you need. So reducing bloat, right? I mean, you'll see things all the time, like you want to make an HTTP request and so you'll install some like helper library, right? Request is the most popular example in node land and you install Request and then Request has all this support for all this crazy stuff. Like it can OAuth with, you know, has OAuth support. It has support for all these weird, like it can talk to AWS and stuff. It has all this like extra crud that's added in there. And so you're trying to just make an HTTP request, but you now pulled in like 30 dependencies to deal with AWS, which you may not even be dealing with. And so it's a really hard problem in software because it's like, do you wanna have all the bells and whistles, do you wanna have all the API stuff that you need so that in the future, if you need that, it's there and it's supported and it's really awesome and it has all the features that you want, or do you want something that just does exactly what you want? so that it's perfectly tuned. I mean, no dependency is gonna be perfectly tuned to your use case, but the goal is to try to find something that does exactly what you want and know more and then know less. But even that is hard because in the future, your needs might expand and then now you'll regret that you picked a minimalist dependency. We ran into this when we were picking an internationalization library for a project that I was working on where, oh, there's a lot of them out there and if you pick a really minimalist one, it'll work fine, but then you'll add a right to left language or something or you'll add, you'll need to do some kind of very, you know variable substitution and then it turns out that the I18M library that you picked is too simple, it's too minimalist, it actually doesn't work in some cases. So I don't know, it's just a really hard problem and I agree with what you're saying, I think it's a good goal but I don't know, do you have any ideas in practice how to balance this? Because it's a really hard problem I think. 

AJ_ONEAL: Well, I get a lot of pushback actually because it's become so common in the ecosystem that people don't realize that this is not normal. It's like back in the Roman times when they used to just kill children that didn't perform well or something. It's absurd to think about today, but back in those times it's just like, well, yeah, that's what you do with a kid that's a runt or whatever. You just take them out of society. It seems absurd. Now, obviously, using a thousand dependencies isn't as absurd as taking someone's life. But to me, I come from the prior era where the idea that you would have a thousand touch points that you don't understand and that you don't know where they come from and you don't know what they do is just absolutely absurd. But the people that are entering the workforce now, this is commonplace for them. They don't know any other way of doing it. The idea that you wouldn't want, say, 19,000 dependencies when you install Gatsby is just as ludicrous to them as anything else. So I try to Personally, what I try to do is figure out what problem we're trying to solve and then do a little bit of digging. I've posted on Reddit sometimes, hey, does anybody know of a library that does this that doesn't have 10 years of legacy? Because another thing with things like request is you're not just dealing with whatever the library author is trying to do today. You're trying to deal with what they were trying to do over the last eight years. And they may have matured and grown up, but everything depends on their library. So they can't break their library by...chopping off all those AWS dependencies because then somebody needs to go update their package.json. So there's a lot of things in terms of ecosystem where I don't know what the solution is on a broad level. And I think that's kind of what you're handling is the more broad level solution. But on the local level, it's just, well, hey, look for something that's got maybe 10 to 100 stars rather than something that has 2,000 stars. And you peek in the code and see, does the code look reasonable? Does it look like this person copied and pasted from Stack Overflow, which is a lot of what those 20,000 star modules are, or does it look like this person wrote this from scratch and that they kind of had an idea of what they were doing? But again, you can't peak at a thousand modules, but you can peak at five. And if you will peak at those five, then maybe you don't need to peak at a thousand because those five might just do what they need to do. 

FEROSS_ABOUKHADIJEH: I think a lot of what has changed is it's not so much that people have forgotten how to program. I think as much as that NPM was the first package manager that made it painless both to create dependency, like to create new packages and also painless to depend on them. So before NPM with Python and another and you know the pip package manager or whatever easy install, whatever Python had before, you had this problem where if a package adds a dependency on some other package, then it's forcing all the other dependencies in the project to also use the same version of that dependency. So like if I depend on package foo at version one, then every other part of the project that uses package foo has to also depend on version one. And so it's this like really annoying thing to add a dependency to a project, because now you're forcing all the other dependencies to also be synced up with you. And, and so it led to this culture, I think, in that ecosystem of people just inlining code, like rather than adding a dependency, they'll just copy the code. And if it's like 100 lines, you'll just copy it in. And then you could say, we don't have any dependencies. So it's really easy to use this library. And in NPM, they solved that problem by just saying, look, if I want to use version one of foo and something else wants to use version two of foo, then that's fine. NPM will just install both versions of foo and we can move on with our life. It doesn't really matter. And so that made it, I think, like a lot more costless or it feels costless to just be like, oh yeah, we can add a dependency on this rather than copying the code in because like no one's going to complain to me about that and it's going to work and I don't have to write that 100 lines. And there's also some part of it that's actually arguably better in some ways, which is like even 100 lines, you can have a ton of bugs even in 100 lines of code, especially if it's tricky. And so there's some benefit to like being able to automatically inherit the bug fixes, although you also automatically inherit the new bugs as well. 

AJ_ONEAL: Well, I think again, I think this is kind of an ecosystem problem, though, because look at the Go community. You've dabbled in Go at least, right? 

FEROSS_ABOUKHADIJEH: Very, very, very.briefly. 

AJ_ONEAL: Okay, well, the rest community kind of has the same problem as NPM to some extent, but the Go community does not have this problem. And I think a lot of it has to do with the leadership, because the leadership says these are our values. We value being small, being simple, being understandable, being readable. A little copying is better than a little dependency. And the package manager solves all solvable problems that a package manager can solve, provably so. And So there's some amount of ethos that I think, I think part of the problem is there is no leadership in the JavaScript community. There are no figureheads, but there aren't there. There's no, there, there was Douglas Crockford. Okay. Sure. Sure. Sure. I'm just saying that there, that there is, when there is some of this, some defined culture, people will fall into that culture. 

CHARLES MAX_WOOD: I, so there are a couple of things that I want to kind of pick out here. One is, is.I do agree that if there was somebody out there kind of championing a particular approach or a particular way of doing things, you know, or particular tool, things like that, that everybody kind of agreed is our guy, right? So kind of like Ruby has maths and whoever else has whoever else. You kind of have these benevolent dictators or what have you, right, that are making a lot of these calls. They kind of push things in a particular direction, right? You know, everybody who writes Ruby on Rails. They kind of do things the way DHH does them because that's how Rails is written. Right. And so it kind of, and it kind of forces the Ruby community to come along in, in certain ways along with that. Right. So you've got these opinionated pushes, but the difference is, is that the PIPs and the Rubies or the Ruby gems and the other package managers, they kind of came about before the community really had a large set of established practices going on. And with NPM, NPM came on the scene after, you know, 15, 20 years of web development, right, going on and all kinds of packages or libraries already being written in JavaScript and it tried to encompass all of it. And so it had to go and be compatible with the way things had been done in a whole bunch of different places. And there was a lot to manage. 

AJ_ONEAL: I disagree. What did it have to be compatible with because they blazed the new trail. They fixed a lot of problems that had existed before because of the experience of the Ruby people coming over and a few of the Python people coming over. 

CHARLES MAX_WOOD: They did, but at the same time, and speaking specifically about what Firas is talking about here, where he's saying you could pick up different dependencies of different libraries depending on, I've got eight libraries I'm pulling in here, four of them use different versions of Lodash. And so it doesn't matter, right? Cause it just pulls in all four versions of Lodash. That was kind of important because before what you would wind up doing is you would pull down a bundle of like jQuery, right? And you would stick it on your page. And then, you know, if you pulled in some other library that did something else and it depended on a different version of whatever jQuery depended on, it kind of lived in that space, right? 

AJ_ONEAL: Okay. So you're talking about NPM for the browser, not NPM for Node. 

CHARLES MAX_WOOD: Right. But And NPM, if NPM had just stayed a node thing, I think it wouldn't have had to try and encompass some of these other issues. But because people were using it, and Browserify, and some of these other ones, they all had a lot of the same problems, in the sense that they were trying to solve these issues for multiple ecosystems that had an established way of approaching these problems. And I don't know that anybody really could have championed a right approach to this. I think it's something we're gonna wind up solving over the next several years still.

FEROSS_ABOUKHADIJEH: Yeah, I mean, the other thing to keep in mind too is like, even if you don't have a, so like, I agree a thousand dependencies, you know, it's a lot of dependencies. And the statistic that I think is mind blowing about, but just to throw it out there, cause I didn't mention it earlier is that the average NPM package has, uh, 79 dependencies on other third party packages and you'd have to also trust 39 maintainers. 

CHARLES MAX_WOOD: So it's, so you get to a thousand fast. 

FEROSS_ABOUKHADIJEH: Yeah, you get to a thousand fast. And so that's, that's mind blowing, right? I mean, it is, it is a huge number, but, but I don't want to like,I don't want to make it seem like that's the only problem and like NPM is unique in having a risk of supply chain attacks because we're also seeing them in other ecosystems. 

CHARLES MAX_WOOD: You are definitely. 

FEROSS_ABOUKHADIJEH: Yeah. So it's not just a, it's not like this is, this is not helping the problem that you have to trust 39 people that you don't know who they are, but it's contributing to the problem, but it's not the only problem. I mean, the bigger, the bigger problem and then, you know, I think is that no one actually reads this code. I mean, the, the problem is that you're, you're basically trying to do something really, really crazy. And it's a miracle that it even works. So you have, you know, we're trying to download code from the internet written by unknown individuals. We haven't read the code. And then we want to execute the code with full permissions on our laptops and on our servers. And we keep all of our most important data on those machines. And we expect this to go well, right? It's like, that is a crazy thing. And it's crazy that it has even worked as long as it has. But I think like we can address the problem by sort of looking at each of those things independently and thinking about like how can we actually improve things. So one thing is like we could read the code. That's one thing, right? I mean we could actually take a look at the code that we're using before we use it. 

CHARLES MAX_WOOD: Now I'm really glad you have time for that. 

FEROSS_ABOUKHADIJEH: I mean what I mean by look at the code isn't necessarily that a human is looking at it. 

CHARLES MAX_WOOD: Oh, okay. 

FEROSS_ABOUKHADIJEH: It's a spectrum, right? You can have you can either on the one hand you can take a really aggressive stance. So there's some companies, really big companies such as Google that treat third party dependencies as their own code and they check it into their own repository at Google and then they basically vet it and they treat it as their own code and they are very careful with updating to the latest version. They look at the diff and they decide whether they want to update. So they treat it as their code and so that's one approach, very, very expensive approach. You need to have a team of dedicated people basically just doing that. So most companies, most startups can't do this. And then on the other hand, you have the like, do nothing. Like let's just YOLO like it's fine, let's just install whatever, let anyone install whatever they want and hope for the best. And that's the way that pretty much most, I think most companies and most teams and most projects do things because it's just the way that everyone else does things. And it doesn't feel like there's really anything else you can do. You can try, like, well, with some of what ages, I mean, you can try to pick like a, you can try to try to pick fewer dependencies and be more careful, but fundamentally you're not really looking at that code and you're also not looking at the updates that are coming in. So I think that neither of those approaches is good and you need a middle ground approach. And that's what...what socket does. That's that's what my project does. 

AJ_ONEAL: So you can also take the approach that Apple and Microsoft take, which is because we also have to define what scope you're trying to solve for because at the small scope, you certainly can when you're picking a dependency, take a look and see does this look like a trustworthy author, you know, just take one click to see them on LinkedIn, you know, are they a real person, take one click to look at the index dot j s and just scroll. Does this look like this was written by somebody who has an understanding of the problem space and the solution space and the language at hand. And if not, sometimes that's okay. Sometimes you, you can take crap code that you can tell was copied and pasted from Stack Overflow because you just need it right then and just mark it as a note of, okay, I'll, I'll go back and reevaluate this later. But, um, 

CHARLES MAX_WOOD: that always happens. 

FEROSS_ABOUKHADIJEH: AJ, you also got to remember though, that, that like even trustworthy authors can, can turn not trustworthy. Like the attack we saw. 

AJ_ONEAL: Oh, absolutely.

FEROSS_ABOUKHADIJEH: with Merrick sabotaging his own code. And also maintainers can lose their passwords and can get hacked. Their machines can get compromised. Their passwords can get reused. I think I missed that one. I agree. What happened? I'll just quickly summarize it for Charles. So there was a maintainer that basically went rogue. He maintained a couple of popular projects. One of them is called Colors. The other is called Faker. And he just decided one day to wake up and sabotage his own packages and replace them with code that prints out a bunch of random Unicode stuff, junk. 

CHARLES MAX_WOOD: Okay. 

FEROSS_ABOUKHADIJEH: You know. random junk, he added like infinite loops, just all kinds of just garbage like that and published it as a patch so that other dependency, other people who depended on it would just get it if they weren't being careful. And so things like, you know, the Amazon EWS CLI tool was affected by this because if you installed it, you would get the latest version of this guy's library. And so that's an example that happened literally last month in January. And it, you know, his packages had 100 million downloads. So even if at one point that was a good library and he was a trustworthy person, like he can just wake up one day and decide to go rogue. And so it doesn't discredit, you have other points you're making, AJ, but I just wanted to mention that because it is also. 

AJ_ONEAL: Yes, I agree with that. So the other part I was gonna say, so that's on the small scale, I'm saying as an individual team with a few people, you can do some level of auditing to kind of get a sense of what's the debt we're bringing on with this and whether you're small team or a large team, you can also take the Microsoft and Apple approach, more so if you're in a large company like Microsoft or Apple where they print money, which is they don't use third party code. They might go inspect it to kind of see how something is done or whatever, as long as it's not under the GPL, if it's under an MIT or an Apache or MPL license or something like that. But they don't use third party code. And if Google, if they do, their version system is locked. It's not a loosey goosey thing. I think the number one thing people need to know about Node is that npm install is an alias for npm install dash dash random. I think people need to know that And that the only acceptable install is npm ci unless you were trying to get random dependency versions if you Which I don't think is what anybody wants to do I don't think anybody wakes up and says hey I want to just just roll a dice and see what gets installed when I run npm install, but that is the default behavior. So there's that too. Actually having version locking in place and then just for simple things, just write your own code and for very complex things, evaluate it. 

FEROSS_ABOUKHADIJEH: Yeah, so I totally agree with your broad points. I think, so if you just take an example though of like a project that we worked on before we built Socket, there was this thing called Wormhole. You can check it out at wormhole.app. It's a way to send files securely with end-to-end encryption in your browser. And we tried really hard to make sure that the server doesn't see your files, doesn't see your data. And when we were building it, we were a two-person team at the time, and so we needed to rely on other people's code. We couldn't feasibly write this from scratch. The problem is, we wanted to do stuff like peer-to-peer, file transfer, so that we could make the site really fast. And so we had to pull in dependencies to help with that networking stuff the world there's a world where we could have sat down and just like hammered all this code out and would taken us like a year and then maybe we would have ended up building the wrong thing you know and no one would have wanted this thing we would have wasted a year of our life working on it instead we decided like we're going to pull in some dependencies we got it done in two months and now you know we released it and it has over 100 000 people using it every month and we made we made a trade-off where we decided like it's better to get this into the hands of users we'll do our best to pick dependencies carefully but we're not going to sit down and like read everything and so then after launching and like after realizing, okay, a lot of people like this and now they're relying on us, then we started asking ourselves like, is there more we could do to go back and take a closer look at the dependencies that we selected beyond just like cracking open the index.js and looking at it, beyond just looking at the maintainer and saying, have they historically been trustworthy? But also like what do we do about updates? Like when we get a new version update for something, we'd love to be able to update to it, but It seems like, you know, in most of the recent supply chain attacks, that's been a vector. So like you update to a new thing and then it's actually, it's actually worse for you. You end up that the behavior changes and now suddenly it's talking to the networks. Now suddenly there's a crypto miner in there. Now suddenly, you know, it's stealing all the passwords on your computer or stealing your NPM RC file where you keep your, your NPM token. And so like, so like what we, what we realized we needed is some kind of automation. Like if we could basically have our attention automatically like drawn to a suspicious update and we could take a close look when automation detects that something is suspicious about this new version or about this new dependency, then we could spend our time, our limited time on the packages which are the most likely to be dangerous. So for example, if I've been using a package for like the last year, and it has never used an install script, so it doesn't run any code upon installation. But then suddenly, like today, I see there's a new update available and the package is now running code upon installation. That's pretty weird. That's not normal. That's not a thing that you see very often. And so it's probably worth calling that out so that the reviewer who's looking at this update, this pull request sees like, hey, there's something that's changed significantly about the permissions that this package requires. You can almost think about it like the way a phone app works, a smartphone app or a Chrome extension where when an app needs more permissions suddenly, it doesn't just get to use them whenever it wants, it has to actually prompt the user. So you'll see a thing that says like, this Chrome extension needs new permissions. Do you want to like let it use them? And so that's kind of what the model we're trying to bring to dependencies where, you install dependency, you get shown upfront what capabilities it requires. Does it use the file system? Does it talk to the network? And then going forward, if those capabilities change and it suddenly needs new capabilities that we can alert you to that fact and you can be informed before you make a decision about whether to update or not. And we can link you directly to the line of code in the package where it is doing that new thing, that new behavior, and you can look for yourself and see is this a reasonable behavior or not. So if you do that, then you can catch the most egregious supply chain tax of the last year. 

CHARLES MAX_WOOD: So it sounds like you're describing what I wish my kids would do, right? They just go ahead and do what they want instead of asking for permission when their desires change. One thing that I kind of want to, and I was looking for a way to derail this exactly to where you went. So this is perfect because I think everybody kind of understands the issue, right? As far as like how dangerous this is and all the things that you and AJ kind of went back and forth on are things I really just don't want to take the time to do, right? I want to go build stuff, right? And so when we get into this, now it's all right. So yeah, what do I look at? Like, how do I know? And automation seems kind of obvious, right? It's like, there's no way for me to just intuit from the NPM packages folder, oh, that one. I need to look closer at that one, right? So, and I've seen products where they kind of keep track of known vulnerabilities and they'll tell you, hey, this one is out of date. This one has this vulnerability open to it. A lot of times it has a CVE number attached to it, but the problem with that is, is half the time the damage is already done by the time somebody exposes it. And so what I wanna know, it sounds like you've got socket that does something else, right? Something other than, hey, that one's bad. We know that one's a problem. So then one of the things you're talking about is, does it execute code when it installs? I think there are some NPM packages that actually do this. I've heard that. But outside of that, what else are you looking at? And how do you know even if it does execute right off the bat? I mean, some things I might want it to, right? So. 

FEROSS_ABOUKHADIJEH: Yeah, I think the idea isn't to ban any of this stuff. It's just to make sure that you're informed about what the package is gonna do before you choose to use it. And so this is, it's almost like you can think of it like a nutrition facts label, right? Like no one is trying to, a nutrition facts label doesn't. It doesn't ban any kinds of foods. But what it does is it says that when you pick up that food off the shelf at the store, you can take a look at it and you can know what you're getting. You can see what the ingredients are. Maybe you see that there's peanuts in there and you're allergic to peanuts and so you don't want that. Or maybe you care about how many calories or how much sugar it has and you can see that and you can make your own decision. And so that's all that Socket is trying to do is to sort of surface this information about what the packages are doing so that you can make an informed decision about whether to use it. And I think CVEs, you mentioned, so there's a lot of tools out there that, there's a lot of tools out there that will tell you if a package has known vulnerabilities in it. And that's pretty different than what I'm talking about here. So maybe it's worth spending a minute on it, just to distinguish it because, so a known vulnerability is accidentally introduced by a maintainer. So it starts out as a vulnerability and then it becomes a known vulnerability once the security researcher finds it or somebody discovers this bug. And then they write up a report about it and send that to the maintainer and ask the maintainer to fix it. And then they'll hopefully fix it in a timely manner and publish a new version that has the bug fixed. And then what happens at that point is a CVE number is issued and this is basically just a number that goes into a database that says this bug existed in this package, it was in this version, and the bug was fixed in this other version. So if you update to this new version, then the bug will be fixed. And that all just goes into a database. And so there's a lot of tools that'll tell you, hey, this package you're installing, it has three vulnerabilities that we know about. That's something that NPM audit does, for example. That's built right into NPM. You can run NPM audit. It'll tell you, hey, this package has these, these 10 known vulnerabilities. The thing about known vulnerabilities- 

CHARLES MAX_WOOD: Look what you did. 

FEROSS_ABOUKHADIJEH: Yeah, I mean, and there's, it's really noisy too. It's like, it's, it's actually something that developers basically ignore these days. I mean, you can't, you can't really install a package without getting a ton of those these days. And so people are just sort of rightfully kind of ignoring them and a lot of them are, are listed as high criticality or-critical level, and then you look at them and they're not that big of a deal a lot of the time. It's stuff that's like a denial of service and a regular expression in a tool that you only run in development to build your own JavaScript. So it's like, that's never gonna be exploited by a real attacker, right? So people are sort of getting tired of the noisiness and it's like the boy who cried wolf. Everything has known vulnerabilities in it, and sure, you should try to reduce them, but it's not, most of them, like 95% of the ones you get from NPM audit are just noise, right? And so this is a problem that everyone is talking about now and trying to improve the signal of the noise. But there's this whole other problem that no one is talking about yet and no one has really tried to address, which is what do you do about intentionally introduced malware? So what if a maintainer goes rogue and adds malware to their own package, like we saw in January? Or what if a maintainer's account gets compromised and a new version is published that has malware in it? Like we saw back in October with UAParserJS and RC, three packages that were compromised. They each had 30 million downloads a month and those got compromised and malware was added that would basically download a cryptocurrency miner, run it on your computer, mine Monero, send that to the attacker. And then on Windows, it actually did an extra step, which was they would go into the Windows credential manager and steal all your Windows passwords, as well as passwords from a hundred different applications on your machine. And UA parser JS was depended upon by React Native. So like anyone who was using React Native, who installed like who typed npm install react native during this window, which I think it was a four hour window during which this malware was on npm was compromised. You would have all your passwords stolen, you have to go and reset all your passwords, your computer is basically hosed, you need to really honestly just delete it and reinstall everything from scratch to be safe. Change all your passwords, right? Not a good situation. So that's what malware is. Malware is like not, it's not a thing that a security researcher when they find malware, they don't just like publish a CVE about it. They go and they get NPM to take it down off of the NPM registry. And then usually there's not a CVE filed. Sometimes there is, but in most cases, there's not. In the last month, 700 packages were taken down from NPM for various reasons, including malware and security reasons. And there were not 700 CVEs published. So there's just, this stuff is getting published all the time and taken down all the time. Just constant malware going on NPM and getting taken down. And no one is reporting CVEs for this stuff. So it's like, you need another way to basically avoid accidentally installing some of this stuff. It's not enough to just it's not enough to just like hope for after the fact that a CVE Will go into a database weeks too late and that you're gonna run a tool that tells you hey you're running this bad version It's it's too late at that point, right? So that's kind of the that's the key like that's the key problem is like these these these malware attacks these supply chain attacks are Increasing and there's there's there's so many examples we could talk about but yeah, there's they're just October literally just last October There's there's massive ones in in those three packages. I mentioned so so yeah, that's that's that's the kind of difference between looking for known vulnerabilities and looking for malware or supply chain attacks. Hopefully that makes sense. 

AMY_KNIGHTS: I had a question I wanted to bring up. So let me figure out how to word this just like circle back to you. So before I ask my question, like go over thoughts. So I always am like the I feel like the person on teams who's like the not fun person that all the developers hate, like the old person that and I swear it's because I come from like not a traditional background. So I come from more of like the business side of things where I'm just constantly reminding people that our jobs, when we're working for a company, our job, for better or worse, there's a contract there. We're supposed to build things for this company because it makes the company money and we're helping the company make money and in exchange we get a paycheck for that. I mean, that's just the way it works. For better or worse, people might not like it, but at the end of the day for our jobs that's how it works. Now, if you're doing stuff on your own, completely different story, do whatever you want. So knowing that, I feel like it is our responsibility as engineers, developers, programmers, whatever you want to call us, to make a case to the business for these types of things. Like as a responsible engineer, I'm working for this company. It is my responsibility, and I should also be held liable if I am...pulling in any of these packages. So I would say like there, I feel like there needs to be higher stakes for people who, I don't know, it's like, there's a little bit of gray area though, because like we talked about at the beginning of the show with the issue in January, like you can't always predict what someone is going to do, but at the same time, like you need to do somewhat due diligence on things. Sorry, I'm looking at our conversation. All that to say. I guess, so the tool that we're talking about today that you're working on, how friendly would you say that is to like someone coming from more of the business side? Because is this a responsibility that we can share with product and engineering, or is this something that like engineering is gonna have to take sole responsibility for and work with product to say like, hey, we need to educate you on why this is important. 

FEROSS_ABOUKHADIJEH: Yeah, that's interesting. So I think there's, so let me start over.

AMY_KNIGHTS: I said a lot, so sorry. 

FEROSS_ABOUKHADIJEH: Yeah, yeah. So we designed Socket to be super easy to install. The easiest way to install it is just, you just, it's a GitHub app. So it's like, it takes like a minute. You go and you click install. You say apply it to all my repositories in my GitHub organization. And then you're done. Like that's it. So what that means is that an engineer can install it, or the head of security can install it, or a product person can install it. Really anyone who cares about security and wants to make sure that...this stuff is being looked at can go ahead and install it. But we've designed it to be really friendly for developers because the way that it operates is once this GitHub app is installed, it takes a look at all pull requests that are happening on a project. And anytime package JSON file is changed and a dependency is added or a dependency version is updated, it will look at the version that you're trying to add, that the developer is trying to add. And it will check for a whole bunch of things. It'll say, does this new version have any obfuscated code? Right? Does it have, does it look like it's a typo? Like, is the package, you know, we found, for example, there's a package called browser list, but it's a typo of browsers list. And our tool found that Preact project was using browser lists instead of browsers list. And so we sent them a port request to fix that. But this was a package that at one point was malware. And now it's just a, you know, it got taken down and now it's just an, it throws an exception and says, hey, you installed the wrong package. But there's no good reason for anyone to depend on that that typo. It's just risk you're adding to your project for no reason. It's literally a dead code. And so we can look, we can look at dependencies and say, Hey, this looks like a typo. It's it's two letters off from another package that has a thousand times as many downloads. And so we, you know, the bot will come in and post a message and tell the developer, Hey, just double checking and just want to make sure that you intended to install this package and not this other one. And of course, the developer is free to ignore that if they want, they're really sure that they installed the correct package but this is the kind of automation that it's very low cost. It doesn't really get in the way. It just adds information, gives the developer information and then they can go ahead and do whatever they wanna do. And it's the kind of information that I think most developers would be really happy to get. It's like, whoa, you saved me. I almost installed a type. And now this thing just told me that. Or maybe the reviewer noticed it. Maybe it could tell you that this package accesses the network on these three lines. And now the reviewer, so maybe a junior developer sent in a pull request, right? and they don't necessarily know what the implications of talking to the network are, but a senior developer who's reviewing this can say, wait a minute, like, why does this package, which is like rendering a calendar component on the page, why does it need to talk to this.ru domain, right? So it's like, okay, that's a good conversation to have before this pull request is merged. And the cool thing is that it's actually not just gonna check, it's not gonna open up just the first dependency, it's gonna look at all the transitive dependencies too, and it's gonna find if any of those talk to the network, and it'll let the...it'll leave a comment and let the reviewer know that. And so it's just giving information and it's the kind of thing that really anyone can install it, developer, a security person, product person, whoever values this. And we've seen basically all kinds of people installing it for all kinds of reasons. Some people just because they're compliance, they wanna make sure that they're following all the best practices and they have some customer that's asking them about, hey, tell me about all these open source packages you're using and how are you making sure that they're secure? And they can say, well, we installed socket. And now...you know, now we know that at least we're checking for these things. And other people are doing it just because they like the idea of like knowing what's in their dependencies. And they want to make sure that none of them are just talking to the network without them knowing or contain random blobs of code that look like they could be doing who knows what. So, so yeah. 

 

Hi, this is Charles Maxwood from Top End Devs. And lately I've been coaching some people on starting some podcasts and in some cases, just taking their career to the next level. You know, whether you're beginner going to intermediate and intermediate going to advanced, whether you're trying to get noticed in the community or go freelance, I've been helping these folks figure out how to get in front of people, how to build relationships and how to build their careers and max out and just go to the next level. So if you're interested in talking to me and having me help you go to the next level, go to topendevs.com slash coaching. I will give you a one hour free session where we can figure out what you're trying to do, where you're trying to go, and figure out what the next steps are. And then from there, we can figure out how to get you to the place you want to go. So once again, that's topendevs.com slash coaching. 

 

AMY_KNIGHTS: And I think like, I don't know, thinking out loud, talking out loud here a little bit, I think the point I was like trying to make is I just, I feel like we, at least if you've been doing this for a while, probably need to hold yourself and your team to a little bit higher standard, like going back to what AJ was saying at the beginning. I mean, I'm going to make the analogy to like an SRE team. Like it doesn't matter what the application teams are deploying. Like our job is on the line if production goes down. It doesn't matter if I have, have not touched the app code and ever in my life. Like if I am supporting an environment and it goes down because some, you know, application causes a pod to run out of memory or the container in the pod to run out of memory, like that, that is on me. So I guess I'm just saying like. If I'm adding something to a project and I add a dependency that is doing something malicious, whether it's my fault or not, hopefully the company or your boss, whatever, has some grace about the situation, but we definitely need to like hold ourselves to a higher standard. There should be like a postmortem about this kind of stuff. Just all that. 

FEROSS_ABOUKHADIJEH: Yeah, totally agree. I think this is the kind of thing that's going to become a best practice in the coming year, if not sooner than that, because there was a time when two-factor authentication was considered like a nice to have, but now you can't really launch a service without your customers demanding it and saying, where's the 2FA on this? I can't deploy this without 2FA. So 2FA is now standard. And I think also vulnerability scanning has become pretty standard. So that's why it's built into NPM. That's why I have NPM audit. But I don't think anyone is doing this next level of like, what are the capabilities of this package? And I think that's going to start to become standard in the coming year because I wish it wasn't true, but there's just, it seems like every month now or every...every month or two, there's like another one of these supply chain attacks. And so it's just an unacceptable level of risk. I mean, I just came, I've always, by the way, this isn't even a new thing for me. I've always been kind of mine. My mind has always been boggled by how, how NPM install works. Like even like five years ago, whenever I was running NPM install, I'm just like, Whoa, look at all the code coming in, you know, and I'm like, I don't know what any of this is doing. And I'm running this on my computer. And I have a folder over here with like all my, you know, family photos and like all my tax returns and all like my social security number. It's all just sitting in PDF files in this folder. And I'm just like hoping that, and so yeah, I'm just hoping that none of them, none of those people have turned evil or that none of them have had their account hacked or chose a five letter password. So it's really a problem that's been around for a while. It's just not, for some reason, the bad guys haven't really like discovered this goldmine just sitting there until recently. And so- 

STEVE_EDWARDS: And now we're sitting here telling them how to do it, right? Great. 

CHARLES MAX_WOOD: Well.Maybe. So if you've got all that stuff on your computer for us, I have this picture I want you to look at, I'll email it right over. Okay. 

AJ_ONEAL: So I, I lost the connection there for a little bit. And so I missed all of what Amy said and half of what you said for us. But one thing that I wanted to know is can this detect if you're now doing a required HTTP or require FS where that didn't used to be there in surface status. Hey, this is now accessing the file system, but it didn't used to, hey, this is now accessing the network, but it didn't used to at the internal level, not just the dependency level, but what capabilities of node are you trying to require or what capabilities of the browser are you trying to require? 

FEROSS_ABOUKHADIJEH: Yeah, that's correct. Yeah, so you can think of this like a linter. So it looks at, it statically analyzes the dependency and all of its transitive dependencies. And it looks for...capabilities that it's using. So it looks for, you know, does it use the file system? Does it use the network? Does it use eval? Does it use the shell? Does it use debugging features of node? You know, does it dynamically require something that we can't tell at static analysis time, what it's doing? So for example, if you require like a variable instead of a string, right? You type require something complicated that we can't figure out what it's requiring, then we can, we'll mark that as a dynamic require, which means. We don't know what it's doing. It could be anything, but it, so you should assume the worst basically, because that's really weird. And most, most of the time people don't, don't require some convoluted string. 

AJ_ONEAL: For that sort of thing. Are you using ESLint or you have your own? 

FEROSS_ABOUKHADIJEH: We have our own. Yeah, we're using, so we parse the EST and then we just have our own detections that we could have used ESLint, but we just are doing, we're doing a few other things that are, it was just easier to do our own, our own thing. 

AJ_ONEAL: Yeah. That makes sense. And then, okay. So you said you got the.Oh, I lost my thought. I had another question. I lost it. Maybe I'll come back to it. 

STEVE_EDWARDS: You know, it's interesting, you know, while AJ is thinking his deep thoughts, I can remember for the left pad, how a library with eight lines basically took down the internet when something went wrong with it. And I think I'll, what did, didn't it just add some padding to the left side of the string of texture or something like that? It was incredibly tiny library. 

AJ_ONEAL: But it's called start pad. Now the, the official spec is called somebody. And by the time that problem happens, that had already been in the standard library. But. Yeah, it was created back in the olden, olden, olden days, back in the ES5 era. 

STEVE_EDWARDS: Right, right. Anyway, I can remember at the time that this came out, this subject started to... People started noticing it more, that all the dependencies and... Somebody said, create rackdap. I had over a thousand dependencies on it when you installed it out of the gate. But I remember a blog post, and I wish I could find it, where this guy went through and audited some popular NPM packages that people used and looked at what they did behind the scenes. And I always remember one that every time somebody downloaded, installed it, it sent out a tweet to a certain account, you know, saying, Hey, somebody just installed this. I don't remember what the tweet said, but all kinds of just weird stuff that it would do information would gather or stuff like that, sending out tweets. And yeah, it was really interesting post that just looking at all the things, weird things that people buried inside of their libraries. 

FEROSS_ABOUKHADIJEH: Yeah. By the way, the example I gave earlier about a calendar component that was. doing shell scripts was actually a real example that we found. 

CHARLES MAX_WOOD: No way. 

FEROSS_ABOUKHADIJEH: Yeah. Yeah, so it's not a joke. Yeah, it's actually a real package. And we've seen a lot of weird stuff. There's also packages that will, like, you install them, and then they will star themselves so that their NPM star count will go up. And then there's all. 

AJ_ONEAL: Dang, I need to do that. It's like free internet points. And then. Dang, that's a good idea. Why have I not been doing this? 

FEROSS_ABOUKHADIJEH: There's also one that when you install it, it will uninstall itself. So it like runs NPM RM, its own name. There's just like weird crap. There's all this weird stuff on NPM if you dig far enough. And the other thing, by the way, I'll mention too is, oh yeah, go ahead AJ. 

AJ_ONEAL: The box that you press the button and it reaches its hand and then turns itself off. The flip switch box. 

STEVE_EDWARDS: That's one way to increase your installation stats, right? Gotta keep reinstalling it. 

CHARLES MAX_WOOD: I know, right? Or my podcast numbers are gonna go way, way, way, way up. I'll tell you what the package name is later.

FEROSS_ABOUKHADIJEH: Yeah, just hit it. Just do a quick little get requests there in the background. 

CHARLES MAX_WOOD: Yeah. 

FEROSS_ABOUKHADIJEH: Every time the package is required, I'll get you really fast. Yeah. There's also, if people find it interesting, I'll mention too that, um, we've been collecting all the packages that NPM removes over time. So whenever they take a package down from the registry for any reason, we've just been observing that fact. And, uh, we have a page on the website where you can look at all the removed packages. So we're not like, you know, we're, we just have like a basic page where you can browse the files and see what they were doing. And it's super fascinating if you're curious, but you can go in there and just see like this, all this crap that's been published. It's like, it really, it really emphasizes the fact that MTM is basically a Wiki that anyone can edit. I mean, there's no, there's no rules about what you can put on there. So it's just like all the crap. If you're installing a package with like under a hundred downloads a month, right? It could be anything. I mean, it's just like, it could be whatever there's, there's stuff that's just extremely, you can look at what I mean, it's basically there's malware in those, in those, in that page, there's samples of actual some of it is really dumb and really simple. It just takes like process.env, which contains all your environment variables. And it will just curl that off to some URL. 

AJ_ONEAL: Get your AWS keys. 

FEROSS_ABOUKHADIJEH: Yeah, exactly. So there's stuff like that. There's stuff that there's just giant piles of obfuscated code that just like an entire screen full of just you don't even know what it's doing, but it's clearly something not good. So we have a detection for that where you just detect that the entropy in the file is really, really high and it looks unnatural. It doesn't look like normal code. So we can...We can also warn about that. There's stuff in there that is like spam. I mean, it's not even like necessarily malware, but it's like someone just published the package because they want to get links to their Viagra site. And so they just are using the NPM site as like a link to get free links to their website. There's security researchers publishing stuff on there that's like probably not malicious, but still like phones home that it was run to track that. There's all kinds of weird stuff on there. If you're curious, you can poke around it and like let me know if you find anything interesting but it's on socket.dev. You can just go socket.dev and then in the footer, we have a link that says, removed packages. And if you click that, you can see every package that's been removed from NPM in the last couple months that we've been saving them. 

CHARLES MAX_WOOD: So we're about an hour in at this point and I still have way more questions. I'm trying to decide if we wanna push to a part two or. 

AJ_ONEAL: I would love a part two personally. 

FEROSS_ABOUKHADIJEH: Because. You mean like we go another hour? 

CHARLES MAX_WOOD: No, I can't go another hour. I have a call in the half hour or about 40 minutes, but let's schedule another one of these. But in the meantime, yeah, let's just stay on this vein because yeah, I have, I have questions in a couple of other areas that I want to hit, 

FEROSS_ABOUKHADIJEH: but okay. Yeah. Whatever you guys want to do. You, we could do it now for the next 40 minutes or we could do it another, like we could do it tomorrow. Just let me know. 

AJ_ONEAL: Could we do it on Tuesday? Chuck 

CHARLES MAX_WOOD: is Tuesday open. 

AJ_ONEAL: I don't, I don't recall if this next Tuesday is open because I thought that was, we could bump Dan. 

STEVE_EDWARDS: Yeah. We've got something this Saturday or excuse me, this Tuesday. 

CHARLES MAX_WOOD: Yeah. We have George Georgian, Nickolov. Yeah.

AJ_ONEAL: Oh, okay. Yeah, I see it now. Okay. It's the it's the following Tuesday. It's the March 1 is when we could we could bump down. Yeah, he'd probably be all right with that. Plus, he'd probably enjoy being on this discussion, too. 

CHARLES MAX_WOOD: Yeah. 

FEROSS_ABOUKHADIJEH: So is the idea that it would be like two podcasts? 

CHARLES MAX_WOOD: Yeah, it'd be two episodes. 

FEROSS_ABOUKHADIJEH: Cool. Yeah, that works for me. Yeah. 

AJ_ONEAL: Because I want to continue the discussion. But I also need to get back to work because I'm off cycle because it's Thursday. 

CHARLES MAX_WOOD: Right. 

FEROSS_ABOUKHADIJEH: Cool. Yeah, thanks for all the good questions. Yeah. I realize there's like a lot to discuss here. It's not, it's, it's not simple. And I, I mean, even the discussion at the beginning on the, on the like way we code these days, that could have been a whole episode. 

CHARLES MAX_WOOD: It could have been. And what's interesting is, is that kind of bringing this back into a conversation. Those approaches aren't wrong. It's just the reality is, is that at some point you're going to need to depend on some open source code for anything that's reasonably complex and at that point you really want to know that yeah, you're not exposing yourself or your employer or your customer or whoever, right? Your client, if you're freelance to, to things that are going to compromise the integrity of the app. And so yeah, it's super, super interesting just to look at. And I like the approach that you've got as far as yeah, looking at the code and looking for specific patterns. I was, as soon as you said, and we, We grab all the packages that they pull off of NPM and we store them so we can look at them and My brain went that's really smart and not in a condescending way But in a I didn't think of that and it seems pretty obvious to me when you say it way 

FEROSS_ABOUKHADIJEH: So there's so much there's so much interesting stuff in there. 

CHARLES MAX_WOOD: And yeah, 

AJ_ONEAL: yeah It's like what number of terabytes we have to on all of NPM the size of all of NPM Yeah, and how many people are basically hosting their YouTube blogs? Just pre store just for anything. 

CHARLES MAX_WOOD: I didn't think of that either. That's that's what I'm doing next week guys the whole catalog is going to be on NPM. NPM install top end devs. 

FEROSS_ABOUKHADIJEH: Just how the whole thing should make every episode should be its own dependency. 

CHARLES MAX_WOOD: Oh, there we go. And episode two will depend on episode one and episode three will. 

AJ_ONEAL: You can totally get away with it. You can put a couple hundred megabytes in. That's what dependencies are these days. Put a test folder, call it, put it, put a, put a test folder and then put fixture.mp3. 

FEROSS_ABOUKHADIJEH: Yeah. So.

CHARLES MAX_WOOD: So getting serious here for a minute though, it sounds like socket.dev is the place to go to check this out. 

FEROSS_ABOUKHADIJEH: Yeah, socket.dev is where we're putting all the stuff we're working on. You can go to socket.dev, you can look up any package. So all the data's public, you can just search any package name and we'll show you all the things that our analysis detected. And then we also have these scores for each package that sort of try to summarize what the quality of each package is in terms of different areas. So What's the security? What's the quality? What's the maintenance? What's the license? So just give you like an overall picture of the quality. That's the thing you can get on soccer.dev. And then there's also the GitHub app you can install too. Right. 

STEVE_EDWARDS: So Chuck, was this a podcast episode or an infomercial for soccer.dev? 

CHARLES MAX_WOOD: I do bonus episodes with paid product folks. And what I hope we, what, no, what I hope we get to is just kind of where we got here, where it was like, look, there are all these things you can be looking for. Right. And you can go do it on your own, right? If you could write your own script to do it, I mean, whatever, right? This is a non-trivial problem, but you could, right? If you didn't wanna go use socket.dev or pay for a service that does what it does or whatever, I haven't even looked to see what you pay or what level is free or whatever. But the reality is that these are things that people need to think about. And so there's a ton of valuable content here and you can shortcut part of the process by checking out Socket, right?

FEROSS_ABOUKHADIJEH: Yeah, 

CHARLES MAX_WOOD: that's what I aim for with these shows where yeah, we have somebody on that works for a company that solves a problem. 

AJ_ONEAL: So question I have, I just looked at one of my own packages on this. I've got a, a 47 score of maintenance, which makes me sad, but basically the thing is complete. So why, why that's one thing I think is really that I don't like is that when modules are complete, when they when they do what they need to do and the only changes are extremely rare and frequent, they get dinged on all these metric systems. Shouldn't you get 100%? The module is complete. 

FEROSS_ABOUKHADIJEH: Yeah. No, I agree with you. It's hard because if you're choosing something that's a top level dependency, like a web framework or something where there's constant churn and there's always stuff, you don't want to pick a framework that hasn't been updated in two years because you're just asking for sad times. But on the other hand, if you're picking a library that's supposed to do one thing and do it well, then...actually having it not change is a positive. It can be, right? Especially if it's really solid and it's really perfect, then you don't want random API changes in this library that you're using to do one specific thing, right? So it's really hard to make a metric that gets that perfectly right. I think right now on the version of the site you're looking at, we might be slightly too aggressive and that's something that I wanna fix in the next few weeks and make it less, it shouldn't penalize a package for being done. I agree with you, totally. 

CHARLES MAX_WOOD: I'm gonna push on this a little bit Oh, go ahead, AJ. 

AJ_ONEAL: So another question I have is, so what this is, it's at root request. It's a drop in replacement for requests. So it's the same API as request, but there's no dependency on AWS or OAuth or any of that. It is literally what, if you're using request in your code, this would be a drop in replacement for almost every use case, right? For the average person. And there is one thing that most of the time you don't need the form data library, but occasionally do because most of the time you're dealing with JSON, right? And so in there, I have this, this little line where if you try to use form data, then it will require it, but it's not listed in the dependencies. And this is on purpose. And I'm wondering it because I don't want it to install that the goal with, you know, I'm very strict on my modules. I do not anything that's a pure development dependency that's tooling. I don't even put it in dev prettier at 2.x, right? It doesn't even, no one ever needs to install it unless they run the prettier script in which time it'll be installed. Same thing with, if there's a dependency where if you're using this particular feature of the library, then yes, you will need to have read the documentation and pre-install this thing that handles that. But what I'm talking about here is most of the time people don't need that, so I don't want to put it in the dependencies because I don't want it to get installed for somebody when they're likely not going to use it. Is there a solution to that problem? 

FEROSS_ABOUKHADIJEH: Yeah, that's interesting. 

AJ_ONEAL: Because I'm using things in the NPM scripts that aren't in the dev dependencies, but that's on purpose because they don't need to be. Because unless you were actually a maintainer, get cloning this and then running those scripts, there is no reason for you to have those things installed. Or, you know, so, so even if I'm doing an NPM stall locally, rather than an NPMCI only production, like there's just, yeah. So there's, there's some of those things. I would love to see like a blog article on, for example, because maybe you can prescribe, this is how we suggest you do this so that you limit dependencies, that you don't have extraneous things being installed, but then you also don't get dinged. 

FEROSS_ABOUKHADIJEH: Right. Yeah. I mean, that's a great suggestion. I think we need more information for each of these detections to explain what you can do to like what we recommend doing instead. I think what you're doing, it makes a lot of sense. You basically don't want to, you're trying to solve the problem you were complaining about earlier about too many transitive dependencies being installed by like...defaulting to not install them unless they're needed. So yeah, I think for this specific issue, I would probably try to do some dependency injection. So like you have the user pass in their own implementation of the module instead of like assuming it's gonna be there. You could tell them like maybe they could pass that into the constructor and say, this is the form, the version of form data to use. And I went and installed it and required it so that your package doesn't have to like require a thing that's not in its package JSON. But yeah, I don't know. We can look at that further. I'd love to get more of your thoughts if you find more of these things that you think it's being unnecessarily harsh on because we're still tweaking the score. 

AJ_ONEAL: Well, I'm, I'm all in on this tool by the way. I, I'm, this is one of the first, uh, dev developer tools in this category that I'm, I'm looking for the pay me money button right now, actually. Where is that? 

FEROSS_ABOUKHADIJEH: Yeah, we're, we're right now, we're planning to make it free for open source and then charge for private repos. So if you want to install the the GitHub app on a private repo will charge for it eventually, but it's free right now while it's in beta. 

CHARLES MAX_WOOD: Yeah. 

AJ_ONEAL: Well, I would, I would love to find out what that pricing structure is going to be. Cause a lot of times what it does is it's too big of a jump. It goes from it's free to it's $10,000 a month. And it's like, well, I'm not big time. I can't give you $10,000 a month. Is there a five, $10 a month plan kind of thing, which I don't know. I think you're, you're targeting enterprise and you're probably going to get pushed into the enterprise price point, but gosh, it's If people could just start out not as enterprise, but just as, you know, yeah, I'm commercializing this. Yeah. I want to, I want to pay for this product. 

FEROSS_ABOUKHADIJEH: Yeah. I know. I mean, as, as, as a person, as a developer myself, who wants to use this and like would want to use this on all my projects, even the couple of projects I have that are private, like I don't want this to be a thing that normal like people can't afford. So I, I totally agree. I want there to be, I want it to be accessible to people. So for sure. 

CHARLES MAX_WOOD: I'm going to derail us onto the end of the show. I just wanted to add really quickly when you were talking about the,how much it's maintained. Sometimes that is an indicator if you know, for example, that the node API has changed and you want to know that this library is going to be compatible with those changes if they've deprecated or dropped anything. So it's not enough. It's something to pay attention to. But yeah, different projects are going to have different life cycles on them. Anyway, let's go ahead and do picks and then we'll figure out the scheduling for the next part of this because yeah, I mean, I have questions about a handful of other things related to this that are kind of new topics. That's why I didn't want to bring them in, because I didn't want to trigger another half hours worth of talk on it if we can just do another episode. So, yeah, let's hit the pics and then we'll hit the schedule. 

 

Hey folks, if you love this podcast and would like to support the show, or if you wish you could listen without the sponsorship messages, then you're in luck. We're setting up new premium podcast feeds where you can get all of the episodes released after Christmas 2020 without the ads. Signing up will help us pay for editing and production and you can go sign up at devchat.tv slash premium. 

 

CHARLES MAX_WOOD: Steve, do you want to start us off with picks? 

STEVE_EDWARDS: Yes, I will start us off with a pick. First of all is a version of Wordle, you know, the word, the little popular word game. And there have been many variations of it. I've talked to two people in the view community that have done variations using view with light tweaks. But I found one yesterday that was really funny that instead of guessing a five character word, you try to guess a sha256 hash and it's really, really funny. So it's called, I got to find it again on here on Twitter, but yeah, it was, yeah, here it is. It's a GitHub repo. It's just a page from a GitHub. Passwordl is what it's called. So I'll put the link in there. And then, you know, the highlight of the dad jokes, you know, in the past, I've always talked about my sorted work history, like when I got fired for my first job at a bank because an older lady came in and asked to have her balance checked and so I pushed her over. So anyway I was, oh gosh, I just lost my joke here. Give me a second here. Okay, so in the past, I always liked Valentine's Day and I used to open a lot of letters on Valentine's Day but that was why I got fired from the post office. Thank you. And then last question, what do you get when you cross a police officer with a skunk? Law and odor. I was a big Law and Order fan, so that's why I liked that one. Anyway, that's it for me. 

CHARLES MAX_WOOD: Don't laugh. It only, it only encourages him. 

STEVE_EDWARDS: I heard him laughing, so it's too late, Chuck. 

FEROSS_ABOUKHADIJEH: Sorry. I didn't realize that we were, we were doing standup for our picks. 

CHARLES MAX_WOOD: Uh, I don't know if it qualifies. Anyway, Amy, what are your picks? 

AMY_KNIGHTS: Sorry, I had to find the mute button. Okay. I don't know if anybody can hear this noise behind me. I've been like trying to look through my picks and like all my star stuff is Kubernetes related. And 

CHARLES MAX_WOOD: do it.

AMY_KNIGHTS: I'm so out of time for a fix. I don't know. I'll drop one. I haven't really had a chance to look at it, but it's basically like chaos engineering for your cluster. I'll drop a link for that. It looks kind of fun. Definitely want to spin up my own cluster and not do this on a work one. Unless I'm the one on call that week, then maybe that would be fun. But going back to this noise that is probably going off behind me. So I am sitting right now because it's been a very busy morning. I usually do it. I have a Peloton. I usually ride that every morning. I didn't get to do it today because I had...prod stuff I had to do early this morning. And when I get done with my ride, I usually put these things on my legs, which is what you can hear and they're called Normatec compression sleeves. Brass is nodding like he knows what I'm talking about. So I'm sitting in these right now and it's usually like you can go usually to a place near you. It's like $25 for 30 minutes. I just use my HSA card to buy a pair myself. So they're pretty expensive. But if I was paying $25 a pop to go, then I might as well just...pay for my own pair. But if you're, you know, a little bit athletic and like to push yourself like I do, they help tremendously. So you can think of them, they're like this giant like blood pressure cuff, but they go around your legs. And so after you get done with a workout, they just like help speed up recovery. I swear by them. So that's the noise that people can hear that behind me. And that'll be my second pick. 

CHARLES MAX_WOOD: Holy cow. Yeah, those suckers aren't cheap at all. 

AMY_KNIGHTS: They're not, but...I was like, I haven't been, because of COVID, I don't do a heck of a lot anymore. I haven't traveled since 2019. So, I haven't been to the doctor in three years. I have an HSA. My HSA card covered all of it. 

CHARLES MAX_WOOD: Oh, wow. Yeah. 

AMY_KNIGHTS: I mean, I try to invest my HSA. So, I did, it's $800 or however much those things are now that I don't have in my HSA anymore. But heck, when you have an HSA card and you have the...less expensive interns from work. Like just getting sick twice is going to be $800. So, you know, I figured to pay for it, pay for him that way. So anyway, 

FEROSS_ABOUKHADIJEH: this thing looks awesome. I'd love to try it. I'm a person myself way too hard all the time. I'm like a weekend warrior because I never get time to run during the week. And so I'll go out and do like a, like an eight mile run on, on Saturday. And then I'll just be wrecked for the, for the rest of the week. 

AMY_KNIGHTS: Yeah. I would say try to find a place near you that has a pair and you can try them a couple of times, make sure that you like them. And then if you do, I mean,Like I said, I was paying $25 to go a couple of times a week, so it pays for itself eventually. 

CHARLES MAX_WOOD: Yeah, I've been doing triathlon training, so I'm kind of in the same boat. My Peloton is the indoor rider that I put my tri bike on. 

AMY_KNIGHTS: You'd be surprised what you can buy with an HSA card. 

CHARLES MAX_WOOD: Yeah, that's awesome. 

AMY_KNIGHTS: That's my sub tip, I guess. 

CHARLES MAX_WOOD: Very nice. Was there anything else I don't want to cut you off? 

AMY_KNIGHTS: No, no, that's it. Okay. I might jump. It was very nice to see you all. I haven't been here for a while. So hopefully I'll be back again soon. 

CHARLES MAX_WOOD: We missed you. 

AMY_KNIGHTS: Yep, totally. 

CHARLES MAX_WOOD: All right, AJ, what are your picks? 

AMY_KNIGHTS: Bye. 

AJ_ONEAL: So first and foremost, I'm picking socket.dev because this is awesome. 

CHARLES MAX_WOOD: I've heard of that. 

AJ_ONEAL: This gives you such great overviews. I really, I want to have some chat with you out of band for us about, well, basically things that, you know, we're already discussing, how do we get the score to look better for things that actually are really good and not get false negatives. And then I'm actually going to ask one more question real quick. Is there some sort of like a, some sort of config file that you can say, Hey, it's expected that this should use the network. It's not a, it's not a potential vulnerability. It's yeah, this is, this is a request library. It should use HTTP. That's, that shouldn't be a flag. Is there like a socket dot Jason or something like that? You do. 

FEROSS_ABOUKHADIJEH: We don't do that yet. But that's, that's a good idea. I mean, I think you have to be, you got to think about the use case where you have a malicious person publishing the package and saying, you know, everything's fine, you know, so there's a little bit of that. 

AJ_ONEAL: Yeah, but just to say, you know, like, like typically on the phone, it says, well, why do you want to use? Why do you want access to network? Because it's going to check your email. You know, does it make sense? Does it make sense? Yeah. Anyway, I'm also going to pick, because we're in this vein, I'm going to pick bundle phobia, which is this nice site that also tells you how scary your dependencies are. And it and it does it in terms of weight what the size is, how many kilobytes it is transitively per the package and transitively. And then there's another site, which I actually pasted into the chat, but then the chat got deleted because I had to refresh because I switched networks. Let me see if I can grab it real quick. It is npmgraph.js.org, which is like Bundlephobia, but it gives you the scary visualization of how those transitive dependencies look in terms of breadth and in terms of depth and in terms of, I guess, cyclical as well. But you can see how everything relates to each other. So I'm definitely going to pick those couple of things. I'm so glad that we had you on to talk about Saka.dev. This is quite amazing. It even shows you co-maintainers, which is a good metric of how involved is this person in the community. It's just...Oh, so much good stuff here. I love this. I love this. I'm going to pick saga.dev again. 

FEROSS_ABOUKHADIJEH: Oh man. You're being too nice. But by the way, let me know if you have other ideas. Cause like, we want this to be like the dream, like package search site. Like, I don't know why the NPM website hasn't improved since like five years. I've not to rag on them too much, but like, it feels like there's so much potential for interesting data to show on these pages. So let me know if you have other good ideas. 

AJ_ONEAL: Well, I've got an idea I'd like to discuss with you out of band, but basically getting paid source. 

CHARLES MAX_WOOD: I think we just need to do an episode on that, AJ, because it sounds like you've got some ideas around it and I'd like to give it proper air. But yeah, I'm gonna jump in with some picks and then we'll let Feroz have his turn. So I usually do a board game pick. I think I might have missed the board game pick on the last round because I was fired up about something else. And I think I also picked in Kanto last time, but we're within the same week and so it throws off my whole schedule. So I'm gonna pick Seven Wonders as the board game this week. In Seven Wonders, you kind of have this cardboard placard, I guess, in front of you that has a wonder that you're trying to build. And then you build your city, and your city gives you resources, and you get resources for just playing. And then you can also build armies, and you get points for your army size at the end of each round. You get points for buildings that you build. You get points for buildings that match in specific ways. Like there are different sets that...match in certain ways and then you get points for basically uncovering your wonder. And so this is one of those games honestly and I think it's hilarious because most of the time I'll be playing a game with somebody and I know if I'm winning or not, right? I can usually tell. This game I never have any clue until the end of the game when we tally up the points, right? Sometimes I have a feel that I did better than normal but that's better than normal for me not that I was winning. So anyway it's a fun game. It's a rather popular one. It seems like a lot of folks that are into board games have it. So I'm going to pick that. And then the other pick I have is Airmeet. And so Airmeet is the system that I'm going to be using to run the workshops, conferences and meetups on topenddevs So if you're looking to level up on stuff, most of the workshops that I have scheduled are career focus, right? So the first one is kind of long-term planning your career. Like where do you want to end up? Right? Do you want to end up doing open source stuff? You know,company stuff like for us, or do you want to be a speaker and podcaster, or do you want to be kind of the hero, the tech hero at whatever company you work for, or? And the great thing about it is, you know, we'll talk about how to evaluate that so that you're heading towards something that'll make you happy. And then the next one, I keep getting asked, how do you stay current? How do I stay current? Which often translates into what should I be learning next? So that's the next workshop. I don't know if this is going to come out after those. But I'm pretty well committed to doing a workshop every week, unless I'm on a family vacation or something, something that I already have planned. It looks like I'm probably going to be doing them on Wednesday afternoons. But anyway, you can go check it all out at topendevs.com slash events. And I'm planning on inviting other people on. So I could foresee inviting Firas on and having him do a workshop on how to make sure that your app's secure, or have somebody else come on and do a workshop on that, whatever they're good at. And then I have. I'm good friends with a lot of people in the community that have a wide depth of knowledge or wide breadth of knowledge, wide depth of experience. So anyway, looking forward to that. But AirMeet, so what we're going to run it on and the reason is, is because they have a feature where you can effectively open up tables and let people get on and talk to each other. And I feel like the networking is just as important as the content. And I want to open that up to people, especially since I talk to people and I'm like, you need to go to a meetup. And they're like, well, I looked and there was one here, but they haven't done it since the pandemic started. And I just find that exceptionally disheartening. And so I want to open that up to people and the upside of this too is that you get to meet people all over the world. So anyway, those are my picks. And all of that will be at topendevs.com slash events. Like I said, I'll have the workshops, the meetups and the conferences as we get that together. All right, for us, what are your picks? 

FEROSS_ABOUKHADIJEH: I'll start by picking fetch in Node.js. So the fetch API landed in Node17 and that means that we can no longer, we no longer need to install node fetch or any of these goofy polyfills anymore. It's just the next step in how node is becoming a browser. But in this case, it's actually good. I think that the fetch API is actually quite good for like a built-in API. And so having that just be available in node will make that be one less like thing you have to install. It's just a good thing, I think. So That's yeah, I'm just excited about that change and I can't wait till I can actually use it in my in my code also shout out podcasts So there's a podcast called darknet diaries that I highly recommend have any of you guys heard of it? 

STEVE_EDWARDS: Yeah I've heard of it. I've listened to it, but I've heard it mentioned elsewhere. 

FEROSS_ABOUKHADIJEH: Okay. Yeah, you would love it Every almost every episode is is gold. It's like basically it's stories about cybercrime But the host is really good at explaining things in a clear way and an understandable way. So there's not a lot of jargon or if there is, it's explained well. And then it just gets into the people behind it. So he'll interview oftentimes people who are either like criminals who went to jail and they'll talk about like what their story of how they got into internet crime, spamming, selling drugs on the dark web or whatever. And you get this glimpse into a part of the like cyber underworlds that you normally just you don't normally don't get because you actually get to hear from them. And then, so it's just really, it's really interesting. And then they'll also interview security, security, like industry people who do like really cool stuff for their jobs. So they'll interview, sometimes they'll interview people who like do incident response. So like, they'll talk about, you know, the time that a big company got hacked and like what they did, like what it was like being in that room and what are the kinds of things the attacker was doing and how they were trying to stop it. So it's all just like really good narrative. Like basically every, every episode has a really good story to it. Some of my favorite ones were episodes that they had about physical security. So there's actually a job you can have where you go and try to break into banks and the bank pays you. So that's like, just, I didn't really know that much about that. And just hearing about that was super, super interesting. You know, they'll their job was like, find a way into the bank. And so they'll just scope the bank out, you know, find the door in the back that isn't open, that sometimes is left open, or they'll, they'll use crazy like James Bond contraptions to like break into the, to the building. And then we'll talk about how. They're trying to find a computer to plug their USB stick into. It's like a movie, but it's like real life. So it's pretty fun. Highly recommend it. And then I'll also just shout out one other podcast called Risky Business, which is if you're trying to get into the security industry and just learn about security, it's kind of a fun weekly news recap of all this cybersecurity news and events from the week. Yeah, those are my picks. 

CHARLES MAX_WOOD: Awesome. One more question for you. People want to connect with you online. Where do they find you? 

FEROSS_ABOUKHADIJEH: I'm on Twitter, just for us. My name is Feroz. F-E-R-O-S-S.can follow me there or my website for us.org and you know socket is socket.dev. Those are the URLs. 

CHARLES MAX_WOOD: Awesome. All right. Well, we'll, uh, we'll get part two scheduled and then until next time folks max out. 

STEVE_EDWARDS: Adios. 

FEROSS_ABOUKHADIJEH: See you later. 

AJ_ONEAL: Adios. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit c a c h e f l y.com to learn more.