It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder

Rate this content
Bookmark

Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.


You can check the slides for Feross' talk here.

26 min
18 Feb, 2022

Video Summary and Transcription

The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.

Available in Español

1. Introduction and Stories

Short description:

Hello and welcome. Thanks for coming to my talk. It's a jungle out there. My name is Firas, and I'm an open source maintainer. I started WebTorrent, and StandardJS. I've been doing open source since 2014. In the past, I volunteered on the Node.js board of directors, and I also teach a class on web security at Stanford University. Now I'm the founder of a startup called Socket, which helps protect the open source ecosystem. Let me tell you a story. On January 13th, 2012, a developer named Faizal Salman published a new project to GitHub. It was called UAParserJS, and it parsed user agent strings. Over the next 10 years, Faizal continued to develop the package, and it eventually grew to 7 million downloads per week, being used by nearly 3 million GitHub repositories. Now, let me tell you a different story. On October 5th, 2021, a hacker was offering to sell the password to an NPM account that controlled a package with over 7 million weekly downloads. Two weeks later, uaparser.js was compromised, and three malicious versions were published. Malware was added to these packages that would execute immediately whenever anyone installed one of the compromised versions. Now, let's take a look at what that malware does. It uses a pre-install script that splits based on the operating system of the target. On Mac, nothing happens, but Windows and Linux users aren't so lucky.

Hello and welcome. Thanks for coming to my talk. It's a jungle out there. What's going on inside your modules folder? My name is Firas, and I'm an open source maintainer. I started WebTorrent, and StandardJS. I've been doing open source since 2014. In the past, I volunteered on the Node.js board of directors, and I also teach a class on web security at Stanford University. Now I'm the founder of a startup called Socket, which helps protect the open source ecosystem.

Before we get started, let me tell you a story. On January 13th, 2012, over 10 years ago, a developer named Faizal Salman published a new project to GitHub. It was called UAParserJS, and it parsed user agent strings. Now, lots of people found this project useful. And so over the next 10 years, Faizal continued to develop the package, along with the help from many open source contributors. He published 54 versions, as the package grew in popularity. It eventually grew to 7 million downloads per week. Eventually being used by nearly 3 million GitHub repositories.

Now, let me tell you a different story. On October 5th, 2021, on a notorious Russian hacking forum, this post appeared. A hacker was offering to sell the password to an NPM account that controlled a package with over 7 million weekly downloads. His asking price was $20,000 for this password. Now, this is where the two stories intersect. Two weeks later, uaparser.js was compromised, and three malicious versions were published. Malware was added to these packages that would execute immediately whenever anyone installed one of the compromised versions. So, now let's take a look at what that malware does. So, this is the package JSON file for the compromised version. And you'll see that it uses a pre-install script. So, this means that command will run automatically any time this package is installed. So, now let's look at what that script does. So, the first thing you'll see is that it splits based on the operating system of the target. On Mac, nothing happens, which is lucky for Mac users, but Windows and Linux users aren't so lucky.

2. Malicious Package Attack

Short description:

And you'll see here that command prompt has spawned for each of these platforms using child process.exe. Now, let's take a look at what that pre-install.sh script does. It fetches the user's country and proceeds to download an executable file. This program is a Monero miner used to mine the Monero cryptocurrency. On Windows, the script downloads a DLL file that steals passwords from over 100 different programs and the Windows credential manager. This package was published for about four hours, compromising those who installed it during that time. Over 700 packages have been removed from NPM for security reasons in the last 30 days. The trend of attacks on the open ecosystem and trust among maintainers is accelerating. 2022 will be the year of supply chain security. The system of downloading code from the Internet and executing it with full permissions is risky, but it's a miracle that it has mostly worked for this long.

And you'll see here that command prompt has spawned for each of these platforms using child process.exe. So, now let's take a look at what that pre-install.sh script does. The very first line fetches the user's country and figures out whether the from Russia, Ukraine, Belarus, or Kazakhstan, and stores that in a variable. Now, if the user comes from one of those countries, then the script exits without doing anything further. However, if you come from any other country, then the script proceeds to download an executable file from this IP address, mark that file as executable, and then run it.

And now based on these command line flags, you can see here that this program is a Monero miner, which is going to be used to mine the Monero cryptocurrency for the attacker. Now, this is the script on Windows. It's very similar. So it starts off with downloading that same or similar Monero miner, but it also downloads a DLL file as well and runs that. And then here you can see it just starting up the Monero miner and registering the DLL file on Windows.

