Aaron Davis — LavaMoat — solving JavaScript software supply chain

0:00Chris RomeoAaron Davis is a founder, developer, and a lead security researcher at MetaMask, a popular Ethereum wallet. He introduces us to Lavamote, an approach to solving JavaScript software supply chain security for both Node and the browser. The Lavamote runtime prevents modifying JavaScript's primordials, limits access to the platform API, and prevents packages from corrupting other packages. We hope you enjoy this conversation with Aaron Davis. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term sustainable security culture amongst all their developers. Our approach is to provide security education that's conversational, quick, hands-on, and fun. We don't do lectures. Instead, we let the experts talk about what's important. Modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, building builder and breaker style that allow your developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo.

1:14Aaron DavisHey, welcome folks to another episode of the Application Security Podcast. This is Robert Hurlbut, Threat Modeling Architect, and I'm also joined here today by my co-host Chris Romeo.

1:41Robert HurlbutChris? Hey Robert, Chris Romeo, CEO of Security Journey, and, uh, definitely excited today to be talking about the world of software supply chain security, which seems like It's always in the news. There's always something happening in this space right now across the board. It does, it does. Quite often we, we see something about it.

2:00Aaron DavisAnd so with that in mind, our special guest today is Aaron Davis. I think you're coming in from Indonesia, is that correct? Yep, uh, digital nomad in Bali.

2:10Robert HurlbutWow, very cool. So, uh, for our listeners, what we usually do is, uh, we, we ask our guests, uh, their security origin story. So Aaron, tell us that. What is your security origin story?

2:22Aaron DavisYeah, so I was really interested in making games and also in programming education for young people. I wanted to combine these things and create kind of like a multi-user dungeon from the days of yore, where users can come together and sort of like create a game or create a space and do some programming in that space together. And so inevitably, that means you're running code from some untrusted party, and you have to find a way to sandbox that, get it to play nicely. And that was fairly early in my programming career, so I was still figuring out what I was doing. But that started me thinking about, you know, how could you safely run this code that you didn't trust? Even if you could, like, sandbox all the way down, if it just runs an infinite loop, that's a whole other problem.

3:11Robert HurlbutVery cool. And so Whenever you were trying to think through—

3:15Chris RomeoI've done a little bit of game development, it's been years ago, but I remember that also helped sort of spark some interest in security as well, and thinking about protecting different areas and, you know, verifying and so forth.

3:29Robert HurlbutBut out of that, what were some of the challenges in particular when you were writing some of those and thinking about security?

3:37Aaron DavisYeah, well, at that point, that was pretty early. And so I really didn't know what I was doing and didn't know what resources there were for sandboxing. And then I kind of transitioned into a more normal web development career and did a short time at Apple. And then I kept hearing about the Ethereum blockchain. It was really interesting to me, not from a financial perspective, but from this idea of sort of creating a virtual mainframe that a bunch of code that a bunch of different people publish can interact in some way. I couldn't quite imagine what it would be or how it would evolve, but the idea really grabbed me. So I started early with the Ethereum blockchain, and I'm most known for my work starting MetaMask, which is a very popular Ethereum wallet. And it's a mobile app now and also a browser extension. And both of those are made— they're JavaScript apps that are made from the JavaScript commons via the npm ecosystem. And that— and, you know, they're securing digital assets via private keys. And so that has a strong need for security, but especially in the browser context, like we have good security provided by the browser. But then you introduce the problem of supply chain attacks, and suddenly the world becomes a bit scarier. This place that you thought was safe on the inside of the walls of the browser, suddenly an attacker could be already inside. The call is coming from inside the house.

5:20Robert HurlbutYeah, I'm just chuckling as I'm kind of thinking through and listening to your history and thinking, you know, at least you started with 2 easy problems: sandboxing and protecting the world via crypto. Like, you know, A lot of people would have said, maybe we'll start with something simple like, you know, how could we make input validation better? You know, but you went big, so that's good. It's good to have that perspective on the world.

