ActiveState wants you to stay a step ahead of open source dependency woes

Speaker A: Hello everyone. Thank you for tuning in to this episode of uh, our podcast here at Software Plaza. Uh, we recently actually rebranded from Amazic to Software Plaza. So in case you're used to following us uh, on our different social media and on our website Amazic, uh, want to update you that with this rebranding now you'll find us@softwareplaza.com and we're in the process of just updating all of our social media handles right now. Uh, so just know uh, that we're going through this transition. Um, uh, but uh, what's not changing is our focus on topics uh, related to the cloud and DevOps, uh, cloud native. And uh, today we're going to be talking about uh, security and more specifically software supply chain security. I have with me today, uh, two uh, guests who uh, are working in the trenches in this space and here to talk about uh, all that they're building and the cool stuff that they're seeing around them. I'm quite excited for the conversation today with Scott Robertson who's the CTO at Active State, and Pete Garson who's the Senior Director of product at ActiveState. Scott and Pete, great uh, to have you guys with us. Thanks for joining. How are you doing?

Speaker B: Oh amazing, thanks Twinning. We're really excited to uh, talk about uh, a topic near and dear to our hearts.

Speaker A: All right, yeah, Software supply chain security. You know, before we get into all of that, tell us a bit about yourselves, um, your journey so far and how you got to Active State.

Speaker B: Uh, Pete, you want to start?

Speaker C: Uh yes. So you know I've been working in technology pretty much my whole career. Um, I did uh, about 15 years in video games uh, before I switched over to uh, working in open source. Uh, Open source is something that's been sort of near and dear to my heart, my, my whole career. And so um, uh, I was happy to get a chance to work with ActiveState. And so I've been at ActiveState now for about seven, almost eight years um, and uh, seen the evolution of ActiveState from uh, providing sort of Perl and Python distributions all the way through to the um, sort of self serve uh, platform for managing all of your open source and uh, helping you uh, manage your supply chain security at Active State. So that's been a really interesting evolution to see that change, change from that uh, from when I started to where we are today.

Speaker A: And have you always been involved in product or have you moved around pretty?

Speaker C: Yeah, pretty much. Yeah. Like I was uh, I, I did the the latter half of my career when I was in games, so I was a producer kind of thing which is the same, basically the same role as a product manager. So and I did start at Active State doing a developer relations kind of thing to being a developer advocate. So I uh, you know, always had a, you know, keen ear to the developer perspective um, in uh, in open source.

Speaker A: Great Scott.

Speaker B: Yeah, I mean my, my background, um, I've always been kind of the startup guy with a focus on enterprise software. I like to tell everybody that this is actually my second tour of duty at activestate. I was with them um, uh, in the early 2000s before I went off to work at a bunch of other kind of startups and things like that. Um, the kind of interesting story when people ask well, why did I come back to Active State? Was I was working at a, um, at a startup called Six Sense. We were working on predictive analytics and I was in charge of the uh, the data science with the data engineering team. We were helping data scientists take their models and get them in production. And it was kind of a funny day. I was, I was literally sitting at a laptop uh, with a new data scientist that we had just hired and they had been working on a project for about a week or two and we were trying to get this thing into production. And it was always kind of the same story where like data scientists would just run out and just copy and paste code from all over the place to get their system up and running. And then it would be like investigating this crime scene to figure out what they did to get to this point so that we could turn it into something that we could run at ah, scale. And my old boss called me up and said hey, how would you like to come back to Activate? And I was like, I did some work with them and they're kind of claim the fame as they helped port languages like Perl and Python, um, in the late 90s to the enterprise operating systems that people uh, want to use. So we were helping port Perl and Pearl to make it work on like uh, Windows and big Iron machines and things like that. And I was telling this, telling um, my former boss Bart, who was a cto, uh, or CEO at the time, uh, of Activistate, is like that. Activist business is one of the most boring businesses in the world because it's all dealt with managing open source and I really hate it. In fact I'm dealing with that problem right now where people have gone out, got all this dependencies and they're just independency hell, nobody wants to do that. He's like, you're right, nobody should be dealing with dependency management issues. Why don't you come back to Active State and figure out a, a better solution for that? And that kind of became the seeds to the idea uh, that Pete and I started working on, which is like Open source is this great tool. Uh, enterprises have adopted it, they're relying on it, but at scale, when you get, start working with teams and managing and tracking becomes in some cases, uh, an impediment to the way that you work your code. And it's like in some estimates we have like 30% of your time is just managing your dependencies or the consequences of the dependencies you have. And it just kind of became our driving mission. Like how do we get rid of all of that minutiae and work that everybody has to deal with with managing open source, whether it's acquiring it, building it or now lately just dealing with all the security consequences of it. And it's like more and more of these things that we rely on are just taking more and more of our time and taking us away from the greater joy of it. And that kind of became the roundabout way and the motivation of rejoining activestaking became our new mission is like, let's just get rid of all of the pain points of using open source so we can all get back to what we love, which is developing software and making great products for people.

Speaker A: Right. Quite a story. So I have to ask, how old is Active State then?