Now, what does this extra DLL file do? Well, it steals passwords from over 100 different programs on the Windows machine, as well as all the passwords in the Windows credential manager. So, yikes, this is a really nasty piece of malware. And, you know, anyone unlucky enough to run this lost all their passwords and had to do, you know, kind of a complete reset of their online accounts. Not a fun time. So, this is kind of the aftermath. So, this package was published for about four hours. And the open source community was pretty diligent and reported it, and the maintainer was also quite diligent. And so, you know, anyone who happened to install it during the four-hour window was compromised, but it was removed relatively quickly. Any software builds done in projects without using a lock file were compromised. And anyone who was unlucky enough to update to this new version of the package or maybe who merged a bot PR to update to this new version during this time would have also been compromised.

So, this was big news in the JavaScript world, and I'm guessing you may have already heard about this attack. But this is really just the tip of the iceberg. So, we've been tracking packages that are removed from NPM for security reasons, and we've seen over 700 packages removed for security reasons in just the last 30 days. And I think this trend is accelerating as attackers take advantage of the open ecosystem and the trust that maintainers have for each other and the sort of liberal contribution policies that we've all sort of adopted in the modern open source era. So, I think 2022 will be the year of supply chain security, as the awareness of this issue is now coming to the fore. So, one question you might ask is, why is this happening now? I want to start by just pointing out that what we're trying to do here is kind of crazy. We're trying to download code from the Internet, written by unknown individuals that we haven't read, that we execute with full permissions on our laptops and our servers, where we keep our most important data. So, this is what we're doing every day when we use NPM install. And I just have to say really quickly that I personally think it's a miracle that the system works. And that it's continued to mostly work for this long.

3. Open Source and Security Risks

Short description:

90% of your app's code comes from open source, allowing us to build powerful web apps quickly. However, the abundance of transitive dependencies and the lack of code review create security risks. The Node modules folder is a massive collection of packages, and the visualization of Webpack shows the complexity. People rarely read the code they execute, and npm doesn't make it easy to review packages. Relying on Linus' law, we trust others to find security issues, but this can lead to malware going undetected for months. These findings highlight the importance of supply chain security in the open source ecosystem.

It's a testament, I think, to how good most people are. But unfortunately not everyone is good. So, let's dive into why this is happening now. The first reason is that 90% of your app's code comes from open source. So, we're really standing on the shoulders of giants. And open source is the reason why we can get an app off the ground in hours and days instead of weeks or months. And it's the reason that we don't need to be an expert in cryptography or in time zones or the virtual DOM to build a powerful modern web app. It's also the reason why your Node modules folder is one of the heaviest objects in the universe.

Another reason is that we have lots and lots of transitive dependencies. The way that we write software has changed. We use dependencies a lot more liberally. And so, installing even a single dependency often leads to many, many transitive dependencies that come in as well. A 2019 paper at the Usenix conference found that installing an average package introduces an implicit trust on 79 third-party packages and 39 maintainers, creating a surprisingly large attack surface. And so, what we have here is a visualization that my team at Socket created that shows you what Webpack looks like. If you kind of go into the node modules folder and really look at what's inside. Each gray box represents a package and each purple box represents a file or files inside of a package. As you take away each layer of the dependency tree, you'll find more packages inside the top-level package until you get down to the bottom. This is just an insane number of files and just a lot of modules flying around here.

The next reason is that no one really reads the code. There are some people who do, but by and large, people don't look at the code that they're executing on their machines. One big reason is that npm really doesn't make this very easy. If you go to the package page for UAParser.js and click on the explore tab here, you'll see that you can't even see the files of this package, so people have to resort to clicking the GitHub link and going and checking GitHub and hoping that the code on GitHub matches the code that's on npm, which is not necessarily true. But that's okay. That's okay. We can rely on Linus' law that given enough eyeballs, all bugs are shallow. So, if there is a security issue in a package or malware in a package, we can rely on others to find it, right? But if everyone does that, then who is finding the malware? And so, maybe this is the reason why on average a malicious package is available for 209 days before it's publicly reported. This comes from a research paper by Ohm et al. So, that's 209 days during which the wrong npm command can end extremely badly. And I find this number personally very shocking. A 2021 paper at NDSS, a prestigious security conference, also found similar results, including that 20% of these malware persist in package managers for over 400 days and have more than 1,000 downloads.

4. Popular Tools and Supply-Chain Attacks

Short description:

Popular tools give a false sense of security by only scanning for known vulnerabilities, leaving you vulnerable. Distinguishing between vulnerabilities and malware is crucial. Vulnerabilities may be low-impact and can be shipped to production temporarily. However, malware, intentionally introduced by attackers, always leads to negative consequences. Fast development increases the risk of supply-chain attacks. We need a new approach to detect and block malicious dependencies. Understanding the mechanics of supply-chain attacks is essential. Attack vectors, such as typo squatting, trick users into running malicious code.

And the fourth reason is that popular tools give a false sense of security. A lot of popular tools scan for known vulnerabilities. So, in 2022, I believe this is no longer sufficient. We can't just scan for known vulnerabilities and stop there. And yet, that's what the most popular supply chain security products do, leaving you vulnerable.

The thing is, it can take weeks or months for a CVE or known vulnerability to be discovered, reported, and detected by tools. And so, it's just not fast enough. So, it may be worth taking a minute here to just quickly distinguish between known vulnerabilities and malware because they're very different. Vulnerabilities are accidentally introduced by maintainers, by the good guys, and they have varying levels of risk. So, sometimes it's okay to intentionally ship a known vulnerability to production if it's low-impact. Even if you have vulnerabilities in production, they may not be discovered or exploited before you update to a fixed version, so you have some time to address these kinds of issues, usually.

Now, malware, on the other hand, is quite different. Malware is intentionally introduced into a package by an attacker, almost never the maintainer, and it will always end badly if you ship malware to production. You don't have a few days or weeks to mitigate the issue. You need to really catch it before you install it on your laptop or on a production server. But in today's culture of fast development, a malicious dependency can be updated and merged in a very short amount of time. And so, unfortunately, this leads to increased risk of supply-chain attacks, because the quicker you update your dependencies, the fewer eyeballs that have had a chance to look at the code. And so, I really think we need a new approach to detect and to block malicious dependencies. But before we get into that, let's look a little deeper into how a supply-chain attack actually works and the mechanics of it.

So, we downloaded every package on NPM, and we spent a few weeks poking around. The download was 100 gigs of metadata and 15 terabytes of package tarballs. And as we poked around this metadata and all these packages, we noticed a few trends in the types of attacks we saw. So, I'm going to go over these attacks. These are what we found. So, there are attack vectors, which is sort of how the attacker tricks you and gets you to run their code in the first place. And then, there are tactics, which are what the attack code actually does or the techniques that the attacker uses to hide their code. So, let's talk about attack vectors. The first and the most common attack vector is typo squatting. So, typo squatting is when an attacker publishes a package which has a very similar name to a legitimate and popular package. And so, you can see here, there are two packages here with very similar names and one of these is malware and one of these is the real package, but I would guess that it would be hard for you to know that without actually cracking open these packages to see what's inside.

5. Malware Package and Dependency Confusion

Short description:

Let's open up the malware package and see what it's doing. It uses an install script, which is a common technique for malware. The code is heavily obfuscated, but it's definitely something you don't want to run. Another attack vector is dependency confusion, where internal tools accidentally install public versions of packages. We found many likely dependency confusion attacks with malicious code, affecting various organizations.

So, let's open up the malware package and take a look at what it's doing. So, you can see here, again, it's using an install script, which is a very common technique that malware uses. And if you open up this install script to look at the code, you'll find that the file is heavily obfuscated. But I can tell you, even without knowing exactly what this code is doing, you can bet this is not something that you want to run on your machine.

The next attack vector that we saw is called dependency confusion. So, this is pretty closely related to typosquatting. Dependency confusion happens when a company publishes packages to an internal NPM registry and uses a name that hasn't been taken yet on the public NPM registry. So, later an attacker can come along and register a package with the same name as the public version and confuse internal tools, so that internal tools will accidentally install the public version. So, this is why it's called the dependency confusion attack. So, looking through the recently deleted NPM packages, we were able to find a bunch of likely dependency confusion attacks, and most of these packages had malicious code in them. So, all these packages have names which appear to conflict with internal company package names. You can see here a whole bunch of different organizations, including governments, were affected by this. And here are a bunch more, clearly targeting these specific companies here in this list.

6. Hijacked Packages and Attack Tactics

Short description:

Hijacked packages are a common vector for criminals to infiltrate communities and infect popular packages. Attack tactics include malware in install scripts and privileged API usage to steal secrets. Install scripts have legitimate uses, making it difficult to disable them. An example of privileged API usage is making HTTP requests to exfiltrate data, while another technique uses DNS for exfiltration.