5:44Aaron DavisYeah, so now the goal is no less small. It's trying to solve software supply chain security for the whole JavaScript ecosystem and be backwards compatible as much as possible. So that's been a fun one. I've been working on that for a little over a year. And at first, I, you know, I tried doing some of these sandboxing things in, you know, trying to make games and stuff in JavaScript. And there were a few packages and libraries that were suggesting that they could do security. And so I played with them and really found that they could, that they had a good idea, but it really didn't work. You could find a hole, and once you found a hole, You know, there was no security provided, or they worked by limiting what you could run to some subset of JavaScript that was so small it wasn't really compatible with any of the code you wanted to run. So I kind of had given up on it being possible. You know, of course, if you're just— for each thing you want to run, you're just spinning up a new process or something like that. If you're running the server, you could do that. You can kind of do it in workers and stuff like this on the web platform, but then you're also at the risk of resource starvation or something like that. There's not ways— good ways of doing metering or something like this. So it becomes sort of an unsolvable problem. And a lot of those challenges are still there. But then, maybe 2 years ago, at the Decentralized Web Summit in San Francisco, I met some folks from the Agoric team. I met Dean Tribble, and he told me he had a system where he could do in-process, inside of your JavaScript that's already running, build a little container in there, and everything can still talk synchronously. And I didn't believe him. It was just, that didn't seem possible at all. I chased that idea so many times that I couldn't find it. And at some point after that, I think, what's commonly known as the Event Stream incident or the BitPay wallet hack happened. And so this was a Node module, a legitimate Node module called Eventstream that had been around for a long time, used in many, many applications. It was even in the Azure CLI. It was a dependency of that. So it was basically everywhere. And, but the author, Dominic Tarr, he didn't use it. And, you know, he gets nothing from maintaining it.

8:15Robert HurlbutRight.

8:17Aaron DavisAnd so someone's like, hey, I'll help you maintain it. He's like, great, I don't even use it anymore. So he added this new author, and a little bit later, this author deployed a targeted attack against this Bitcoin wallet. And so part of the problem is, once you get into a dependency, you can pretty much do anything. You just run wild. There's very little limitations. And so you have, you know, network access to do your infiltration. You have disk access or local storage or whatever it is on the platform you're on to take private keys. You can mutate what other classes do. JavaScript particularly is very mutable at runtime. You can change the behavior of all these different things. And so that wreaks some havoc.

9:06Robert HurlbutSo when you think about kind of the software supply chain in general, And so that's a great example you just shared kind of from the Event Stream incident. Event Stream incident, we would kind of bucketize or categorize that as JavaScript and Node. It's kind of where it fit in. When you think about this problem in general, it's definitely not just a JavaScript problem, right? This is an industry-wide problem for all libraries, all package management, all open source that's everywhere, right?

9:37Aaron DavisYeah, absolutely. I can comment on some of the specifics of JavaScript. I think JavaScript is a little more dangerous than some other languages just due to the nature of the way it works, but that's also my language of expertise. I'm sure if you found hackers for all the other languages, they could find clever ways of really taking over as much as possible. But basically, if you are able to run some code inside of an application, very few software paradigms that are in use today prevent you from doing very much. You're basically on the system, you have shell access. And so if, you know, in my context as a cryptocurrency wallet, much like this one that was hacked, it was terrifying to read something like this because it could happen to me as well. So that launched me on this journey of like, we have to solve supply chain security for the JavaScript ecosystem, and we have to do it now.

10:40Robert HurlbutSo when you think about the attacks then, so with the Eventstream incident, I think of that as a— and there was a malicious actor involved who drove that through. But then kind of the other side of the equation when you're thinking about software supply chain is just a known vulnerability in a package. So those are kind of the 2 categories that I tend to think of when I'm thinking software supply chain. Are there any other from your perspective? You know, when you're thinking about JavaScript and package management or anything, is there— are there other attacks that are, that are outside of those 2 categories, or are those 2 the categories that really describe or kind of define all supply chain attacks?

11:19Aaron DavisSo the 2 categories were, uh, like known vulnerabilities and targeted attacks?

11:23Robert HurlbutYeah, those are the 2. I tend to think of everything in those 2 buckets, but are there more buckets from your perspective as you're thinking about how you're trying to break JavaScript or attack from your perspective?