Speaker B: Oh, uh, I think we were founded in, I should know this. 97, 98. So we've been around for about 20 years. Um, um, maybe I'll just give you the brief history of Access Data kind of touched on that. We, like I said, our claim to fame is we helped get, uh, it started off with Perl actually. So the time the web was taking off, uh, people were learning how to build CGI programs on web. And the tool of choice at that point uh, was Perl. And people wanted to take Perl to work, but it wasn't supported on the hardware and operating system platforms uh, that everybody needed. And so um, uh, ActiveState helped Microsoft Port Perl to Microsoft Windows. And then we just built this great business of supporting, um, supporting getting open source in the enterprise. And I sometimes joke that we, we helped create. The problem that we're now trying to solve is everybody wanted to use open source inside of the enterprises. And so we started uh, dealing with a lot of the complicated problems of getting open source. To compile and build and manage dependencies. And a lot of this was at the time when dependency package managers and things like that weren't a thing that the community was providing. It was like if you wanted Open Source you had to go to Usenet groups and uh, collect it yourself. Then what you saw is you had players like um, Red Hat and suse and stuff like that collecting Open source and making Linux distributions. And what ActiveState did was we collected open uh, source components for developer use cases along language um, lines. So if you wanted Perl, we'd get Perl to work across multiple different operating systems at the same time or if you wanted Python we'd do the same. Uh, so we've been at the whole Open source management game for quite some time. A lot of it has been helping companies deal with license management issues and build related issues and now it's morphed into security risks. And so there's just a lot of all these great advantages you get. There's also a lot of risks that are involved with IT and Active States here to help um, enterprises deal with those problems.

Speaker A: Uh, that's uh, quite some pedigree there. Um, but yeah really long that you guys have been at the problems and challenges with Open source security. Uh so yeah, uh, really curious in all uh, that you guys have been working on and just your opinions on the way things are uh today uh, uh, I wanted to talk a bit more about just uh, how uh things have changed uh since then, uh since uh when Active State started and more recently now we're talking about uh security in terms of cloud native and uh Kubernetes is now like the biggest, most widely used uh open source tool in the cloud. Um and it's pretty much like defining uh, it's bringing people together around uh just how to run things in the cloud and so it's become a big part of security conversations. Uh, I want to get your take on just uh, what has changed, uh maybe in your stint at Active State when you said you came back and you guys were building something new, uh what was the scene? What did you notice that's changed, that's new and uh, what have you guys been building?

Speaker B: Yeah, I mean my biggest perspective when I left Active State, um, at that time I was kind of alluding to this. The acquiring Open Source was the biggest challenge and dealing with the licensing issues related to it. At that time organizations were very fearful uh, of what bringing in something like a copy left license might do to their code base and then kind of like the bigger shifts that happen in the marketplace. And I often like to tell people, uh, in the battle between closed source and open source, open source, uh, one, we're all comfortable with it now, we all bring it in easily. Uh, in fact we might have become too comfortable with it. And then on the other case of it, we have all these communities that have produced easier ways of distributing and acquiring open source. To the fact now that we got in the state of the world where it became just really easy to. I'm working on a problem. Oh look, there's a library. I can include it into this. Seemed like a bunch of people are using it. I'm going to include it. And then when you, when you hit that at like enterprise scale, I mean we deal with organizations that have development teams of 10 to 30,000 people and uh, all the way down to 50. But you know, when you get these large, lots and lots of teams, lots of competing projects and deadlines, people have just been grabbing all these components off the Internet without understanding the providence of it, lobbing it into production and wondering how things are uh, happening. And now the nice thing is that containers and kubernetes have come along to make that a little bit easier to contain and release that. But in our line of work, what we've just discovered is open sources just come into these organizations this big accelerated rate. And the biggest challenge we see right now is people don't even understand how much open source is in their organization, where it came from, who built it, who put it there, when was the last time it was used. And, and you, you compound that to the fact that, you know, you've got these threat actors now. Like we deal with companies that build software for nation states and um, m, those themselves have become targets for, for attacks. Right. People are saying, hey, there's, there's all this stuff being uh, built and produced by uh, communities. And they're not, you know, they're looking to build great software. They're not really thinking about things from a security perspective. Well, that just puts a big bullseye on if I want to get into an enterprise. If I understand what open source you're using now, I have a blueprint of how I might be able to get into your systems and find out more information about you and make you more vulnerable and attack. So it's like we've made it really easy to consume open source and now we're kind of suffering the consequences of that. And I think it's for good reasons, but that's to me the biggest change. And now it's not. What I see ultimately is our use of Open source is also starting to slow us down because we have to start worrying about all these other consequences people should take on this.

Speaker C: Yeah, I think that the scale at which that enterprises uh, are able to ingest and like utilize open source is probably the biggest change. Right. You know, at the beginning when Active State was founded, you know, Open source was pretty, still pretty niche, you know what I mean? And, and what, you know, wouldn't have been as widely adopted. Um, and you know, the rise of things like GitHub, um, uh, where it just became so much easier to access the open source and get it in, you know, used in your product to the point now where like over 90% of the code in pretty much any code base is going to be consisting of open source and the dependency chain is going to be huge. Right. You know, if you. Modern stacks, even for things like websites are, you know, have hundreds and hundreds of dependencies and most people don't even really know what, you know, all of the things, not just in terms of like what's being used across your organization, but just even an individual developer for the most part when they pip install something they just think, oh yeah, I'm installing TensorFlow, I'm installing whatever Flask or Django or something. But they don't realize it. Okay, but you're also installing all of this other stuff that goes along with it and those stacks are getting more and more complex and the scale of it is just so large now that uh, you, you really need specialized tools to be able to keep track of it in a, in a coherent way.