And finally, the third vector that we see a lot is hijacked packages. So, these are the ones that you usually see in the news quite a lot. So, criminals and thieves finding ways to infiltrate our communities and infect popular packages. Once they infect a popular package, once they get control of it, and they can publish to it, they'll steal credentials or install backdoors or abuse compute resources for cryptocurrency mining. And so, these happen for various reasons. So, sometimes it's because a maintainer chooses a weak password or reuses a password or maybe the maintainer gets malware on their laptops. This is also kind of not helped by the fact that NPM doesn't enforce 2FA for all accounts currently, although they are starting to enforce this for the most popular accounts. And finally, sometimes maintainers just get tricked and give access to a malicious actor. This is partially just due to the fact that maintainers are overworked and when someone offers a helping hand, it's sometimes hard to say no to the help. So this is also a big vector as well.

So now let's talk about some attack tactics. So what does this attack code actually do? As we mentioned, install scripts are a huge vector. Most malware is in install scripts. And so this is a quote from a paper we mentioned earlier. So most malicious packages, actually 56% start their routines upon installation, which might be due to poor handling of arbitrary code during install. So in the npm package manager, packages are allowed to just say, hey, when this package is installed, we want to run some code. And so unfortunately though, install scripts do have some legitimate uses. So we can't just disable them. It's not an easy problem to solve. So let's take a look at just an example. Another example of an install script, again, you'll see it right here in the package.json file, super common. The next is privileged API usage. So we see packages accessing the network, accessing the file system and accessing environmental variables. This is very, very common because when an attacker runs code, what they want to do is steal some secrets and they need the network to exfiltrate those secrets. So this is a typical example of malware that does that. So you can see here that it's making an HTTP request to an IP address, and it's sending some data. The data it happens to be sending is process.env which contains all the environment variables in the environment. And then here is actually another file that it includes, which is a different exfiltration technique that uses DNS instead of HTTP. So the way this works is it creates a DNS resolver, and then it does a... It gathers the environment variables, and then it does a DNS lookup with those variables as the subdomain.

7. Obfuscated Code and Code Discrepancy

Short description:

Obfuscated code is difficult to understand at a glance, but tools can help unobfuscate it. Attackers can publish different code to npm than on GitHub, making it hard to evaluate packages based on GitHub code.

So it's just another way to get the data out of the system. And finally, we have obfuscated code. So we took a look at an example of this earlier. So obfuscated code like this is just obviously it's really hard to see at a glance what it's doing, although there are tools to attempt to unobfuscate code like this. There's also another kind of obfuscation, which is attackers can publish different code to npm than they do on GitHub. And so you know when they do that, as I mentioned earlier, npm doesn't make it easy to see what code is actually in the npm package. And so a lot of people who are trying to evaluate a package will rely on the code that's on GitHub and there's no guarantee that that code is the same.

8. Protecting Your App

Short description:

Let's talk about how you can protect your app. We worked on a product called Wormhole, aiming to build a secure and private way to send files. We implemented security measures, such as early consideration of security, tests, code reviews, and careful selection of dependencies.

Okay, so now let's talk about how you can protect your app. So we asked ourselves this question when we were working on... My company was working on a product called Wormhole, which lets you share files with end-to-end encryption. And our goal was to try to build the most secure and private way to send files. So we did all the usual security things that we could think about. We thought about security early in the design process. We wrote tests, we enforced code reviews, and we were pretty thoughtful about the dependencies that we chose to use. But, you know, we still felt like we could do better. And so we started thinking really carefully about this problem and what we could do to make it better.

9. Choosing Dependencies and Assessing Security

Short description:

Choose better dependencies and take responsibility for the code you ship to production. The popular MIT license highlights the need for a mindset shift in how we view open source. Relying on heuristics to pick dependencies means we may not be aware of their true behavior. Socket provides a tool to assess the security of packages, highlighting install scripts and binary/native code. Quality scores are also available. For example, the Angular Calendar package has invasive dependencies.

So the first kind of thing I recommend is that you can just try choosing better dependencies. You know, if you shift code to production, you are ultimately responsible for it. And, you know, as an industry, I think we need a mindset shift here because people assume that they can just install stuff from the internet and that it's going to be safe. And it's not necessarily true. And if you're shipping code to production that includes open source code, then really ultimately that code is part of your app. And so you are ultimately responsible for the behavior of that code.