11:35Aaron DavisNo, that seems about right. And we're doing— I'd say the ecosystem does a pretty good job about the known vulnerabilities. Like, when your package manager installs things, it gives you a list of warnings and severities. And GitHub as well will blow up your notifications with new reports as So if there's like a new prototype pollution vulnerability detected in this package at this version range, it will, you know, GitHub will notify you, your package manager will notify you, and other companies like Snyk that, you know, have services like this and automated fixes. So we're doing well there, but the targeted attacks is what I'm particularly concerned about. There's, you know, precedent of similar organizations being attacked. And one thing, one thing that's hard with these dependency graphs is you import this utility, this utility, this utility, this utility, and so those are the ones that you're like really paying attention to, but all of those import things and import things and import things and import things. So you have that giant graph, but you're really mostly exposed to just the top layer.

12:47Robert HurlbutYeah, and you get all the other goodies that sneak in. I had 100 dependencies, and now, all of a sudden, there's 80,000 packages in my application. What happened? Let me just code review all of them, which nobody could ever do anytime.

12:59Aaron DavisYeah, that was part of the thing is after the event stream incident went on, there's a ton of conversation on Twitter, people saying, oh, you should never use dependencies. It's too dangerous. It seems like— I really don't like that argument because it's It's like the whole nice thing about technology is technology builds on technology, especially in the open source community. We're all sharing and making progress. But then the other side is, you should— the other camp was you should always audit all of your dependencies, always. And yeah, of course, that's a good idea. That's a good thing. But it's literally megabytes and megabytes of JavaScript, and you have to figure out how all of it fits together. And then you end up in a situation where, let's say, you have a loss-causing, potentially loss-causing bug in production, and you want to fix it, and it requires some cascading dependency updates. Are you going to hold that off while you audit these things? It's a tricky problem.

13:56Robert HurlbutYeah, I mean, that argument's made by somebody who's never developed an application before that says you should audit all of your dependencies. Well, you've never created a JavaScript Node-based application because, like, I'm not kidding, like, it's You could see an application where you have 100 dependencies that has 80,000 packages that are pulled into it. That's not— I'm not just making that up trying to be like— that could be a relatively normal use case. And so for somebody to say, yeah, you got to audit them all, it's just not realistic. There's got to be something else we can do to either build trust into the open source ecosystem, which we're probably a little further away from being able to do that, where we're saying, hey, how could we sign all these packages so that somebody is able to attest to the fact that, hey, a known good entity worked on this particular package and did it. That's a whole other category, but I think technology is going to be one of the ways that we approach this as well.

14:52Aaron DavisYeah, there is that sort of— there is the open, the software ecosystem and financial aspect. Azure, Microsoft, was relying on this dependency, among many other dependencies. But this maintainer was not compensated for any of that, which was all the more reason why he was just like, sure, you have it. I couldn't be bothered. I don't even use it anymore. So, yeah, what can we do besides not using dependencies, or how can we reduce the audit burden or something like this? And so, I started Thinking about POLA, the principle of least authority, and so if we can limit what we give those dependencies, then they're less dangerous, and it's easier to audit them, and it's easier to prioritize our audits through the dependency graph and find where exfiltration is going to happen through the network access. We can look for the one place where there's network instead of giving it to everything.

16:01Robert HurlbutYeah, and so the— I mean, you were, you know, one of the things that kind of brought you to our attention for this conversation was this, this Lava Mode thing. And so, um, first of all, great marketing name, Lava Mode. I kind of know what it, what it does, but tell, tell us a little bit about what Lava Mode is and what it actually does.