Speaker B: Maybe I'll talk a little bit about the scale because I think developers, you know, we, we like to, we do a lot of complexity. So in our mind we always try to realize things to just these things, but we don't sometimes take a breath back and look at what we've done. It's like if you, you think of like modern application development, okay, you're on a team of a, of uh, 100 people and you're leasing software and maybe your software, uh, we still have customers that you know, ship software to people, uh, in on prem. Locations and are running things in the cloud or running in containers. And now it's like every version of that software that you're releasing might have a different set of dependencies that you have to worry about over time, but it gets even worse than that. Like when you're in the development process. Even the difference between what I'm doing at my Laptop versus what Pete's currently doing at that laptop could be changed like PIP will give you or, or NPM or these packages managers, unless you're like really meticulous about how you're managing your dependencies, is going to just give you the latest version of whatever's available right now on the Internet when you make that request. And um, if you're not diligent about all of those processes or you don't have tooling in place that makes that consistent, which is kind of the, if you want to get to what ActiveSt data is fanatical about, it's repeatability and consistency. But we're trying to build these tools so that you have the exact same experience on every single environment that you're building your code in. But if you're not diligent about that all of a sudden, what happens if you start just bringing in random different combinations of open source components that look like they may work or right, uh, may look like they work on your development machine but might be different somewhere else or who knows? It's really easy to slip a vulnerability um, into that particular case. Um, I don't want to get too much into the FUD side of things because I don't really think that's what ActivState is about of saying hey, you know, open source is scary to use. It's just the scale of having to deal with it makes having to worry about these issues a lot more complicated and we're more focused on how do we contain that chaos for you so that you don't have to think about these things.

Speaker A: Yeah, yeah. You guys really described uh, the various challenges around uh, open source security really well, uh, from various perspectives. I see on your website one of the first things it says is what Active State does is discover, prioritize and curate trusted components. And I want to dig in to uh, talk a bit about that. And the approach you take and uh, does is, is, is uh, something like an S bomb which uh, has definitely been uh, you know, uh, in, in the news a lot. Um, and it's been getting a lot of attention from security folk. Is that a central piece to how you do this or is that one part but you, you've got more an overarching security strategy that uh, you, you follow. Could you talk a bit more about just um, how you approach all of these challenges?

Speaker B: Yeah, um, I'm glad you're talking about SBoMS. It definitely is uh, a central thesis of this and in fact what ActiveState takes is what we like to call an SBoM first approach. So what you see currently out there in the field, which uh, is different, is a lot of people build and assemble their applications. They run, uh, they build the application or CI CD systems and then at the very end of the process they generate an S BOM here's the bill of materials that we use and we kind of think of that stance.

Speaker A: And just for the record, could we just like explain what an SBoM is really quick?