And, you know, the most popular open source license, the MIT license, actually literally says this in the license, it says that the open source code is provided as is with no warranty of any kind and in no event shall the author be liable for any claim damages or liability. And so, you know, while this is legally true, most people don't think of their open source this way. And I think we really do need a mindset shift.

The other thing is very few of us actually read the code that we're shipping to production. And so we rely on other heuristics to help pick dependencies. So maybe, you know, we look at does the code get the job done? Does it have an open source license? Does it have good docs? Does it have lots of downloads and GitHub stars? Does it have recent commits? Does it have types? And does it have tests? And we're not really cracking open the code to go much beyond this. So what that means is that we're sort of not aware of what the code may be doing.

And so, we built a tool at Socket to help with this problem. So you can quickly at a glance get an idea of the security of a package. And so this is what it looks like. So you can go to Socket and look up packages to figure out what behavior the package has. And so in this example here, you can see that this package contains install scripts. And that's called out very prominently on the page. So it's the first thing that you see. And this package also happens to contain binary, you know, or native code, which means that it's not easy to audit the code. It's not like a human readable. And so both of these issues are called out. And in this case, it's not necessarily this is not a supply chain attack by any means. But it is nice that this is called out very prominently so that you can make an informed decision if you want to use this package or not. You can also see that we have very helpful quality scores that show up at the top of the page as well.

Now, let's take a look at another example. So this package here, Angular Calendar, is quite a useful package. It's a calendar component that shows up on the page and renders a little calendar. But if you dig into its dependencies, you'll actually find that some of its dependencies are doing quite invasive things.

10. Dependency Management and Security

Short description:

One of its dependencies contains install scripts, runs shell scripts, and accesses the file system and network. Research packages on Socket before using them to make an informed decision. Updating dependencies requires finding the right balance between known vulnerabilities and supply chain attacks. Auditing every dependency is an option for security-critical applications, but it comes with tradeoffs and challenges.

So here, you'll see that one of its dependencies contains install scripts. It also runs shell scripts and accesses the file system and accesses the network. So this is probably not something that you would expect a web component to be doing. And so it may be worth a little bit of further investigation to figure out what's going on here before you use this package.

The other thing that we do that's quite cool is we can highlight when packages do these things, and put that directly in line in the code. So in this package here, I opened it up to take a look at the files. And I could see here that the module is accessing the network, as well as accessing environment variables. And I can see the exact lines where the package is doing each of these things. And so it makes it a little bit easier to get an idea of what a package is doing before you run it.

So if you want to research packages on Socket before you use them, this is the URL you can use. And I highly recommend you take a look at some packages there, and use that information to make an informed decision before you select a package.

Okay, the other thing you can do is think about updating your dependencies at the right cadence. So what do I mean by this? So there's a question about, like, how quickly you should update your dependencies. And this is actually a question we struggled with on our team as well. So if you, you know, you can think of it as should we update slowly, or should we update really, really quickly and aggressively? If you update too slowly, you're exposed to known vulnerabilities. And you're running code that's old and that you know, may have issues, may have some bugs that have been fixed in the newer version. And so there's some downsides to updating too slowly.

On the other hand, if you update too quickly, you expose yourself to supply chain attacks, because you're now running code that may have been published, you know, literally yesterday or, or in the last couple of days, which means that you haven't had that many eyeballs able to look at the code. And so, you know, if as you think about security, you have to balance, you know, this, this tradeoff, and there really is no perfect solution here. It's just a hard problem.

Another idea is to audit every dependency. So, you know, if you're building a truly security critical application, like we were doing with wormhole, then you, you know, one option is to literally read every line of code of your dependencies. So if we, again, put this on, on an axis of starting from full audit on the one hand, reading every line of code to YOLOing on the other hand, and, you know, by YOLOing, I mean, like doing nothing? How closely should you audit your dependencies? And what you see here is we're in the same situation. We have tradeoffs and really no good, no good solutions. So doing a full audit is something that only the biggest and richest companies seem to do in practice. It's a lot of work. Usually you need to have a security team looking at every one of these packages, and we also have to approve them one at a time and add them to an allow list, which is really slow. And this is expensive just because of the time and the effort that it takes. On the other hand, doing nothing and just installing whatever you want without, even looking at the code, has its downsides. So it means that you're vulnerable to supply chain attacks.

11. Automation and GitHub App

Short description:

It's risky. And most teams are on the side of doing nothing. We used automation to evaluate dependencies and manually audit the most suspicious packages. The security information is shown directly in pull requests, empowering developers to solve security issues before deployment. Our GitHub app runs a full health report on new dependencies, leaving comments on any issues discovered. It augments the review process and only raises issues worth attention. Try our free GitHub app at Socket.dev to block typosquats, malware, hidden code, privileged API usage, and detect suspicious updates.