16:20Aaron DavisYeah, so the intention, uh, of Lava Mode is to take your, um, npm-based Node or browser application. And without really changing how your code works at all, you run it in a way that applies a little sandbox around each package or module based on a policy file. And we also have a tool that automatically generates these policy files. based on a static analysis of the code. Looks like it's using this thing, is using that thing, so okay, we'll give that one network access. And afterwards, you can, you know, just obviously audit that policy file, look at how the packages connect. And then there's a data visualization tool as well, so you can see, well, that one's particularly dangerous, it has network access. And you can see how all the modules connect, so you can see how this one could get network access to through that one. So if you imagine an attacker got access to one of those modules, how is it going to be able to steal the information and then get it out or whatever your attack, whatever attack vector you're imagining? So that's all based on that SES container that I learned about from Agoric. So what they came up with was, so they're working on a JavaScript standard, but it It works today, you know, like they have a shim that you can run in JavaScript and it's basically a special eval function that just constrains what the code you've put into eval, what it has access to. And it uses a with statement and a proxy in order to basically have a hook to whitelist what's trying to be accessed. So if you're going and say like, hey, give me the network, They'll say, hey, the network is not in the policy file, so throw an error and explode. And there's some other tricks and things that need to be tied down and sawed off in order to not be dangerous and make it so you can't escape out of that container. But once you have that container, you can just apply it to all the modules and then have this runtime block act. make sure packages can only talk to other packages that they're allowed to.

18:42Robert HurlbutSo if I was to— I'm trying to kind of conceptualize this in my mind and put it in a category. And so it can sometimes be dangerous to try to put new technologies or new concepts into old categories, but is this— if— could I summarize this as saying it's like applying containers inside my JavaScript application? Could I say it's like using a microVM, or am I going too far with that statement? Is it a firewall for JavaScript code? What previous concept that we have floating in our brains can we attach this to? Is it most like? It's probably not exactly like anything that I described, but which one is it closest to to help us conceptualize?

19:27Aaron DavisYeah, I think containerization is a really great way of thinking about it. Just because, like, on one machine, you can have many containers talking to each other. And in the same way, inside your application, you have this further, finer granularity of container communicating. So, you're just bringing containerization down to different parts of your application, single-threaded application.

19:55Robert HurlbutAnd you call these SES containers. So, SES is Secure ECMA Scripting.

20:02Aaron DavisYeah, ECMAScript being another name for JavaScript. So SES. And so that is the project and standard being championed by Agoric. So if all goes smoothly, this will be a— these containers will be first-class citizens in JavaScript.

20:22Robert HurlbutDoes that mean LavaMote might work itself out of a job if this becomes a standard? Like the browser writers would implement this capability natively in the browser?

20:34Aaron DavisYeah, that would be fantastic. So this is an open source project and not a business venture. So again, it has the same problem of like, well, who's going to maintain this? If this all disappeared into JavaScript spec and Node.js features, I would be very, very happy. But in the meantime, it works now with the code you already have. So if you have, you know, some Node server, for example, you have some, you know, Express or whatever you might be using, the first thing you can do is you can install LavaMoat or just use npx if you want it to be automatically installed, run it and have it generate a policy file for you. And then you run it again without the generate policy file flag, and it will use that policy file and run your app. And unless you're doing something really strange in there, it should work just as simple as that. There could be some performance impacts. I'm running it in production right now, and it seems to run fine, but it could depend on your workload and how much your workload crosses package boundaries. 'Cause we do some extra protection to make packages not be able to mutate what the other packages export. Yeah, there's like 3 main dangers in JavaScript that we worry about. One is the basics is Object, capital O Object, and capital A Array. Like the basic built-in functionality of JavaScript is all mutable, and so you don't want that to change, and so Sets locks that down. And then, we want to limit access to platform APIs, like disk, like network, and the Cess containers help us with that. And then, the LavaMoat kernel is limiting packages talking to each other and preventing packages from corrupting each other.

22:35Robert HurlbutSo, do you have any— I mean, you mentioned performance and the fact that you're running this in production. I think that's always the million-dollar question. right, for anything like this is what's the hit by— is there, you know, have you done any kind of analysis or anything to say it's a 10% performance hit, it's a 1%, it's negligible? Because I think a lot of people are going to be thinking about that when, you know, you're talking about a production-grade enterprise application that's really scaled out. You know, 10% is a big deal. 1%, you might be able— you could probably get away with. So any thoughts on what the actual kind of metrics would look like for performance hit?