Speaker B: Oh yeah, absolutely. Yeah, yeah, yeah. Thank you. Um, yeah, no, SBOM stands for Software Bill of Materials. And it's essentially if you go back to the problem we're talking about, which is just like open source is pouring into an organization to the point now where people don't even know what it is, uh, an SBoM is a record of saying this application or library that is being used is comprised of all these other individual open source dependencies. Um, you'll call them, some people call them indirect dependencies or transitive dependencies. Is basically this thing depends on this. That depends on this. It depends on this. The bill of materials lays out all of those individual components. If you're lucky, it has checksum information. It can basically give you a way to say this is exactly what should be powering my other application. Um, and the purpose of that bill of materials is to tell you that later on, uh, a vulnerability might be detected, uh, somewhere in your open source dependency, uh, chain that, hey, I'm actually impacted by this and therefore I should update that software component. And that's kind of the thing that people struggle with, is they don't understand all of the dependencies that are consuming the power of their application or the impact of changing that component, uh, that. So SBoM is, is kind of a record. There's a couple different formats that people have created to kind of give you that inventory of what you're consuming so that you have some more data to understand the impact of vulnerability threats or upgrades or everything else like that. And um, so they're kind of being championed as this thing that's going to help us with all of our security problems. And it's, you know, they're right in some cases. But there's also how you go about producing your S BOMs and what you go about doing to manage them. Is the point that I don't see enough people talking about in this because that's, that's a real point. It's just having a list of what's in your components is just the start of, of the process. And so this gets into like kind of unique take that we have is we, like I was, I was mentioning is we focus on what I call the, the SBoM first approach. So instead of letting it get all the way through your CID process and then you build your bill of mater, we start by assembling the bill of materials first and then building your application off of the things that um, we've created in the bill of materials. And so what probably makes us the most unique out of everybody here is that we've been at this whole software dependency management longer than even the open source communities have. Uh, so we have our own systems and tools and processes that we've used to manage the build complexity. There was a point actually When I rejoined ActiveState, we were doing over a thousand different unique builds for uh, various organizations and just Python alone. And it was like some 30 odd combinations of operating systems and hardware platforms. So we got really good at just understanding and managing what Open Source had and that became the platform that you see today. And what, what we're doing is we're running out, we're taking a catalog of all the open source that's being released on a nightly basis in the open source and then we're, we're capturing that in the immutable cat that we have exactly those individual components that are always reproducible. We can always give you the exact same bit of source code. Everything we then deliver to our customers, um, is built from source from that code that we've captured into the binaries and then distribute it back. And we can deliver that as we deliver the bill of materials from you. And at the heart of all this is a component that we call our solver, which is sort of, we have created a system that is, I like to call it the um, it's kind of the superset of all software dependency managers out there. So we understand how Python manages its software dependencies or how Go manages its software dependencies. We're working on rest right now, uh, from these things. We're putting them all together so that you can just come to our platform and say, I need this open source component. We can figure out the transitive dependencies for that component. And even more uniquely is we will jump across ecosystems, which is one of the other big challenges that you'll see in the ecosystems today is like Python only knows about Python dependencies and if you're on Rust, you're on your own. You gotta learn another set of tooling, uh, for that. Or if Python is using a Java component, um, you'll have to understand the Java stack, um, various things like that. What ActiveState's done is we've modeled out the software dependencies, cross ecosystems, all the way down to the bare metal, uh, libraries. From that, and that is how we can just, you tell us one dependency, we can figure out the complete set of transitive dependencies. We build the SVOM, we generate the SBoM. From that, we build your open source components and then we can give you uh, that manifest saying this is exactly what you're using. And then that's just the start of the story, right? So now that we have this SBoM, we're cracking that SBoM. So now as we're monitoring the Internet for the rest of the open source components out there, we're able to say, oh look, there's a vulnerability. We know all of our customers who, we've generated a build off of those S bonds for right off the bat, and we can notify them. But not only do we notify them, hey, you got a component that's missing, we can notify them like, hey, your, your component has a vulnerability. We already know the dependencies that you have, so we've rebuilt the entire set of dependencies for you and it's ready to go. Or in some cases we'll be like, uh, we've done it. But guess what, you're independent CL if you try to take this update yet you can't take the fit. And that's kind of the unique part of ActiveState is because we have this S1 first approach, we just have much greater clarity of the open source you're using and its impacts on the updates and changes, uh, from that.

Speaker A: All right, all right, really interesting. Uh, Pete, did you want to add something to that or uh, do you think it's a good time to get into uh, a demo or a walkthrough?

