 Hi, this is your host Satil Bhartiya and today we have with us Peter Morgan president and co-founder of Phylum Peter. It's great to have you on the show Thanks so much for having me. First of all, you know, this is the first time we're talking to each other So tell us a bit about the company. You're also co-founder. So what do you folks do? What problem are you trying to solve? Sure. So we started Phylum right when the pandemic hit Kind of coincidentally because we've been tracking the problem of supply chain security for quite a while And we noticed that there was a pretty significant gap and what the existing tooling is it was able was looking for and Where attackers are going? One of the unique parts of our company is that the Great majority of the people we have have spent a lot of time doing offensive security research All the way up to all the co-founders. So when we looked at the supply chain security problem we kind of see it from the lens of how an attacker is going to go after it and Looking at it in that regard Showed the need for some changes in the way thinking is done some changes in the way products are built And how defense needs to adapt to where what attackers are doing over the last couple of years We've seen a lot more evidence of that. Unfortunately, excellent. Thanks for explaining about that and because of pandemic a lot of other things also happen Companies kind of accelerated their district transformation Cloud to journey also adoption of open sources also increasing which may also kind of Lead to why we are talking a lot about software supply chain I also want to understand from you is that why are we talking a lot of our software supply chain? Because if you look at the old model of delivery, it was one monolith coming from one source that company was responsible for everything else when today's word We are using a lot of open source library different open source frameworks event components from different places It's more of like when you assemble a car Different parts are coming from different windows or if you're cooking a food different ingredients So so talk about the why we should care or talk about software supply chain That's a great point in the analogy about how cars constructed is really spot on You can make the argument that software isn't really as written as much as it used to be It is a lot more assembled and there's a lot of great things about that like the concept of open source is fantastic in that You can leverage libraries from you know really strong developers that have worked really hard on that on a different problem And you can build on top of those very rapidly and when you look at it from kind of the commercial sector My perspective is I see that companies have kind of gotten used to the ability to develop things so much faster on top of these Open source libraries, which is great You know the fact that anybody can contribute and come up with a better idea and that idea will often win If it's you know skiffly better is a great thing unfortunately the world is not so You know altruistic in every way and it opens a huge attack surface for bad actors to to do things here, right? And when you look at how much software development has changed just in the last five years things like reproducible builds and CICD and kind of all the hotness right now and everyone's implementing them or on the way to doing so and Fundamentally, there's so much open source being used now in automation you put those two pieces together and It means it just means we're using untrusted code in automation and that opens up an attack surface that is fundamentally different from Things just like software vulnerabilities. I mean those are still an issue But there's a lot more that goes into defending a supply chain But it first takes that understanding that we're reusing untrusted code in automation And we have to defend against that kind of concept. I was thinking there are so many things that we can talk about First of all with open source as you mentioned that it's more about assembly than writing the code that I mean I could be totally wrong about it But one of the advantages of open source is also that if you do realize there is a weak link or there is a bug You actually have the capability to fix it yourself depending on how much capability you have You don't have to actually wait for the big vendor to push those updates And then you can make the changes and send it back to the supply chain So there are so many and as you also said the velocity is also higher companies can move faster But not everybody can afford to have all the developers Just tracking how many code pieces of code they're using is also challenge. So talk about how are you kind of helping those folks in addressing If not all at least some of those problems. So what are the areas that you help folks so they can improve their security posture? Ideally everyone would be able to like identify these issues fix them and patch them upstream the reality that we see from customers Under the weight of trying to defend their software is that's just not realistic We have to find a better model and this is a bigger question than what filing is addressing right now We have to find a better model of compensating open source developers You know the things about log4j and kind of highlighting something that is so widely used But those developers aren't paid for that kind of activity, of course You can you can look at that and apply it to everywhere in open source almost, you know equally There's a handful of organizations that really fund Their own developers to go work on open source But these are some of the largest software development companies in the world and it's not realistic for everyone so what filing is doing is first taking the right perspective I think into Understanding what the issues are where the attack surface comes from and being able to identify when these open source packages we rely on kind of go off the rails or start turning in a direction where The risk the risk of using those changes dramatically for a company of course the next steps are how do we fix that and You know encourage those fixes to to win That is a that's a kind of another problem in entire entirely There's some things we can do and there's some things that just result in you have to switch using that from a using package a to package B Unfortunately, it goes that direction a simple example here is One of the heuristics we added to the platform Is just detecting when the author of a package the person that controls a package is using an email address from a custom domain And then email address is expired There's been some articles about this of the past couple months. It's a great idea There are tens of thousands of packages And some popular packages that are maintained by authors with email addresses that the domain is expired an Attacker that takes over one of those email domains effectively becomes the author and now controls that software So understanding that first is the first part of the problem. The second part is now. What do we do about it? In some cases you might want to just take over domain ownership. So before an attacker does You're gonna probably irritate some people by doing that in other cases You may just want to fork that package take the code out of it and then maintain ownership of that internally But the first part about this of course is really getting the awareness of the supply chain problem So we can start dealing with You know the ramifications of those things with the supply chain the challenges First of all the code starts with the code developer but most of the code today resides either on the personal repository or the repositories of GitHub repositories of the project page some of the project is now hosted by organization like Linux Foundation Then there are commercial vendors who are supplying those repackaging is as part of their own code And then you are your big SAS providers who are using them and then their end users So where is the bucket stop when it comes to supply chain? Who is responsible? That's a great question and to kind of highlight some of the some of the interesting parts of this The more you look at the supply chain and the different layers of it one of the things that kind of comes to mind is that There's no such thing as rules in this everything is a convention for instance If you want to host a package on npm or pi pi As an author you write your code and you post it on the package registry and then other developers can install it from using those that registry Some things you'll put into the registry are What is the license? Who who are the authors? These are freeform text fields that have no validation or requirement whatsoever So when you put in something something simple that doesn't seem as interesting in the security side as licenses The developer can write whatever they want in that text field Then there's a convention that it should link to some sort of open source Repository like github or get lab If you go look at github it can have another license definition if you then go look at the code in github That can be another license definition. There was nothing before that was kind of reconciling What is the actual license and that's just one part of this right? There's actually no convention that you have to link to a source code repository Or that if you do that the code matches what actually comes in the package so You know for security researchers and attackers those kind of gray areas of Convention not rule are you know the dream where you can start doing things Unexpectedly and we see that a lot and you know analyzing them that we analyze malware all day every day The systems the automated system actually detects hundreds and hundreds of pieces of new malware a month And as we dig into this it's those kind of convention areas that are not enforced by anything that attackers are leveraging to do bad things in the supply chain and When we kind of look at that and then think about the scale of how automation is really spreading this That's where the blast radius the impact of some of these attacks can be fundamentally disastrous No longer do you have to like go write experts for Chrome to pop into organizations? Which is very difficult Chrome is a fantastic security team You can attack a single developer on github that doesn't have any real defenses that doesn't know they're being attacked because they manage a package nine transit dependencies up and if you win there you affect thousands of organizations and tens of millions of people in the process so the The value to the attackers is so high and the defenses are relatively not existent for that This is a again why we put everything else down to come work on phylum. You folks the security folks You have to be right 101 percent time, but the bad actors. They have to be right only once So this is it not it's a constant battle It's also it's not a product. It's a process. You know, it's not you're like, hey, you did that You're secure. No, that's not so can you also talk about When you're talking about, you know, that's not chrome is safe secure, but you know one developer so can you talk about the cultural aspect of security as well where The thing is that bad actors the incentive should be high enough They put effort into that. Of course, there are a lot of state-sponsored attacks There the incentive is totally different. It's not monetary incentive so talk about the cultural aspect also so as to kind of Lower the incentive and increase the effort so much. That's not even worthwhile, right? It's um, You make a good point there in that if you think about um Kind of how the malware industry kind of the endpoint desktop malware industry really evolved We had av you know back in the 90s and virus definition files And I think a lot of people remember updating those if they're getting older like me, um Then things moved forward pretty pretty rapidly in the mid late 2000s 2020 times We're at cloud endpoint full emulation. We have you know Functionally data centers just emulating all the software to try to defend against endpoint malware. The goal there was never to stop all malware It can't be it's to make it difficult enough and the returns Not high enough to move attackers into other things. Unfortunately, that drove them into ransomware So we're kind of dealing with that problem right now But it's a very similar game when it comes to The supply chain because fundamentally again, we are executing code from strangers on the internet On our developer workstations as we install these packages and on the ci infrastructure that runs And if you actually analyze the malware that we identify Um, the target is not production infrastructure. They're not even trying to get there The goal is the developer workstations and extracting things from ci cd runners that are supposed to be running tests And integrations and so and so those sort of things To pull off that data so the attackers can keep going forward now Solving all malware is not a realistic realistic endpoint right now The idea is make this hard enough Where we can kind of keep the great things of open source and keep building products rapidly and improving things rapidly with open source But avoid the pitfalls that unfortunately come with letting Anyone just kind of write code and post it online and people reuse it, right? So it's a Little bit of a it's a challenge. No doubt, but it's an element that is never going to go away, right? There's humans. There's a lot of people Some people are going to want to try to do bad things. Maybe it's because they're just testing something out Maybe it's because they have bad intentions, but the you know, we have to kind of have a model of No longer trusting everything we get on the internet, right like we kind of We mostly convinced everyone to stop opening attachments in email from people. They don't know But we've kind of gone backwards in going back to just using anything that comes off of github.com and assuming it's going to be okay Peter, thank you so much for taking time out today and talk about not only the company phylum But also the larger problem area which comes in the software security chain This is this is a long, you know, as you rightly said process and you cannot just throw a lot of people at it So thanks for you know bringing solutions like, you know, these to help folks so they can continue to Help their users But I would love to have you back on the show because there are so many things to talk about especially in this area So thanks for your time today, but let's meet soon again. Thank you. Yeah, I'd love to. Thanks so much