 Thank you everyone. I'm presenting a open-source tool on sandboxing for enabling safe installation of untrusted open-source packages. I'm Ashish. I hold a PhD in cybersecurity from Georgia Tech, and now I work at Oslate, and we're building tools to mitigate open-source supply chain attacks. So what are these attacks? So in the last couple of years, we have seen bad actors publish malicious packages on popular package managers such as PiPi, RubyGems, and NPM, and these attacks have been increasing every year. So how do we defend against such attacks? So security is a shared responsibility, and we must all do our part. And there are multiple measures that I think we have talked about. For example, enabling two-factor authentication to stop account hijacking attempts. Namely, name scoping to stop dependency confusion attacks, and we've talked about code signing provenance. However, these measures fall short. For example, our discriminant maintainers, like we saw, a recent protest wear attack. They can abuse their own package. So they can still propagate malware. So this figure is from Salsa, a supply chain security framework from Google, and it says that Salsa framework cannot protect against compromised packages. So we need additional security measures, or we must thoroughly analyze the code that we are using, especially if it's untrusted third-party. However, this is easier said than done, because every package can have hundreds of thousands of transitive dependencies, and reviewing everything manually is just invisible. So there are open-source tools like package that can semi-automate this, to some extent. It can look for several risky attributes, such as if the dependency is old or vulnerable, number of dependencies, any risky APIs. For example, is the package trying to access your file system, your keys, or trying to talk to a server that's remote? If the package repo is available and the code matches with the repo or not. However, a sophisticated malware can still find a way. For example, there was a recent academic study that said 99% of malicious NPM packages that were found at least used one pre-installed hook. What that means is that a malicious package can behave differently in different environments, different operating systems. A different CICD environment can behave differently in production, can trigger at a later time, and can hide itself in a bit analysis. So that's why we must apply security in layers. So an additional layer is sandboxing layer, and this can enable a safe installation. At least we can sandbox the install step of dependencies. So we have built this tool called package sandbox. It's open-source hosted on GitHub under oscillating, and it can basically detect and stop any malicious activities before it can happen. And it's fully configurable. It can take custom firewall rules. For example, you can specify that package installation should only go to rubygems.com or npsds.org. You can specify what file system directories should be touched. So for example, if you want to prevent SolarWinds like attack where the code was overwritten, you can specify that do not write current directory. It can also monitor processes that are being created. For example, if a package is trying to spawn a pseudo shell, you can be detected and blocked. So let's see the sandbox in action. So in this case, what we are doing is we are trying to sandbox installation of a rubygem called overcommit, and it's the same command. It's just you need to add package sandbox before the actual installation command. And what it's going to do is it will do the same installation steps. It will get the package star ball and it will install. But at the end of it, it's going to provide you with data on what the package installation step did. So what URLs were contacted, what servers were contacted. And it will block anything that you have not listed. You have not allowed in your custom firewall rule. And it will also give you a summary of files and changes. So what files and some changes were made. And it will allow you to either commit or discard these changes. If you discard the package will not be installed. And it can also fake network requests. So the package installation could still succeed and not cause any actual outbound requests. So the question is why not containers or VMs? Well, they are built for different purpose. So for example, they have this host versus guest notion. So if you install a package in a container or a VM, you're installing in guest, and then you need to copy it back to host. Also for compatibility, the host file system and the guest file system must exactly be the same. Otherwise, it will cause incompatibilities. For example, native packages or packages, Python packages that have wheels. And these tools also require super user privileges. That means you're increasing the attack surface. And in your CIC environment, you would need Docker in Docker or nested VMs to enable this. So package sandbox tool fills the gap. It intercepts all system call requests and it'll rewrite the argument at runtime so that the file system changes are layered on top of the host file system. So that means package installation step gets exact replica of where you want the package to be installed finally. And at the same time, it'll layer those changes. So it's copy on right. And no root privileges are required. It uses ptrace. So you can enable harden CIC pipeline with package. So you have to get a GitHub action. It can also audit as well as sandbox the installation process. So it'll point you end of it, literally, you know, comment on your PR and point if there's any risky packages or dependencies. For example, in this case, you know, we found a vulnerable one and a one that needs review because it communicates with Excel network. Perhaps it's supposed to. So but it just says that you need to review the code. So it will reduce thorough manual wetting to a couple of code glances. That's it. Thank you so much. And the package source code is hosted on GitHub. Love any feedback? Thank you. So we are tracing this process, installation process and all children processes that are spawned as part of this parent installation step. We intercept every system call request. So every file system request, every network request is intercepted. If you build with a container, I haven't tried. I think it should work, but I haven't tried. But I think the support can be added. If you're asking if it can log all system call requests so that you can review and is that am I understanding correctly? Yes. So you can have your allow list in your firewall rules and it will only allow those requests. And pretty much you can add some sort of a destination to that. Thank you so much.