23:11Aaron DavisIt's a great question, and I was just scheming up today a good way to get decent metrics on that. I don't have one now, but my server run— so we run like a test network, free Ether distributor server. So like if you're deploying some smart contracts to Ethereum and you don't want to pay the transaction fees of the real network, just put it on this little test server. And so we have an automated faucet that will give you sort of fake test Ether for this test network. And so that has a private key that needs to be protected. I mean, this thing is kind of low stakes, but it's there and it's being hit by traffic all the time. And it runs exactly the same as before without the Lovemote patch applied. So I'm pretty happy with that one. And it's still using— so like for the cryptography it's using, it's still using native modules. So it's calling out to C for those modules. And it's doing that for just this one or two packages. And those packages are whitelisted to be able to run C as well. So it— from a pure security perspective, being able to call out to C, like, as soon as they're doing that, we can't contain it any further. So like, obviously, that sounds bad. but it is practicality. This is how you run your app that you've already built now that is already calling out to C. That's one of the key goals of Llama Mode is like, you should not really have to rewrite anything. You should, I'm not trying to come up with a new paradigm for how to build an app here. I want to take what you have and run it more safely. And the best part is if the security guarantees, I mean, I'm, espousing LavaMoat provides, even if there was a flaw found that tears away all the security, you're back to where you are today. You just have no protection from supply chain attacks.

25:11Robert HurlbutYeah, it doesn't get it. It's not gonna make anything worse by having, you know, that challenge. So now, now I'm putting my, my kind of threat modeling hat on for a second, and I'm thinking, okay, How do we attack this thing with Lava Mode fully going? And so you mentioned that you have kind of a JavaScript, a kernel that's running that's in JavaScript. And so when you're thinking about this, like, what are the potential threats when you have a fully— when you have Lava Mode going? Is there any— how would somebody attack this if they were trying to come in from another angle, get inside, and then potentially turn off the Lava Mode, the protections, the package policy? And I'm assuming the kernel is doing some type of a, you know, it's mitigating those individual requests and deciding, like, do we allow something to go through? Like, what are the potential threats about how somebody could actually attack Lava Mode itself embedded in an application?

26:14Aaron DavisYeah, there's a few different things. There's, like, if you are It depends what kind of package you're like trying to hijack in order to perform this attack, or however it's set up. If that package is already positioned to like deal with something like the network, then it wouldn't seem strange if it, you know, had network access, something powerful like that. Or like I said earlier, the, you know, some native modules, some of them were just trying to call out to C for like the sake of performance or something.

26:44Robert HurlbutYeah.

26:46Aaron DavisOne thing that Lovemode does not do a good job of protecting against is things that don't require any fancy platform APIs like network access or exfiltration, but they kind of sit in the middle of your app and mess with the data as it flows through. And an example for MetaMask, we have transactions that are going through an approval phase and then eventually get cryptographically signed and sent off to the network. If you sat in the middle and you could mutate the transaction parameters and say, no, don't send money to them, send it to me, you didn't need disk access or network access to do that. You just messed with really important application data and its throughput, and then the rest of the system carries off the attack for you.

27:30Robert HurlbutBut you'd have to get in through some other vector to be able to cause that level of disruption. So it wouldn't be— it would be some other type of vulnerability they would take advantage of. Not a lot. It wouldn't be specific to Lava Mode.

27:45Aaron DavisOh yeah, that's not really— well, it's specific to Lava Mode in that it would be way easier to do without if you didn't have Lava Mode. If Lava Mode— this is like one of your remaining options is to like manage to get control of an evil package that is like Really well positioned in the app, like you happen to be passing in the sensitive state into that package. And so I don't right now have good tooling against that, but I've been looking into something like points to analysis where I can where you know a developer could find some sensitive part of state of their app, and then it it could basically walk walk the the code and say like. So potentially, these packages get direct access to mutate this state, this variable that you've highlighted your cursor over.

28:36Robert HurlbutSo you mentioned earlier you were doing static analysis of those packages. So this is a function of LavaMote. Is it actually doing static analysis of the packages that are being imported? Was that just to generate the policy, or is that also to see if there's a— if you're using a package that's doing something that you might want to reconsider?

28:57Aaron DavisYeah, right now it's just for generating policy files. But if it— if the policy that it generates looks a little suspicious, that it's a good time to investigate what's going on.