It's risky. And a breach or bad security press can be expensive, especially as regulators start to crack down on this issue more. And so this is another difficult trade-off. What do you do? And most teams, I think, are on the side of doing nothing, and, but I think this is just a hard problem.

So one thing that we tried to do when we were building Wormhole is to sort of think about, happy medium. Is there a way to use automation to kind of do something in the middle? And so what we want to do and what we've, what we ended up doing is using automation to automatically evaluate all of our dependencies. So we could use static analysis to look through packages to try to find malware, hidden code, typos, squatting attacks, and this kind of thing. And that way we can manually audit only the most suspicious packages. So we could spend our limited team resources looking at the code for the most suspicious packages. And that's the most high impact way that we could spend our time. And so this is, this seems much better to me than an all or nothing approach where you either audit everything or you just hope for the best and look at nothing.

And then the other thing we wanted to do is make sure that the security information was shown directly in pull requests so that the developers on our team were empowered to solve the security issues that they saw before they deployed into production. So what does this actually look like? So this is the bot that we created. It's implemented as a GitHub app that you can install on your GitHub repository. And whenever it sees that the package json file or the yarn.lock file has been modified, it will take a look at the new dependency that's been added and it will run a full health report against that dependency. And if there's any issues found in it, it will leave a comment with whatever the issue is that was discovered. So that way the developer reviewing the pull request can look at it and have their attention drawn to this potential issue. In this screenshot here, you can see that I accidentally installed the package browser list instead of browser list, which is actually a very easy mistake to make. And for that reason, the typo package actually has something like 700,000 downloads a year. So this is really, really helpful. This is the kind of thing that augments your review process. And it's very low cost since it only raises issues that are really worth your attention. And it runs automatically. So if you want to actually try this app out, we've actually published it for anyone to use. It's free. So you can install our GitHub app by just going to Socket.dev. And I recommend you give it a try and let me know what you think. It has a bunch of cool features. So it actually can block typosquats, which as I just showed you earlier, but also can block malware, detect hidden code, detect privileged API usage, such as the use of file system network, child process, etc. And also it can detect suspicious updates.

12. Package Analysis and Feedback

Short description:

We have 70 detections in five different categories: supply chain risk, quality, maintenance, known vulnerabilities, and license. Our static analysis rules focus on actionable problems that users of the package need to know. Try Socket.dev to explore these issues and provide feedback. We aim to improve supply chain security in 2022 and protect it better than ever. Share your feedback with me via email or Twitter. We're also hiring at Socket if you're interested in securing the software supply chain.

So these are updates that significantly change the package's behavior. So we have a whole bunch of things we look for in packages. We actually have 70 detections in five different categories. So we have supply chain risk, quality, maintenance, known vulnerabilities, and license. And we wrote, basically, these are just all static analysis rules that we wrote. You can kind of think of this as a linter in a way. So it's sort of looking at the package's code and then looking for these different problems. We tried to focus all of the rules on problems which are something that you, as a user of the package, really want to know about, and not things that require a lot of knowledge of the internals of the package. So the things that it finds need to be actionable to you as the developer choosing to use this package. And so that's what we tried to do in our rule development here.

So yeah, if you want to try this out, if you want to poke around our website and look at these different issues, you can try it out at socket.dev. And we have made it free for open source forever, and if you have a private repo, it's free while we're in beta, and I really do want people to give us a shot and share their feedback with us, because this supply chain security problem is big and only getting bigger. And I really do want the community to share their feedback with me on this. And I think together we can really do a good job improving supply chain security in 2022 and making 2022 not the year that the supply chain is destroyed, but rather the year that it's protected better than ever. So please share your feedback with me. There's my email and my Twitter, and also we're hiring at Socket if you're interested in working on this project and helping to secure the software supply chain. Thanks for your time.

Hey, thanks for joining us. Glad to be here, and I didn't mean to scare you. There's a lot to do, there's a lot of solutions, so I wouldn't be too scared. I think we can solve the problem, hopefully. Hopefully, well, most people are very concerned and want to do more. Well, it's good. I feel happy that people want to do more, but they should do more. Well, they can do so with Socket.dev. How do you feel about this? This deviation, 70% and then 27% moderate, and 3%, not at all? I'm actually pleasantly surprised that we have this many developers who are concerned about the issue. Now, I don't know how much my talk influenced their voting as they were watching. I was probably helping push this number up by all the examples I was going over of malware and supply chain attacks that have happened on NPM. But I think it's encouraging that people want to do more and that there are actually some things they can do to help with that, including installing Socket or checking out our tools. Yeah.