Speaker C: Maybe that's. Yeah, maybe it's a good time to sort of fire uh, up a demo here and walk you through uh, what this actually looks like in terms of that SBOM first approach and what it looks like in terms of uh, being able to um, being able to uh, get that reproducible history for anything uh, uh, inside your organization when you're making a project. Let me just share my screen here and I will uh, screen and I'll walk you through. So the first thing. Can you see if you can see everything? So the first thing you're doing right, as we're saying is we're starting from an S bomb, right? To say like uh, both in terms of how our system works but also in terms of discovering, you know, you might have a lot of S BOMs inside your organization. Thing we talked about earlier was like oh, what actually is being used inside my organization? I have a whole bunch of teams, I have a whole, they're all using different components, um, they might have S bonds for those things. Maybe I want to be able to scan my kubernetes cluster directly and see what's actually running in production. Uh, maybe I want to look at my GitHub repos, right? And, and I might have you know, whether it's package jsons or pip files or you know, requirements, uh, txts inside my, my repos, that's another way I can use, can discover what I'm using. But the SBOM might be the most sort of comprehensive. And so whether you're generating it from our platform and going directly from our catalog, or whether you are um, using you know, a third party tool where you can generate an S bom, you can essentially take those SBOMs in the different formats, whether it's SPDX, CycloneDx and you can import them into our platform and what our system will do is analyze those and, and break them into different applications that you're running. So in this case I've got my local environments, in this one I've got my production environments and then it's going to do, is going to create uh, do an analysis of those projects and create a kind of dashboard for me to say hey, here's the breakdown of the stuff that the software you're using inside your organization. You've got 2,000 something dependencies, 69% of those are C, sometimes some of them are go Java, Python and this is your vulnerable vulnerability profile, right I've got this vulnerability profile where uh, you know, I've got 12 criticals here and 77 highs and all my individual applications are broken down here into specific uh, little projects. And I can go into that project and I can see the components, right? I can see this is a Debian base image and here's the Python packages that are being used, here's its vulnerability profile and here's all of the dependencies that uh, the system has solved for inside my organization, inside my project. And so if I want to do remediations with that though, what I can do is have the system check for some available remediations because like Scott said we have this whole catalog, right? We have, we know everything that you're being, that's being used. And so we can say actually in your little Python ML runtime here, you know you currently got 73 total vulnerabilities. But we know from our catalog, uh, and the versions that you're using that if you go from you know, in this case numpy 122 to 126.4 and pandas 1.2to 2.14 etc. We can eliminate all those critical vulnerabilities and dramatically reduce the highs. And so you can see this, it's going to show you the kind of diff of this is the changes we're going to make to this project. And it can also indicate that there might be some breaking changes that you might have to um, take a look at here. Because our system is focused really on your third party, you know, your third party code, your all your open source, we're not ingesting your first party code. And so if we look at over here at the, you know, it's going to say breaking uh, changes, you're going from numpy122 to 2.13. That's a major version change. There might be some sort of changes to the function signatures, that kind of thing, parameters that might impact your code. We can't tell you definitively, but we can at least give you the information that you need to sort of vet whether you want to take that change or not. And so if I'm say oh I'm happy with this, then what we, what it will do is we'll uh, update the project, make those changes. And so then when I go over here, it will then build this stuff so it'll build all those components from source and so giving you that kind of provenance of I know definitively that I'm getting this from active state, right? If I'm just like pulling something from NPM or you know, PYPI or something, I'm um, pulling a binary usually from the public repository, but I don't necessarily know where that was built. Like was it built on somebody's laptop in a secure CI farm, you know, where was it built? Whereas what we're doing is rebuilding everything from source here. And so you know definitively that hey, this is built from uh, from source on our platform. And what it can do is then give you the instructions to do any integration. So in this case, you know, if I'm using Docker, it'll say uh, oh, you need to update your Docker, compose YAML file. No problem. We've made a little pull request for you to show you uh, uh, how uh, to integrate that into Your, your um, deployment, if you're using helm, et cetera, et cetera, you know, it's, it's making those changes for you and we even give you the ability to drill down and view the logs. So if you want to see, here's the actual compiler output from uh, this build I can drill down into, see every component as it was built from source. Then ultimately what you can do is because uh, we are like Scott was saying, we're mirroring all of the uh, open source. One of the things we've done is kind of married the concept of source, uh, control and dependency management. So you can see like a vetted history of everything, uh, that uh, every change that you've made. And so if you go back on, and actually I have one open here, if I go back, I can see that I've made a commit here on my history tab, right? This is made on this particular date by me. And here's the catalog revision id. I can see all the exact changes that I've made. I added these languages and so forth. But I can also see this catalog revision id that this is the state of the world at that time, which really I think differentiates us. Uh, so we have that catalog. You know, if I run NPM install on Friday, then run it again on Monday might get a different result. Right. But in our case, because we have a catalog revision id, you can go back in history and definitively uh, get exactly what you were uh, looking at at a particular day and time. And so that's the sort of like high level loop, right? Is that what I'm doing is I'm discovering open source that's running in my organization. Then I'm getting tools where I can sort of go back here getting information and you know, data that I can use to prioritize the changes. Right. I can curate the changes that I'm doing as well, both through the catalog and selecting specific versions. We also have the ability to set policies and stuff like that. So you can be like, oh, I don't want any copy left licenses or I don't want any vulnerabilities below a certain threshold, this kind of thing. Um, and so you do the curation and then you do the deployment. Right. And so that was the last piece that we saw here where in our vulnerability you could do the deployment, whether it's back to your Docker thing or your Kubernetes cluster or maybe it's just like your development laptop. I'm just going to pull this down on my development laptop for the Next iteration of what I'm doing, uh, on my, you know, on the feature development.

Speaker A: Wow, great. Oh, this is a wonderful demo. And I quite like how, just really helpful at different points, uh, your platform is in just uh, suggestions and even uh, thinking of things that might break. That's quite impressive. Uh, being able to see what might break and even being able to just update the projects with the click of a button really, uh, just amazingly helpful is what comes uh, to my mind when I look at uh, just the demo. Uh, so really great demo there. Uh, Scott, is there anything more that you wanted to add to what Pete was saying?

Speaker C: Uh, no.

Speaker B: I mean, but maybe I'll highlight why this is so helpful is really the focus here. And where we think a lot of people get this wrong, a lot of our competitors, uh, get this wrong is we actually try to model the software after the way that dev teams and dev operations think and we think about them in terms of the components themselves and dependencies.

Speaker A: Right.

Speaker B: When you're talking to somebody it's like, oh, I'm using TensorFlow and Flask and I'm putting these things together like that. But a lot of tooling at UFC out there are all trying to use the um, the native tools and are trying to make that your problem. Yeah, like, hey, we see that you have dependency, but we're not going to even tell you how to fix it. You, you have to be the expert in running Maven if you're a Java person, or PIP if you're that, or, or Cargo if you're rust. We're trying to work, give you the natural components that you're actually more useful for. Your vulnerabilities are in a specific open source component. When you're adding a dependency, it's another open source component. And that's kind of like the relentless focus that we're trying to do is just get you away from the actual tools that you have to use and get you back to the actual more problems and tasks that they have at hand. And that's what then generates a UI that looks like that. And it's just kind of really just built into the mental model that we have here and what we're trying to bring to the world so that we can really accomplish the mission that we're after here, which is we really want to accelerate your development and make you have to stop thinking about all the extra, you know, um, minutia that goes along with managing open source projects.

Speaker C: Yeah, for sure that I think a really key point is that a lot of them basically Give you recommendations that, oh, you've got a vulnerability in, you know, uh, in your project here, you know, you've got a vulnerability in Pillow, you need to update it and maybe you would need to update it to 10. But what is actually going to be involved in updating that to 10? Am I gonna have to build a bunch of stuff from source? Am I going, you know, do I even have the tool chains installed on my laptop to do that? You know, uh, what happens? Oh, I update this to 10 and then something else breaks and you get in that sort of dependency hell loop. Whereas our platform is doing all that heavy lifting for you, including building it from source. You know, uh, first of all, you don't have to have the hassle of building room source and then you know where it's coming from. So that really we've already done the hard work of, okay, yeah, you should go from version 9 to version 10. But no problem, we're going to do all of that work for you, not just generate you a task list that you have to do and deal with the fallout.

