 Hi, this is your host Apil Bhatia and welcome to another episode of Tifa. Let's talk. And today we have with us Veras Mukherjee, CEO of Socket. Veras, it's great to have you on the show. Yeah, thank you for having me. Appreciate it. Yeah, we were like kind of planning to meet at Open Source Summit and sit down and talk, but that did not work out. But I'm happy that we are able to do it remotely. And there are so many things to talk about. The reason why I was excited to talk to you was also we never covered this company before Socket before. So I wanted to understand the story, what is your focus area, and you know, how oldest. So just give us the kind of story, original story of the company. What do you folks do? Why was the company created? What problem you guys are trying to solve here? I was an open source maintainer for most of the last 10 years in the JavaScript community primarily. So I've, you know, one of those people that wrote all those NPM packages that are, you know, in lots of our dependency trees today. And, you know, I had a great experience being part of that community and learning how open source works from the inside. And one of the things that I learned during my time writing these packages is how wide reaching our dependency trees are. So, you know, for example, when you start a new application, it's common to have thousands of dependencies right off the bat. Right. So this is a huge change in the way that we do open source and the way that we build application really. And so, you know, I had an insight during that time, which was that this just creates a lot of a risk for us in terms of our supply chains and the trust that we need to place in all the different individuals that make our open source software. And, you know, this sort of new way we open source and application design is leading to more supply chain attacks. And so that's the insight for Socket came from because Socket is a tool, security tool designed to help teams that are open source software and catch not just capabilities, but actually malware and other types of supply chain risk in their dependencies. When we look at software supply chain attacks or software supply chain security, talk a bit about how has open source or the adoption of open source either made it easier for organizations to keep a track of their supply chain, because when it comes when it comes to open source proprietary code, you know, of course model is different. It's only one source here. We are not looking at different, you know, packages coming from different projects or different companies and then there are different libraries and then there are different dependencies. Even if you know the funny thing is even if you ask, you know, I remember a couple of years ago, if you go to events, go to booth, hey, you know, we have this nice container, you can just spin it up. But they have no clue, you know, all the source that is there in a container hard links are there soft links are there. So so talk a bit about when it comes to security software supply chain security, how has open source either made it easier or more challenging to keep a track on it. Yeah, I know. I mean, you're totally right. Like I'm definitely nothing I'm saying is designed to be a negative thing about open source. Like I said, I love open source and I was a creator of open source for for many, many years. I think my npm packages have something like 500 million downloads a month. So I love open source. I mean, it's amazingly powerful, the way that we can collaborate without even needing to really, you know, know the people who are using our code. You know, that's that's the power of it for sure. The risk really comes in when you look at the just the sizes of our supply chains. And this is less to do with open source specifically and more to do with the way that of modern programming communities work. So if you look at the JavaScript community, the Rust community, these newer programming language communities have a tendency to create really tiny packages, small package that do one thing well. And what that actually leads to is our dependency trees having so many dependencies in them that it becomes kind of hard to understand what's happening. The average dependency in npm has 79 additional dependencies that that dependency depends on. So, you know, even in one dependency, you end up with like 80 dependencies in your in your application. So it's like, it's, it's to do with open source and more to do with again, just sort of the way we're splitting up the code into different dependencies and the way that it's just a little bit hard for teams and developers to keep track of all this. So, but to answer your question kind of more directly, like, I definitely think, you know, having having our software dependencies be open source is is way more preferable than having them be proprietary. So absolutely, you know, getting a proprietary blob from somebody that doesn't tell you what it's going to do and you have no idea where the constituent parts came from is definitely way worse. So open source, you know, we have the ability to build nice software builds of materials for our for our opponents and put together, you know, a list of where our software is coming from. It's just hard for teams to do that today. That's part of what socket is trying to address. If you look at this adoption of open source, where almost every company is relying on open source code base, how much understanding do you see that they have about supply chain security or you feel when you talk to them. They're like clueless about it and they have no idea and, you know, and you have to go out and educate them that, hey, you know, just like automobile industry, they should have a very clear visibility of their supply chain. What are you seeing in the market? I think teams are aware that they should be doing something about open source supply chain security. But they don't really know what to do. And I think I've seen a little bit of confusion around, you know, what would actually help with the problem. So one common mistake I see is people think that scanning for vulnerabilities, CVEs is enough. And if you do that, then you're safe against these types of attacks and risks. And unfortunately, this just isn't the case. Market right now, it's flooded with a lot of vulnerability scan tools and tools which focus on CVEs. And these tools really look up the packages that you're using to see any vulnerabilities have been reported in these packages. But unfortunately, this process is very slow and it's too reactive to stop an active supply chain attack. What I mean specifically about that is a packet that gets compromised by a bad actor and has bad code inserted into it. That will go out and people will start to install that. Companies will start to install that a lot of times right away when a developer goes to install that dependency or when a build tooling automatically upgrades the dependency or, you know, when this makes its way into people's products. And then something in the future, the community will learn that this package has compromised in some way. And it's too late at the point to go and protect all the apps that had used that dependency. And so really what we're seeing today is the leading organizations are expanding the scope of what open security means to go beyond just vulnerabilities and to include a holistic defense against supply chain attacks. And so, you know, again, supply chain attacks are pretty different than vulnerabilities. They involve an intentional introduction of a problem into a package and it's done by an attacker with malicious intent. And unlike vulnerabilities, you don't have time to mitigate them. Vulnerability is often you can wait days, weeks, months sometimes to fix the vulnerability and nobody finds the vulnerability. No, I'm not saying that's a good idea, but, you know, a vulnerability is like being your window open to your house. Somebody might use that vulnerability to get into your house, but probably not, right? You go for a very long time without anybody exploiting vulnerability. And also with vulnerabilities, you have a lot of them which are just very low impact and might not even be exploitable in production. And so anyway, what I'm getting at is sort of we're seeing this sort of shift from just looking at this as vulnerabilities to a more holistic picture. But the problem is that even if a team wants to do the right thing and take a more holistic picture of their supply chain risk, it's really hard to do the right thing. Like it's actually just there's no tooling to there hasn't been until now, like until pocket really there hasn't been tooling that makes it easy to help developers make better decisions about what dependency to use. There hasn't been tooling to surface these risks. And so what we see is like most teams just sort of put their head in the sand or just say, you know, I crossed my fingers and I hope that we're not affected by this. And what's really kind of fascinating about it in my opinion is that in the end what you end up seeing is actually a lot of teams scrutinize their colleagues code more than they scrutinize open source code that was written by people, you know, random people on the internet. You see this when code review processes are implemented and, you know, you have to review developers code before it makes it into production or make it before it makes it into the app. And when it comes to dependencies, nobody reviews them. So we just usually see, oh, okay, this tendency was added. And, you know, GitHub and all the popular tooling out there doesn't really show you what is the code in that dependency? You know, what is that code going to do? What other dependencies does that dependency depend on, right? And so most teams just sort of show and say, okay, yeah, a dependency was added and they don't even review code at all. They don't even do the most cursory basic checks of that code to make sure that it looks reasonable. And so it's just, and again, I'm not trying to blame any teams actually just a really hard problem. And so, you know, for the most part, people are really relieved and really happy when they see, oh, wow, socket makes this really easy. This is wonderful. So that's what we've been seeing is we've had to educate a lot of people on the difference between vulnerabilities and supply chain attacks. And we've given them these powerful tools that actually help them do that assessment in a fast way that doesn't really add more burden or more noise to the developer. Talk a bit about how is socket helping organizations where security doesn't look like, you know, other intimidating things that they have to do. Plus, you know, as you're also touching upon that, we need to have a holistic view to your security. Otherwise, we'll end up using 50 different solutions for security and we are also sure that they should work together. So talk about socket approach to make it easier for organizations to focus on security. So the first thing we do is we're extremely developer friendly. So the truth about most security software, I have to say, it's typically sold to executives. So it tends to suck to actually use it. In the best case, the software gets purchased and it sits around on shelf, bothering and protecting nobody. But in the worst case, it gets deployed and then developers find it extremely frustrating and it prevents them from getting things done. So I would start by saying so sockets designed from the beginning to be developer friendly. That's something that our team cares a lot about because we are much more coming from the developer side and the security side. So that's the first. The second thing is we're built directly into the GitHub workflow, the VS code editor, the CLI. We build socket directly into all the places that the developers spend their time. So this means that it doesn't require them to go use another tool, learn another process. Socket brings the information that's most useful to the developer directly to them and then makes it digestible and easy to understand. So for example, a developer might use a new dependency and socket will tell them, hey, just so you know, that dependency that you installed, it has no updates in five years. So that's good to know before you start building a feature and spend weeks using this open source dependency that's abandoned. That's a very simple example, but good to know that and good to know that proactively, not after the fact. Another example, say the developer is installing a dependency on their command line. They type npm install foo and they go to install the foo dependency, but they make a typo. They install actually, they typo it and they install a different package. Now, this is very dangerous actually because the package manager actually allows the package to run code immediately upon installation if it wants to. And so making a single letter typo can actually lead to their developer laptop getting completely compromised by malware. And so this is an example where socket will come in and actually it will stop the installation and just tell them, hey, just so you know, the dependency you installed, it's one letter off from a dependency that's much, much more popular. It'll tell them it's 10,000 times more popular and it's one letter different. Are you sure you intended to install this package? So again, you can see it doesn't it doesn't interfere with their workflow unless there's a good reason to tell them that information and they're very happy to get that information. And then, you know, that's that's the approach we take throughout the whole product. And I'll just mention one other example to one common thing we see with supply and attacks is when a legitimate package or dependency is taken over by an attacker. One of the first things they like to do is to add, you know, additional code that steals information or, you know, doesn't somewhere or adds a cryptocurrency minor to steal, you know, system resources and mine cryptocurrency. So there's these typical kind of pattern we see when when a package is compromised, what is the attacker trying to do? Well, they're usually trying to add some of their own functionality into that into that project and hope that nobody notices for a little while. Right. And what socket can do is when a developer goes to update their dependencies, which they have to do obviously from time to time, and they go to make an update. We will highlight for them when the behavior of the package has changed in a significant way. So, for example, if they've been using a package for the last two years, and it never needed to make any network requests, it never needed to talk to the Internet, right. Now suddenly they're going to update and they're, it's a patch version, a very small update, right, should be for fixing bugs, making very small tweaks. And we see, oh, wait a minute, you know, it's sending to the network now. That's a very significant change in behavior that we want to highlight. So that's, you know, it's again, it's a very, it's a very useful piece of information. Do you have the developer that lets them say, wait a minute, why, why is my dependency being this way? And we don't block them. We don't stop them from doing their work. We just let them know. We let them know, you know, this is what we observed. And now at least they have the information to sort of, if it does seem out of the ordinary for them to pull the thread and to figure out what's going on here. So it's very powerful. And these are just some of the things we do. But, you know, we think of it like the way on a smartphone app, if the app wants to use your microphone or use your camera, right, the developer doesn't just get to do that without asking for your permission. It doesn't just get us to release an update that that's all your information or start spying on you. But with open source, the way it works today, if a dependency wants to start doing a lot of different behaviors in a new version, there's no warning to the developer at all. There's no warning to the team to see this. So we see socket as bringing that type of of a permit model to, to the open source experience and highlighting those changes in behavior. So there's, you know, that's, that's kind of the thing. I don't know if that kind of I covered a few different parts of the product, but we see it as basically being very developer friendly, very developer first, and trying to help them do the job better. Can you talk about some of the use cases? Of course, you may or may not be able to name companies where you can say, hey, these are kind of organizations which are leveraging socket technologies. Today, socket is used by over 3000 organizations and over 150,000 code repositories and we're affecting all of those organizations from security threats originating in open source. So even though we're a relatively new tool on the scene, you know, we haven't been around for decades, like some of these legacy incumbents, we have seen like a very fast adoption of socket. And I would say I associate, I attribute that to really a couple reasons. One is that the tool is super easy to install. I mean, literally two clicks, right? So you go on to get a marketplace, you search socket, it's two clicks to get installed and protect all of your repositories. So the model compared to other security tools is much simpler to deploy. And then in terms of the need for the problem, like I mentioned before, companies are really starting to recognize that vulnerabilities are not the whole open source security solution, right? And as more teams recognize this, especially with these prominent supply chain attacks in the news that have happened in the last few years, teams are looking for, you know, a solution. And when they see socket, they see the approach, recognize the benefit of the approach and so they install it. So that's what we're seeing. I think we're seeing very fast adoption of tool. We also have a very generous free plan, to be honest. I mean, like I mentioned, we come open source, so we wanted to make this tool very, very accessible to people. And so you can get pretty much the whole product for free in the open source version, the free version. So it's really accessible to teams in a way that is really refreshing. How do you see, of course, what we have learned from COVID is don't predict, you know, a lot of times in the future, we don't know how things will look like. But where do you see security is moving and how do you see socket is evolving or what kind of things you folks are working on for the coming months or years? Our focus right now is we want to grow and expand to support more ecosystems, more languages, more different use cases. That's a very concrete direction we're going. But kind of at a picture level, we're seeing these executive orders from the White House that have come out around supply chain security. I'm sure you're familiar. There is mandates now to provide S-bombs to software that's sold to the government. So S-bombs, you know, software bill of materials. And this is really shaking up the industry in a way that is very, I think, very potted for too long. Companies have been able to sell software to people that contains, you know, really old dependencies, sometimes five, ten years old, completely unpatched. And so I'm glad to see that, you know, the government is playing a decent role, you know, a pretty useful role in this way to encourage the industry to do the right thing. So I think we'll see increased adoption of S-bombs. But I think no one solution is going to solve everything. So even S-bombs, right, I mean, it's great to know what open source software you're using. That's wonderful. But real question is what do you do with that information? Like, how do you make that useful? And S-bombs are just the beginning, the first step in the process. We need to combine that information with more useful data about, okay, what are the dependencies doing? What are the risks of each dependency? What is the behavior of each dependency? What is the maintenance status? Who is the creator of each dependency? That type of thing, not just have a big list that nobody looks at. So I think it's a very good direction. It's a good start, but we need to keep going in that direction and we'll be much better off if we do. Hirosh, thank you so much for taking time out today and talking about socket, the whole evolution of software, supply, and security. Thanks for all those insights, and I would love to chat with you again. Thank you. Thanks so much for having me. This was really fun.