13. Differentiating Socket from Other Security Tools

Short description:

There are multiple security scanners, but what sets Socket apart is its ability to scan a package by analyzing its actual code and determining its capabilities. Socket goes beyond basic vulnerability scanning and protects against malware and supply chain attacks. This approach ensures that users are aware of the potential risks before installing a package.

So, first question is from myself. There's multiple security scanners. I know from the top of my head, we have StackHawk and we have Sneak. And what sets your product apart? Yeah. So, I think the main thing to keep in mind when evaluating tools like this is if they will protect you from just vulnerabilities as well as malware and supply chain attacks. So, it's almost like a standard. I would say that there are tools to scan for vulnerabilities. That's what NPM audit does. That's what Dependabot does. There's a lot of stuff out there that does this kind of, I would say basic vulnerability scanning. The real threat that we've seen in the last year is from this new type of attack, supply chain attacks that involve usually a package being hijacked and code being added by a bad guy. And there's this period where before that is discovered, anyone who installs that hijacked package is going to have their computer compromised. And if you're really unlucky, this isn't discovered for a couple of weeks and it makes it into production. And this has happened in many cases in the past. And so I think the way we want to distinguish Socket from all the other stuff that's out there is what can you actually do to scan a package by looking not at some database to say, has a security researcher found a problem with this and written a report about it a couple of weeks ago, the question is really, what is this package going to do? Like what are its capabilities? Is it going to talk to the network and is it going to read files and we're going to analyze the actual code in the package before you install it to answer those questions for you? And so that's really the difference. And that's where I think we need to go with all the tools in this security space.

14. Challenges with Existing Approaches

Short description:

A maintainer adding malware or bad code into their own package poses a significant challenge for existing approaches like code signing and vulnerability databases. The incident highlights the need to analyze the actual code to understand its behavior. Reading all the code in dependencies is time-consuming, so security scanners can be helpful.

And a little bit related. So I don't remember the name of the package, but there was a really popular package, and a month or two back, the author pulled it from GitHub and said, free Aaron Swartz, something like that. Do you remember what I'm talking about? So yes, this will be also caught because you have a significant code change, right? So also catch those issues. Yes. It's not enough to, this is a perfect example actually, where a lot of the approaches that other companies and other teams who are trying to solve this problem are taking wouldn't have really caught this problem because this is where you have a maintainer themselves adding malware or bad code into their own package. And so relying on things like code signing, for example, would not have really done anything in this case because the maintainer himself would have had the keys to sign his code. Or if you're looking at a vulnerability database, this is not going to be in a vulnerability database. And so, sorry, I'm getting a phone call right now. Yeah. So anyway, I think that incident was actually really illustrative of the challenges with the other approaches and why really what you want to do is get into the actual code and look at what it's doing. Yeah. I used to work at a medical tech company. And then it was always the scenario if you do an update, then you actually would have to read all the code that was new. And yeah, so I tried to avoid any dependencies because well, that's just too much work to read everything that's new in all your dependencies. So yeah. But yeah, having security scanners would help a lot.

15. Realms and Deno's Command Line Flags

Short description:

Realms are an interesting proposal that could potentially sandbox code and enforce runtime behavior restrictions for packages. Deno's command line flags, although at the process level, provide some interesting ideas. However, they are less effective for stopping supply chain attacks.

The first question is from Will Shadow real address some of these issues? So I think realms are an interesting proposal. And I think they've been making some pretty good progress through the standards committee. Although I'm not really following it very closely. So I might not be the best person to ask this question to, but my understanding is there should be some way to use this feature, this realms feature to kind of sandbox code. And I know it's really tough to get a sandbox to work really reliably, but if this feature works the way that I think it does and if a bunch of asterisks attached to this statement, we may eventually be able to use a feature like this to go beyond basically just analyzing a package and saying, OK, this is going to talk to the network or this is going to talk to the file system. But actually at runtime, being able to say for a package, this package declares that it doesn't ever need to talk to the network and in fact we're going to actually enforce that at runtime. We're going to make sure that it doesn't do XYZ behavior that it doesn't need. And so if it suddenly starts to do that, then we'd be able to block that. I think it's also interesting to look at deno and see how they do their command line flags where for those who've played with deno a bit, it has this sort of idea of like allow fs, allow net that you can pass on the command line that's pretty interesting. Although that's pretty much for an entire process and not on a per package basis, which kind of makes it less useful for stopping supply chain attacks, because usually you have to allow the network if you want to build a web server. And so it doesn't really give you much protection if one of those dependencies gets compromised. But it is an interesting place to go from.