Speaker A: Yeah, totally makes sense. Uh, yeah, I mean, uh, every team has a budget, uh, in terms of time and how much they can actually work on, what product problems they can work on and what they can't. And so I think it just, uh, you know, this really gives them a clear picture of uh, you know, what are the different options they have, what's high priority, what can they, you know, maybe leave for a later, later point in time? Um, yeah, in terms of the numbers, I like that it really gives you a number here, how many vulnerabilities you have, how many are, ah, critical, how many are high and all of that. And what, uh, what do you see with your clients that work with active stable? Do they actually reach zero and do they maintain zero vulnerabilities? Or is that more like, uh, nice to have and not really necessary, but so long as you go to, you know, a state that you're happy with, that's good enough.

Speaker B: That's a really good question. Um, yeah, the zero vulnerabilities is an aspirational, uh, topic. Uh, there's never going to be such a thing as zero vulnerabilities. It's, you know, because even code today that you think is vulnerability free today is just our best guess at the moment. You know, there are threat actors out there right now constantly probing code and trying to find new ways to exploit it. And in some of these cases, these things that make you vulnerability vulnerable are also the things that are necessary to make the operations complete. So there's, there is a balancing act that is always going to be there. So there's never going to be this 100% free. Just like you know, security in your home is never going to guarantee that you're 100%. You can have a secure home but you can never leave your house and nobody, nothing can get in and nothing can get out. Right. That's just not a practical perspective. So ours, our take on security is more about understanding what is there, understanding the risks and being able to decide if that's there. So being able to decide if that's something you're going to accept or not and make changes to it. Um, so it's more about making it easy to understand your posture and the changes you are. Uh, and I think the greater focus though should be more on not so much um, eliminating all the vulnerabilities. Uh, well, definitely eliminate critical and high vulnerabilities but there's other ones that are kind of harder to um, exploit. But I think the other focus should be staying current with the open source communities. So that way you're, you're current on top of it. And I would say that probably the biggest mentality problem that I see is there's the old adage in engineering which is if it ain't broke, don't fix it, uh approach which is, leads to. I've written software 10 years ago that I haven't updated on. But the longer you put off keeping your updates, the harder the task becomes uh, in the future. So a lot of more what we're kind of focused on is trying to keep you current. Um, so that if something does major come through that you're not, it doesn't turn into like we've seen some initiatives where it takes, takes a company a year just to update their software dependencies because they put their updates off so long. So that's really what we're more focused on is how do we keep you more current, how do we take all the pain away from staying on top of it? Because a little incremental updates is much easier to manage than something that you've put off for 10 years. And so that's part of where our focus is understand the risks and then make it so that updates are less painful and then can you stay on top of keeping your updates done? That's the best way to be um, to keep your security posture. Having chasing an absolute like a number of just zero vulnerabilities though is, is kind of actually a fool's errand in A lot of cases, uh, Pete, you could probably explain that better than I could there.

Speaker C: And in some cases it's not, um, it's not actually really reflective of reality in the sense that not, not all the vulnerabilities that are reported might apply to you.

Speaker A: Right?

Speaker C: In the sense that you are not calling the function that is vulnerable. And so even though that library as a whole has that vulnerability, you're not exposed to it because you're not calling that function or the environment in which it's deployed has a low risk profile for you. It's like, oh, well, this is just running on Bob's laptop kind of thing as a test server, you know, where it has no external access. We're not, you know, we're willing to accept that risk kind of thing. And so therefore you don't necessarily want a nuisance, annoying, you know, a nuisance alert, right? So getting, you know, always getting everybody to zero, you know, on, on the, on the dashboard kind of thing. You don't, um, it's not always a case of, you know, you have to remediate everything. Um, uh, and you know, sometimes they're disputed and there's also, you know, a wide variety of severities. Right. Like you're going to have tons and tons and tons of low severity, uh, vulnerabilities up there that, you know, might not have any kind of material impact on you versus like obviously a critical one. You know, those, you, the critical ones you need to remediate, you know, asap. And you often have to remediate those ones to maintain security, uh, accreditation, that kind of thing. So you, you have to agree to an SLA for those. And so that's like probably where more of the energy. So you know, the sort of absolute zero number kind of thing is, is m, you know, more aspirational than reflective of a real reality where, where a lot of these things might not be applicable to you.

Speaker B: Yeah, probably worth highlighting is maybe the dangerous mindsets we have. Like I said is one of them is if it ain't broke, don't fix it. Um, another problem that you end up having with, especially in the security space is dealing with false positives. There's many, many more false positives saying hey, you're vulnerable when you're not. That eventually starts to desensitize your team from doing, you know, staying on top of, uh, these sectors. So it is a balancing game, you know, that you're going to have to do instead of chasing zero or being diluted by the false positives, like saying, oh, I'm not really vulnerable because these alarms are going off the time. Those are all things that make us stop doing the good activities of keeping your software up to date and trying to eliminate as many vulnerabilities. Like these are the things we have to do. Um, and then we're just looking for ways to, we at activate are looking for ways to make that as least painful as possible for you so that you can get back to what you really want to be doing which is innovating and creating great technology.