29:08Robert HurlbutOkay, so that would be the— that would be the thing for you, would be if the, you know, the policy pops out, you're looking at it going, boy, it's really trying to do a lot of things that don't really seem to make sense, that that would be another positive for LavaMoat where you would have some insight into the application that you might not have had if you just launched a Node app and It pulled all the dependencies and started running.

29:28Aaron DavisYeah, precisely. And so, right now, the policy file is on a per-package basis. And so, for each package, it says what other packages it can import, what globals it can read from or write to, and, for the case of Node, what built-in modules, like the ones that are provided by Node— Node has some built-in ones, like crypto and so on. like this, and the browser may be introducing a similar thing. So there's a policy file for saying what of those you can import, because those are particularly dangerous. And then if you include native modules—

30:07Robert HurlbutFor those policy files, I was wondering about this.

30:09Aaron DavisWhen you generate those, can you tweak them? Can you go back in and look at them and tweak them as needed? Yeah, absolutely. So the idea is that it will generate— we generate the 2 files right now. I might change the way this works. But one is completely computer-generated, and it should work without modification. And then there's a separate one that you can override and add overrides to. And the idea is you commit both of them to version control, but when you install new dependencies or something like that, and you want to generate the policy file again, you can just squash what you had before, but then your overrides are maintained.

30:47Robert HurlbutOkay.

30:48Aaron DavisOkay, cool. So if anyone's interested in Lava Mode, please check it out on GitHub, github.com/lavamode/lavamode, and there's instructions in there. The best operating one right now is for Node, but there's also a Browserify plugin, and I'm working on a Webpack plugin. And so you need to— I originally started with the Browserify plugin. And that's just one bundler that makes your JavaScript app ready to run in the browser. Because that's what I was really worried about. I was worried about our app being compromised. And then as I thought more about the problem, it's like, oh, well, if the app build process is compromised, then you couldn't have created a secure app. So you also have to run that build process, presumably in Node. securely. So, you want to start with Lava Mode Node. Actually, the first thing you want to do is you want to run npm install or yarn install or whatever you use and make sure you ignore scripts, because you can have post-install scripts and pre-install scripts and all these things attached to your package. That's a good way to have your system owned. So, once you've disabled that, maybe on your build server or also on your personal development machine, then you want to move on to moving your builds, your build server, or just a server if you're just running Node stuff, in Lava Mode Node. And so, yeah, you do Lava Mode Node, generate a config file, and run it, and see it happening. You can also run Lava Mode Node with another flag, which will generate sort of like a debug file or a manifest file, and then you can load it into the Lava Mode Visualizer, and that will give you a visual representation of your graph. And will attempt to show you which parts of your graph are particularly dangerous. Okay, so this is an example of the Lauthamo visualization. On the left, there is a list of all the packages that are included, and on the right, in the main of the screen, you have a force-directed graph of a bunch of little circles attached to each other.

33:01Robert HurlbutOkay.

33:02Aaron DavisThere's this one little— this is a particularly complicated app, and so this has been the main problem that I've been trying to tackle, is this dependency graph. The purple one here at the center is the app code itself, and all the other dots are packages in this dependency graph. And these dots are colored to give you an idea of how featureful or how many platform APIs are given to them. that might make them dangerous. What's interesting when you look at this graph is that most of the nodes are green, and that means they have no platform capabilities. They're not using network or disk or something like this. They're merely abstractions on top of the APIs of other things. And then, throughout the network, there's a few things that are red, and so let me— Let's Pick a good one. This one is VM Browserify, and it is labeled as dangerous because it has access to the DOM. This is for a browser build. And so if you have access to the DOM, you can inject script tags, and then you have unboxed JavaScript access. And so doing anything with the DOM is sort of dangerous and sort of out of our sandboxing reach here. Except that everything else doesn't have access to them. So the list is useful in terms of if you want to prioritize an audit of your dependencies, that's helpful, but it's also important to understand it as a graph because if you have some element in here like this one, crossfetch, its whole job is to just export a network API. And so the thing that's consuming it over here has full access to the network. even though it's, you know, it's green, it looks like it wouldn't have access to the network. So it is important to understand it as a graph.