16. Securing Dependencies and Prioritizing Security

Short description:

Getting engineers to care about securing dependencies is a tough problem. There's always technical debt and a backlog of tasks to ship features. However, as craftsmen, we should take pride in the software we create and ensure it doesn't compromise user data. With the right tools, like Sockett, securing dependencies can be made easier and even enjoyable. Security should be prioritized over other aspects of development, such as fancy command line settings and animations.

Yeah. All right. Thanks. We have one more minute. So it's from a hill to the wood. What would you suggest for getting engineers to care about securing our dependencies? I feel like because no one reads the code, etc, they will only care when something already goes wrong.

No, it's a really tough problem. I mean, it's really difficult because, you know, engineers are already there's so much to do. There's always technical debt to fix. There's so much of a backlog and we're just trying to ship features and get our jobs done. And so it's add another thing onto the plate of developers is asking a lot.

I think one argument I would make to those developers to convince them to care is that, you know, ultimately we're craftsmen and we have to be, I guess, craftspeople. We really have to care about like the work that we're creating. And we should have pride in the software that we create and that we ship to production. And part of that is really making sure that the code that we ship behaves as intended and doesn't compromise our user data or compromise our users in any way. And so, it's really part of the responsibility of being an engineer. And with the right tools, and I'm biased but I think Sockett's trying to do a good job here, you can make it not so difficult and so onerous on the developer and make it something that's kind of fun to do as part of the development process.

Yeah. Well, actually, security, if you come to think of it, it should be after maybe accessibility. No, maybe even before accessibility. It's the most important thing. It's more important than your fancy command line settings. It's more important than your 60 FPS animations. It's the most important thing. Yeah, that's also an answer, I think.

Well, we are out of time for Q&A, but Feroz is going to be in a speaker room on spatial chat. So, you can click the link in the timeline below. Feroz, thanks a lot for scaring us and entertaining us. It's been a pleasure having you. Yeah, thanks Mateen. I appreciate the good questions and it's been an honor to be here. So, thanks a lot. Appreciate it. All right, bye-bye.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.
JSNation 2023JSNation 2023
30 min
The State of Passwordless Auth on the Web
Can we get rid of passwords yet? They make for a poor user experience and users are notoriously bad with them. The advent of WebAuthn has brought a passwordless world closer, but where do we really stand?
In this talk we'll explore the current user experience of WebAuthn and the requirements a user has to fulfill for them to authenticate without a password. We'll also explore the fallbacks and safeguards we can use to make the password experience better and more secure. By the end of the session you'll have a vision for how authentication could look in the future and a blueprint for how to build the best auth experience today.
JSNation Live 2021JSNation Live 2021
19 min
Multithreaded Logging with Pino
Top Content
Almost every developer thinks that adding one more log line would not decrease the performance of their server... until logging becomes the biggest bottleneck for their systems! We created one of the fastest JSON loggers for Node.js: pino. One of our key decisions was to remove all "transport" to another process (or infrastructure): it reduced both CPU and memory consumption, removing any bottleneck from logging. However, this created friction and lowered the developer experience of using Pino and in-process transports is the most asked feature our user.In the upcoming version 7, we will solve this problem and increase throughput at the same time: we are introducing pino.transport() to start a worker thread that you can use to transfer your logs safely to other destinations, without sacrificing neither performance nor the developer experience.

Workshops on related topic

Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
React Summit 2023React Summit 2023
56 min
0 to Auth in an hour with ReactJS
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool. There are multiple alternatives that are much better than passwords to identify and authenticate your users - including SSO, SAML, OAuth, Magic Links, One-Time Passwords, and Authenticator Apps.
While addressing security aspects and avoiding common pitfalls, we will enhance a full-stack JS application (Node.js backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session securely for subsequent client requests, validating / refreshing sessions- Basic Authorization - extracting and validating claims from the session token JWT and handling authorization in backend flows
At the end of the workshop, we will also touch other approaches of authentication implementation with Descope - using frontend or backend SDKs.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
WorkshopFree
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
Workshop
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible.
All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL.
In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours.
If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.