Speaker A: Yeah, yeah, makes sense. As we wind down I wanted to uh, get some thoughts uh, from you on just uh, changes that are probably influencing uh this space of supply chain security, open source security. And uh, one thing that is definitely on a lot of people's mind is AI and ML. Um, you know what impact that's having. Uh, just wanted to know your thoughts on you know what you see happening is AI coming into the picture in security. How and have you guys already started to integrate AI in any way in your product? Uh, any thoughts on that?

Speaker B: Yeah, um, I kind of think about this in kind of two spaces. One I, A lot of these models out there today are being trained using open source libraries. And you know some of the, the biggest, most active projects out there are like our data science libraries to help do these models. A classic example here is like Pytorch and uh, there's a lot of good examples of like friendly um security researchers who are actually attacking supply chains and proving them out. And the thing that's interesting is they're picking these data science packages to kind of move them out. So there was a great one. Um, hold on, hold on a second, let me look up this article where uh, these researchers were just looking into how Pytorch was assembled by open source uh, uh, communities. Let me get the name. This is a great paper. I think people should really. Oh yeah, Plane was fired um, by John Stamwinski. Uh, he wrote this, this researcher team, they went out and they, they analyzed how Pytorch was enabling their community of uh developers to help build Pytorch and they analyzed how easy it was for them to get in. And I don't mean to be picking up because I think it's just this just is an example of this project where this community has made it really easy for people to contribute code and build it into Pytorch. And then I start playing with that model. It's really easy to be piped code uh to Pytorch. What happens when people can contribute Things that can also start impacting models. And then where does that danger pop up? Uh, me, what I really start thinking about a lot is where AI becomes a uh, security threat is when you start hooking AI up to other tools that have ability to manipulate the outside world. And that's all going to be done through open source. So I'm going to take my AI model, it's going to make a decision and then it's going to then talk to my open source components that can then have some impact. It can insert data into my records or I know, God forbid it's attached to some kind of utility system out there in the world and the AI just all of a sudden does something bad and opens the floodgates on a dam or something like that. Right. So these are like the, I'm trying to think like the worst case scenarios and we start thinking about where we fit in the world and where we see that tap room, that space is where AI starts interacting with these open source components we have. And we uh, think that we need to understand that part. And this goes back to, we just had a whole conversation about managing securities, audibility and visibility. You need to understand what LLMs you're using and you need to understand how they're interfacing with your source code and your open source components. Um, and you need to be aware of those threats and vulnerabilities and security and you need to be able to react to them and stay on top of them and as fast as possible because those threats could be coming. Maybe a model is compromised or maybe the model just does something silly. Right? But that silliness could then become some drastic impacts. And so the only way we're going to be able to stay on top of this thing is have visibility into um, these things and stay on top of it. So it's kind of using that same philosophy that we built for managing open source. We're looking at those intersection points and yeah, there's probably an AI story here, maybe Pete, you want to, you can chat a little bit about that. Um, the way to help manage that, we're starting to actively put those things in place. But at the core of it all is like you gotta understand what you're using, who's using it, who put it there, why it's there in the first place and make sure you're monitoring the outside world for known problems so that you can stay on top of that. That's kind of where we see ourselves fitting in and just making that easy to consume and understand those components but hey Pete, what's your thoughts on.

Speaker C: Yeah, I think, I think that's a good way to think about it is that Those increasingly the LLMs are becoming like those models are becoming part of your stack, right? They're almost like another library that you're using. And so does that library have a vulnerability? Does that model have a vulnerability in it or uh, what specific version are you using and where is it deployed? Maybe you have it deployed in 50 containers and you're using some of them are running a slightly older version for whatever reason. And so being able to uh, you know, monitor and observe those things is really, really important to being able to know whether you're you know, impacted. So you can do, take a remediation path and you can say oh well we need to update the version of that LLM or maybe we need to pull it down and retrain it or you know there's all kinds of this is totally emerging right now right like that, that this is starting to change the sort of paradigm in terms of how people think about how stuff, stuff is deployed. Uh, and that's just from almost like an inventory uh, management standpoint. It doesn't even get into what these things can do. Obviously we've seen a lot of usage for them for code assistance kind of thing and what they can do to help automate uh, some of the remediation pieces that we're doing here or to be able to make uh, recommendations or uh, a lot of the sort of behaviors we've seen in other domains. How can that be applied to software development and software security?

Speaker A: Yeah, last question as we wind up is just about uh, your roadmap and just uh, what you're working on at Active State. Uh, do you see solutions for uh, these kind of uh, LLMs and AI related security issues on your roadmap or are you guys working on even more pressing issues? Anything that you'd like to uh, mention to kind of tease us on you know, what's coming?