34:53Robert HurlbutYeah, this definitely gives you some perspective on the complexity though. Like when people are— if somebody's sitting there going, I don't understand why software supply chain is hard, look at this picture. That is why software supply chain dependency management and dependency vulnerabilities— this is why it's hard. And just looking at on the left there, I'm seeing like UUID, I see like 3 or 4 or 5 different versions that different packages are dependent on.

35:22Aaron DavisOh, yeah. Yeah, that's another thing too. And those are all from one publisher. With complicated apps like these, this has UI elements and stuff in it too. Those dependency graphs are particularly large. But yeah, when you look at the graph, it's kind of a rat's nest. There's so many lines crossing. And to try to untangle it and also to as an excuse to do something weird, I made a VR version of this. So, you can throw on a VR headset and look at this hairball as a 3D hairball. It looks a little bit better, and then you can have some fun sci-fi vibes of searching for the vulnerability in the network graph. It's fun. So, if you wanna take OpenMOP for a spin, you can spit out a config file and then spit out a visualization file, which is exactly this dashboard for your app.

36:15Robert HurlbutYeah, so there's many, many different use cases. I mean, it could be helpful to run Lava Mode in its native form where you're actually running the policy, but this is also a great visualization tool if you're just trying, especially if you're trying to convince somebody, hey, here's why we need to look at using this tool in production. Here's the— this is a great way to see your app. Now, this isn't like a demo app. This is actually the app that we running in production today, look at all the red dots that exist here that represents potential risk in the packages that we don't even know about.

36:48Aaron DavisAnd you can add the generation of this visualization to your CI flow and, like, have a little GitHub bot post a link to it every time that, you know, a pull request comes up or a commit is made. And so you can see, this is what it looks like now.

37:00Robert HurlbutYeah, who broke the visualization? That'll be the new— it's not who broke the build, it's who made— who added a red dot And then they'll be in trouble at that point if they add a red dot.

37:09Aaron DavisSo I think this is a great way of starting that conversation with your team, especially, like I said before, you're really exposed to those direct dependencies, and you're not thinking that much about your large dependency graph, except when you're watching those dependency install times. They're all flowing in then, and you're like, hmm, where'd they go? Okay, stop thinking about it now. Now, if you have this graph, you show them that, it's like, oh, there they are. There's all those packages I saw being installed.

37:36Robert HurlbutSo Aaron, thanks for kind of taking us through and helping us to understand the software supply chain challenges from the JavaScript world. Also understanding Lava Mode, all the different components, and then even deployment options we've talked about here. You mentioned the GitHub page. That's a good resource for folks that want to, you know, look, get more information or figure out how to use this. What would be a key takeaway or a call to action? What would you like to see our audience do as a result of all the knowledge that you just shared with them?

38:08Aaron DavisYeah, yeah, I think that the big thing there is starting to talk about this with your team because this problem is not talked about enough. Sometimes, you know, it comes up, but there's not a good solution there for how you tackle these things. So people kind of drop it. They're like, oh yeah, this situation is really bad, but what can we do about it? And so the conversation kind of ends there because there's not a lot of solutions out there. And I think Llama Mode is one of the first solutions out there. So in order to bring that conversation back up with your team, try it out, make this visualization, send it to your team, and show them this cool graph that you made. And then people will start asking questions like, what is all that? What's going on? Oh, that's our app. Didn't you know?

38:54Robert HurlbutCool. Well, thanks, Aaron, for taking the time to share this knowledge with us. And it's definitely, definitely been great to learn. I've learned a number of different things about JavaScript and Node just in this conversation. So I'm sure our audience is going to learn a lot as well. And so thanks for being here with us. And thanks for sharing your knowledge. And thanks for investing, I mean, the hundreds, if not thousands of hours that go into running an open source project.

39:18Chris RomeoYeah.

39:19Robert HurlbutNot everybody knows that. Not enough people recognize how much time people volunteer. And like you said, you're not getting paid. This is, this is a labor of love for the community. So thanks for the efforts you put in there, and thanks for being here today.

39:32Aaron DavisYeah, absolutely. Thanks.

39:35Chris RomeoThanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securitycast.net. securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @roberthurlbut. Remember, security is a journey, not a destination.