 Hi everyone, thanks for joining me. I'm going to present an open source tool that flags malicious and other risky open source dependencies in your software supply chain. So hang tight. I'm Ashish. I hold PhD in computer science from John Latek. I work at Osvid as a cyber security researcher and we are developing tools to mitigate open source supply chain attacks. Today open source software is another de facto standard way of building digital apps and services. Modern open source software is actually distributed as packages on package managers. Examples of popular package managers include NPM, PIPI, MVGNs. For example, PIPI hosts over 300,000 Python packages and receive millions of data downloads. However, bad actors can carry out supply chain attacks by publishing a malicious package and propagating malware in these package managers. This is evident by several recent incidents. According to a recent study, software supply chain attacks have actually tripled in 2021 and these attacks have been carried out on all ecosystems NPM, PIPI, MVGNs, no ecosystem has been spared. So the question is how do you defend against these attacks? Well, security is a shared responsibility and we must all do our part. For example, developers and package managers can adopt two factor authentication to protect against account hijacking. Here at open source summit we talked about names, coding, we talked about exciting packages and comrades and espons. Unfortunately, these measures fall short. For example, this diagram is taken from Salsa, a popular software supply chain security framework from Google. And as you can see, an attacker can target your software developer workflow at various steps. And while it can protect against other threats, it cannot protect you against compromised packages. For example, typosquadding. typosquadding is an attack where an attacker would deliberately publish a package and name it after a popular package in the hope that OKLS or an inexperienced developer would type the wrong name and that's how they would install malware. Another example would be a disk frontal maintainer. We recently saw this in case of a testware NPM package. Therefore, we must analyze package code and make it before using it. However, this is easier said than done. Manual vetting can be infeasible because a package can have hundreds of dependencies if you direct it transitive. Which is why we have developed a tool called package. It can semi automate your package vetting. Specifically, it looks for risky code and meta data attributes that make a package vulnerable to supply chain attacks. It carries out static analysis, dynamic analysis, as well as meta data analysis to look for these risky attributes. We have derived a set of risky attributes by studying 650 malicious packages that have been discovered in the past by the community. And we started as an academic research at Georgia Tech. The tool actually provides actionable insights into these activities. For example, we check if the package is old or abandoned. An old or abandoned package can be taken over by an attacker. Is the author email valid for two factor authentication? We check if the package reads files or sends data over the network. We also check if the source repo for packages is publicly available and correct. We have actually built a command line tool as well as CICD plugins for developers to use packages easily. And finally, package can be customized to your threat model to reduce alert fatigue. If you don't want package to alert you on lack of a public source repo, then it won't. You need to simply edit a file and comment that on the top. So let's see package in action. Specifically, let's audit a package called Browseify from NPM and trace the installation as well. So there's a lot going on here. So let's unpack slowly. So first thing that it does is it's going to fetch the Browseify package from NPM using NPMJS API and it found the latest version 17.0.0. Then it will check the package description and it found something. So it's going to display that. Then it's going to check for the release history and it found hundreds of versions, which is good. So you know that the package has been under development for a while and they've been stable releases. Then it's going to check the version. And here you can see the version actually 702 days old. So this could be a problem for you if you cannot accept packages that are that old, then it will alert you. Then it will check for release time gap, which is when was this version released since the prior release? And you can see that it's there been a gap of 68 days, which is good. This is to check if there was an old package and now it's been taken over by an attacker and there's a certain drastic development activity after a long time. Then it's going to check for the author and author email. In this case, the author email domain has been expired. So it could potentially be taken over by an attacker. So this is a risk. Finally, it will check other attributes, attributes such as the home page. And then it will jump to provenance, which is looking for public availability of source code repo. And in this case, it found one on GitHub and with over 14,000 stars and over 1200 folks. And you can see this repo is original, it's not forked. So which is good. And then you can look at the repo description and compare the package description. So browser side require the node way and the repo says the same thing. Browser side requires the node JS way. So you can know that this is a correct repo. Finally, there have been a number of comments and contribution, which is good. No CVs were found. CV information is actually fetched by querying OSV database maintained by Google. Then it will check for number of dependencies. In this case, if it's more than 30, you can change just the threshold. Finally, it's going to download the package. In this case, it's just 163 kb. And it'll analyze the package using static analysis. And it found the three permissions are needed. It will decode some code on the fly. And it requires code generation. So it will generate new code. And it will also access your file. So if these pose a risk to you, then package tool is going to alert you. It also checked for number of files and functions. So that way you know that there are no native extensions, no executables. And finally, it'll install the package and trace code. And it found five process 1.3.0 files and 22 network system calls. That means it's going to access file. It's going to perform network operations and also spawn processes. So if these are risks to you, you can you can take a deeper look. The complete report has been generated here. And overall, the package may be undesirable for you. So it's for you to take a look at these risks identified by the tool. So it has narrowed down from manual vetting to a couple of code lenses. Hopefully. Let's look at the CI CD example. So we do have a GitHub Action plugin that will detect weak links in your supply chain. This is an example. If you include the action, it's available on GitHub Marketplace. It will generate a security scan report for you. In this case, it was created for workflow run 21 on this commit and 15 issues are found with dependency, and then you can click for details. Like I said, you can customize package according to your threat model by editing package.yaml. In this example, you can see if you don't care about old and or abandoned packages, you can simply disable this, right once enabled. And you can customize to your threat model. We actually use the package to perform continuous vetting of high pi packages over 330,000 packages have been, have been analyzed and we found over 70 malicious packages and they've been reported. Some of the recent findings include this. And you can go to this website, package.dev, which is our website in slash malware to look at details. That's it. But thank you for attending the talk. Package source code is hosted on GitHub and we are accepting code contributions. Like I said, there are millions of pre-voted packages and security reports available for free at package.dev. And it's powered by Oslate. You could send your questions comment at oslate.com. Thanks.