Speaker C: Well, I think that one of the biggest things that you're, you'll see coming from us is what we sort of saw in the demo here, which is the ability to kind of ingest and parse all of the uh, any, all that data from SBoMS and from a variety of S bomb sources to be able to, to be able to get that holistic view and then also some of that recommendation piece that you're seeing there in terms of like uh, you know, is this going to break? You know, what's the, what's the ideal Remediation here. Right. You know, we, we talk about it as intelligent remediation, uh, on our side. And so what are the tools that we can give people? What are those kind of, what's that? You know, intelligence we can give people to be able to make those good decisions whether it's a breaking change or whether it's uh, you know, the right version to upgrade to that's going to, you know, work with everything else that they're, that they're working on. And maybe that's a good point that

Speaker B: the throw in is when we talk about ideal remediation, this the latest and greatest version isn't always the best remediate version. Uh, for you. I mean breaking changes are a point of your software development stack and there's other constraints that you have. So it's like how do we get you to the point that reduces the most amount of vulnerabilities in your system? Is kind of the, is what we mean by that intelligent remediation side of it is. And it goes back to that we can't always get you to zero, but that means, doesn't mean we do nothing. We try to get you as many things as we possibly can. And how do we make that easier to consume? You spend less time thinking about that and getting more time getting more reductions in vulnerabilities and risks.

Speaker C: Yeah, that real intelligence comes when instead of suggesting to you blindly, oh well, you should go to the latest version, it's version two, it can say actually you know, you want to go to version 1.9 because it's going to remediate all of your critical vulnerabilities but it reduces the risk to your overall software because it's not a major breaking change. So we recommend that you should go to this version, uh, for, you know, for those reasons because it's still secure but it's going to reduce that risk. So that's when we talk about intelligent remediation. That's the kind of thing that we're talking about um, in our roadmap there. And so those things are the, those are like the near term things that everybody should be looking out for that'll that'll be available and then maybe a

Speaker B: little longer term is going into the plan that we're talking about here is that we, we just see this, this correlation between how models are being developed and released on the Internet through the way that open source code is being developed or released by, on the Internet, you know, in communities and things like that. And, and you know, we predict the same consumption pattern that you'll see here, maybe even at an accelerated rate because I think people are a lot more comfortable these days. It goes back to that beginning of the conversation we had where people are just comfortable consuming open source. It feels like people are even more comfortable consuming models, uh, and people are looking for ways to run them themselves instead of running them through big things. So we're predicting more and more models are going to come into your organization. You're going to need to stay on top of it. You're going to need to be able to manage that. You're going to see a new kind of class of dependency management based in, around um, models pop up and it's going to have the same patterns of. Well now I'm going to need an AI bo to keep track of the bill of materials that my AI is part of. I need to know what, what part, um, what components those are consuming. And we're taking a lot of the parallels from open source and applying that to the AI spaces as well.

Speaker A: Wow. Yeah, I, uh, mean that's a great note to end on because that gives me an idea for what we could probably talk about in a part two of uh, uh, you know, if you guys come back after maybe towards the end of the year or something, uh, we could do a part two talking about just security, uh, for AI models and that would be a really interesting conversation as well.

Speaker B: Excellent. Be happy to come back.

Speaker C: Yeah.

Speaker A: All right. Um, so yeah, before you guys go, just a quick question to get to know you a bit. Um, what would be your ah, alternate career path if not for your job in tech? Um, yeah, yeah, I'd like to hear both of you.

Speaker C: Go ahead, Scott, you can start.

Speaker B: Oh yeah, mine, uh, if I could have any job in the world and maybe I've never actually had it, but uh, I would love to work on wooden boats for crazy thing. M. I'm a hand tool enthusiast. When I'm not in front of my computer. It's probably that the counterbalance to my life is instead of having to be working with technology as most low tech as possible would be my other, other approach. But that's probably just too many years in tech at this point.

Speaker C: So I think it's a common theme. Sorry, go ahead. What was that?

Speaker A: I was just wanting to ask what tool is that behind you there?

Speaker B: Oh yeah, well this is the 3D printer.

Speaker C: And then.

Speaker B: Yeah, that's a, this is actually a. Speaking of which. Yeah, it's an old fashioned wood plane for smoothing, uh, for actually making um, yeah, for uh, woodworking on top of it. So.

Speaker A: Yes. All right.

Speaker B: Pete?

Speaker A: Yeah. What would you do?

Speaker C: Um, well, I think it's a common theme that people who work in tech for a long time want low tech, alternative careers kind of thing. And so, yeah, like, for me, I would be a writer. I mean, I do that now, write novels, that kind of thing. And so I would just. If I wasn't working in tech, I'd be doing that.

Speaker A: Okay, so you have a published novel somewhere on, like, Amazon?

Speaker C: I do, yes. You can go to Amazon, search PJ Garson, and you can, you can find my novels.

Speaker A: Wow. That's fun. All right, guys, thank you so much for joining. It was really a pleasure chatting with you both. And, uh, we hope you'll join us again sometime later this year to talk about AI and security.

Speaker B: Absolutely.

Speaker C: Sure.

Speaker A: Thanks to all of our listeners as well for tuning in our listeners and viewers. Uh, we hope you enjoyed this conversation as much as we did bringing it to you. Uh, if you like what you heard, go and, uh, follow us on our social media channels, YouTube, Spotify and elsewhere, and go to our website, softwareplaza.com and you'll find a lot of conversations, uh, on related topics. And we'll see you on the next episode. That's it for now. Take care. Of.