Pete Garcin – Not your Old ActiveState – Tame Open Source Complexity – DevOps Experience 2024

Welcome, everybody. Uh, I'm Pete Garson, director of Products at Active State. And today we're gonna talk about, uh, taming the complexity of open source with active state.

And you've probably know a little bit about active state. Uh, we've been around for over two decades. Uh, we're currently helping 97% of the Fortune 1000 secure their open source.

And we've been around since the sort of late nineties, uh, when we started doing, uh, Pearl on Windows and doing that port, and we sort of, we were also a founding member of the PSF, and we've been working with, uh, enterprises to help, uh, manage their open source for the better part of those two decades. And one of the things we've done recently, uh, we partnered with PI PI on a trusted publishing initiative. And as over time as things evolved, we went from doing things like Active Pearl, active Python, uh, where you might just download a sort of curated distribution of, uh, open source and open source packages to something where instead, what you're doing now is having a tool to manage all of your open source.

And so what we did was we evolved, uh, our product first to meet our own needs, uh, internally in terms of what we were doing to manage open source for various enterprises, and instead move that to a product where all of our users could use this and to sort of help them manage, uh, all that open source and tame bit of that complexity, uh, around what's involved in managing open source from the ingestion point all the way through to the, uh, deployment stage. And so one of the things is when you're not managing unmanaged open source is exposing you to sort of escalating security and license threats. Uh, supply chain threats and managing this stuff at scale is really challenging.

Uh, you know, it's one thing to know I've got a vulnerability in this package, right? I've got, you know, my, my s e's tool is telling me, oh, yeah, you've got a vulnerability in this package. You need to update that.

But it's another thing to actually successfully update that dependency, all of its dependencies. So everything, all of its transitive dependencies. And to ensure, like the providence of all of that stuff that you're ingesting, you know, dependency hell is a real thing that can really consume a lot of developer time.

And knowing whether that is a breaking change or not, how safe is it for me to update that? It's really, really challenging. And so just that, uh, that element alone is really, really simple.

I'll just say that one again there. Just managing, bringing in the updates alone is really, really challenging. And then we move over to observability where I can even understand what I'm using in the first place, right?

I'm a large organization, I'm running thousands of pieces of open source software. Is that cataloged? Is it versioned, auditable, reproducible?

Where is it running? Who's running it? All of that is super challenging.

And if you don't have systems in place, it can be very, very painful. And then on the other end of things, if you're trying to comply with, uh, government regulations or security audits, do you have tools in place there to actually develop and deliver the, uh, artifacts that you need to support the security guarantees that you're giving, right? Can you produce the documentation, the chain of custody information to be and be able to verify that and supply it when needed?

All of this stuff is really, really complex, uh, and it's very, very rarely, uh, an end-to-end solution. And so it's really, you know, it's no, no wonder that there's a lot of shortcuts that are being taken and, uh, people are shipping with known vulnerabilities or they're doing a lot of ad hoc things. And that's really what we see is that people are really stitching point solutions together.

Uh, they're, they're maintaining spreadsheets. They're, uh, running an ad hoc report. Uh, they're doing, you know, audits on demand, very reactionary, uh, you know, they've got solutions that are kind of diffused throughout the organization department.

There's no standardization. Um, you're managing all these different, uh, upstreams, right? You've got source code, you've got vulnerability DA databases, you've got vulnerability scanning tools, you've got container registries, you've got licenses, you've got SBOs, you've got all these different tools, all these different processes for each one individually, and they're probably largely duct taped together.

They're not brought together in a coherent, cohesive way, and they're really only partially addressing the solution, right? They're not seamlessly stitched together. So one of the things that we've seen over the years is that you really do need to think about this holistically, especially when you're thinking about supply chain security.

And so what we're doing at active state, and what we're sort of talking about today is like, what's, how do you tame that complexity of all of this stuff? How do I deal with all of those stages across my software development lifecycle in a way, uh, that is systematic and reproducible and auditable and understandable and also low friction for those inside my organization? So what we're doing at ActiveState here is sort of bringing our, our, you know, decades of experience with os open source management to bear and to provide a kind of holistic solution.

And so let me sort of walk you through what that looks like here from the discovery of everything that's running inside your org, right down to the deployment. And so we saw before there's an open source ecosystem and maybe your even your own private ecosystem, and there's a lot of information that's out there that you're pulling from all these different sources, and you also have a lot of open source that's running inside your organization. So the first stage is really about discovering that, right?

It's about discovering and cataloging all the open source that's running inside your organization. So discovering it from various sources, uh, knowing who's running it and where having a kind of auditable inventory, we'll see that this, this notion of having an auditable inventory is really important. Um, you know, having a spreadsheet of all the open source that's running, probably not gonna cut it, right?

Having a diffused set of requirements that TXT files or for whatever language you have diffused across your source code re repository, also probably not going to cut it. You can't do any kind of sophisticated reporting against that kind of thing. And so then we move on.

Once you've discovered, once you even know you can't even begin to manage what you're doing, if you don't know what you're running, then we can move on to the analysis stage where we can gain insights into the risk profile and generate some reports and share that intelligence across the organization, right? When you have, you know, uh, DevSecOps, uh, scenario where you've got collaboration happening between development and security and, uh, DevOps professionals, you need to have, uh, ways to share information across that organization and to collaborate effectively. And so the first thing you need is analysis of all that stuff that's running.

So you need license and vulnerability reports. You need, what's the impact of taking this upgrade, right? Do it, does it have a breaking change in it?

Do I have all of the, uh, supporting artifacts that we talked about from the compliance standpoint, you know, in terms of SBOs, attestations, all that stuff. But then once you have the analysis, okay, now we have to take an action, right? We need to do something about it.

We have to remediate the issue, or we need to get it deployed, or whatever. And so then you need to have tools in place to be able to scale that across your organization. So, uh, once I, once I'm taking the action to remediate something, I need to know, first of all, do I need to remediate that?

Does it, does it hit the threshold that we have to remediate? And do I have tools in place? So whether that's policies to be able to say, um, we don't, we don't want, uh, any vulnerabilities inside our organization that are, uh, you know, higher than a high, we don't want any criticals or highs inside.

But then do you have the ability to scale that across all of those upstream sources, right? So we start to think about having a curated immutable catalog where instead of drawing from all of these various, you know, unsecured, unmonitored, uh, you know, public sources, that we can have our own curated catalog where we have control over what's in there, and we also have the ability to, you know, enforce that across our organization. And then finally, okay, great, I'm gonna download, I need a new version of my package and I need to go from version one to version two, but does it build, does it work with all of the other, uh, dependencies inside my, uh, inside my project or, uh, you know, in my deployment?

And so what we've done is we've had, you know, two decades of experience building open source, and we have, you know, a very powerful, uh, build cluster where we can build things in hermetically sealed containers with guaranteed provenance. Everything is built from source, and we can integrate with your systems to be able to, uh, deploy, um, in whatever scenario you have, uh, whether it's a container or whether it's just a, a simple application and getting that into your organization. And so then we get back to the beginning, and now, instead of discovery, we're talking about monitoring on an ongoing basis, knowing what's running inside your organization and being able to keep up up with that, whether there are changes, whether you need to, you know, emerging vulnerabilities, I need to remediate that, get it redeployed, rinse, and repeat across the cycle.

And so this sort of holistic end to end where right from the discovery, right from the source code all the way through the intermediate artifacts in the building, that kind of holistic end to end is really, uh, key to, uh, sort of taming that complexity and to having something that is a reproducible, uh, simple, understandable collaborative system, uh, across your organization. And so, when really what we're talking about is various set of different use cases where we're talking about, you know, the idea of continuous open source integration, how, how quickly can I get new versions deployed within my, uh, organization? How quickly can I get new versions ingested into my pipeline?

How can I ensure that my different environments are consistent and reproducible across my entire organization? Do I have the tools in place for effective governance so that everybody's pulling from the same catalog, everybody's pulling from the same set of trusted artifacts? Do I have insights into all of the usage across my organization?

Do I have insight into all of the places where things are deployed? Do I have the tools to be meet regulatory compliance, right? Do I have those, you know, the, those SBOs, those attestations, those type of things?

And do I have, uh, support for things that are going beyond the community supported end of life? So if I need something, uh, supported beyond that, do I have a a catalog that supports that kind of thing? And then we're gonna kind of jump into that, uh, today and sort of show you what that might look like actually in practice.

You know, I showed you the little diagram here. I talked a little bit about the process, but let's talk about what that actually seems like in practice. So I'm gonna jump over here.

Let's say that we have a, a little environment where, uh, we wanna discover everything that's running inside our organization. We, it's gonna live in a lot of different places, right? It might be in a Kubernetes cluster, right?

It might be just in GitHub, basically, oh, we've got all of our, our requirements files and, and, uh, dependency manifest files across various projects. In GitHub, it might be, we might already have a bunch of SBOs and we don't know really what to do with them, but they can be a very valuable, uh, tool for understanding what's running inside your organization. So we can get directly from our requirements file or an SBO from GitHub from, you know, helm or Kubernetes.

And so let's say, we're just gonna say Kubernetes here today. So we're gonna scan our Kubernetes cluster, and here we discovered that we've got a number of sort of community images that are running here. We've got Postgres and Gin X and Spark and elastic search.

And, but what's inside of those things, right? It's one thing to know, okay, yeah, I'm running Postgres, but what, you know, what's actually inside that? And so our tool can analyze these dependencies and vulnerabilities and give us information and intelligence right down to the system level.

Like you really need to understand, it's one thing to know that, uh, you know, I'm running TensorFlow, but there's a whole bunch of C libraries that underpin that, and that's where you sort of, that's where a lot of the vulnerabilities that tend to be is in languages like c in those type of, uh, libraries. And so what we've got here is we've got an immediate analysis where we can get that information at a glance. So, you know, across my little, uh, pretend organization here, uh, I've got six docker images running, and 47% of that is C code.

There's 1,099 CC dependencies running there. I've got a bunch of Java, some go, some Python in there. It's giving me a vulnerability profile that's showing me, uh, here's, I've got 14 criticals 136 highs.

I've got a profile of the different licenses. So at a glance for my organization, I can see what my risk profile looks like, and I can do things like download a CBE report or download an sbo. But the key thing here is that I've discovered at an early stage what open source is running and what its composition is, and, uh, you know, sort of what my risk profile is here.

And I can see some more details on those things, but we sort of covered those first two boxes. We've got a thing where we've discovered, so now we have that, and we've also, you know, pre presumably got something in place now where we can monitor this on an ongoing basis. But then we've also got some analysis here where initially we can see what our composition is.

Okay, well, we've got a lot of vulnerabilities, how do we upgrade that, right? I go from, you know, 1500, um, vulnerabilities to something that's, that's less, right? And so what we can do is generate something, uh, a remediation plan, right?

We can get, we have a lot of information in our catalog, right? We're, we're going out there and we are ingesting a lot of these public ecosystems. We're pulling in all of pi pi, we're pulling in, uh, all of, uh, you know, uh, the pearl ecosystem.

We're pulling in all of the Java ecosystem, et cetera, et cetera. And we have all of this information around versions. And so we can say immediately here, you know, what, before you had 150, after you're gonna have 188, here's what you can do.

We can also give you some additional intelligence, uh, around the risk profile here. But, uh, essentially what, what we can do is show you that we can remediate all these things. They're relatively, uh, low risk right now.

And so then what we're going to do is we're gonna take those things and we're gonna import them into our platform and manage them as projects. So each one of those containers that we saw before now becomes a project on our platform where now I have a, a contained unit where what I can do is manage that over time. I can configure that over time.

I can see the auditable history of that. So let's say, let's pop over here and see what that actually looks like. So this is a, a little demonstration organization I have here where I've got, uh, five projects, 468 dependencies, mostly go and Java here, and a number of vulnerabilities.

But each one of these things represents either a container that's running in my, uh, cluster, my Kubernetes cluster, like we saw, or maybe just a basic, uh, or project that I created. So in this case, like, um, a basic Python project. And what I can do is I can manage the dependencies individually in those things.

I can also browse them at organization level. So, you know what, if I'm sitting there and I'm in my a an organization, I'm like, I hear about some critical vulnerability. Do you have a index of all the open source that's running inside your organization that you can very quickly, uh, you know, inquire and say, am I exposed to this?

So let's say we hear about something log four J and we type that in here right now across my entire organization, I can type that in and immediately see that, well actually I have this thing log four j append that's running in one of my containers here. It's running in this Kafka test container. And so maybe I should go and investigate that, right?

And I can drill into that exact project and see the details. Um, and that project will then I'll, I'll be able to configure that. I can also see the vulnerabilities across my entire organization, and then I can go in here to my project and configure it.

So let's go like a really simple example, uh, with the, uh, Python, and let's take a look at what that, how that actually manifests. So let me just quickly turn that off. And, um, what you see here is, here's this, the packages that are in my project.

So in this case, I've got a very simple web application, say flask and pillow. And this is sort of maybe running out there on my cluster somewhere, but I've seen here that I've got vulnerabilities, I've got a critical vulnerability here. I've, uh, four highs and I'm getting in.

I, I, so I'm inspecting what, you know, what the problem is here. I've got a couple highs here in the Python version as well. I can see my, all of my dependencies all the way down here to the system level.

I can see, you know, not just that, you know, flask brings in blinker and click and flick corn, it's dangerous and stuff like that. I can scroll down here and see right down 11 LZMA and the system level C libraries. So I've got sort of unprecedented visibility right down to the deepest level.

But then I can go and I can remediate these things very simply. I can say, here's what one is not vulnerable. I'm on Python nine, uh, pillow nine 10 while I'm at one critical four highs, I need to pick one that doesn't have a vulnerability.

Because we are ingesting all of this open source into our catalog. We're building it all from source. You've got a trusted upstream for essentially all of the, you know, open internet.

So rather than going into a situation where you are, um, managing 50 different upstreams, you can say, well, I'm just gonna point to, uh, active state's trust catalog for everything. And I can choose that version though from our catalog where we know that that doesn't have any vulnerabilities. So we're gonna say fixing vulnerability here, and then we're gonna save those changes.

And now that's been changed to, uh, to the non vulnerable version. It's gonna resol and re-figure out all of the things that are in there. But one thing that's interesting that is a critical piece of the puzzle here in terms of taming the complexity of your open source is the idea of that change management auditable history that you saw me do.

So I logged the change. So here, rather than me just editing a text file and committing that, or you know, just installing it on my developer laptop or something, what we've done here is kind of merge the concept of source control with dependency management. Where I've got the, you can see here, here's my base project that I created.

4. And you can see that at any point I can go back in history and revert to this commit, I can generate an bomb at any point in history. So I have a fully auditable chain of custody here where I can see that, you know, Pete made this on October 24th at this exact time.

Here's the commit id. It's fully reproducible. And unlike you can see here that we also have this catalog revision id.

And unlike the sort of public repositories where if I run, you know, NPM install on a Friday and I run N-N-P-M-N-P-M install on a Monday, I'm gonna get a different result. But what we are doing is we are revisioning the catalog every point in time, so it's fully reproducible. So not only, uh, is this saving the state of your dependencies at any point in time and all the open source that you're using, it's also saving the state of the world at that time so that you are fully reproducible, fully auditable from end to end.

The other piece that you can see is that what it's doing is it's kicked off a build into in our cluster where it will be building this, uh, from source, these individual packages. 4, it'll be building that from the source in our cluster here. And so you can see as well, our critical went away over here on our total vulnerabilities and it's rebuilding on Macs here.

Those things get rebuilt completely in, uh, uh, in hermetically sealed containers and completely, um, in a completely reproducible way. You can get SBOs for all of those things. If I go to my overview here, I can see I can generate things like an SBO for this.

I can download a vulnerability report, I can do collaboration. But the key thing is that what we're doing is we're taking stuff from the beginning where we're discovering all the open source that's running in our organization. We're then doing some basic analysis on it to give you sort of, uh, the breakdown of the inventory, whether it's go or Java or C or Python.

We're giving you the high level rollup across your entire organization of all the vulnerabilities. So you have that initial analysis stage, then we're giving you the tools to be able to curate those things and manage a catalog, have a fully auditable history to give you the sort of, uh, governance tools that you need to be able to curate that. And then the tools to be able to build, deploy, and redeploy that.

And so I think that that key cycle there where you have end to end control and visibility on everything that you do, whether it is, um, just discovering what's going on in your organization, all the open source that you're using, cataloging that in an auditable database, then being able to do analysis, collaborate with across your organization, across your, uh, development team, your ops team, your security team, to be able to then curate that, upgrade it seamlessly remediate as we just saw, and then build and deploy that, whether it's integrating with your CICD to get deployed it out, out to your, uh, cluster or whether it's just on your developer laptop, to be able to keep working and streamline that development process. Having a system that streamlines that entire process holistically end to end is, uh, really important. And that's sort of our vision for how, uh, we should be sort of simplifying and streamlining and tame taming the complexity of managing open source, because it's really complicated, it's very complex.

There's a lot of moving parts, a lot of information as we saw shifting landscape as well. And accuracy has been really focused on taming that complexity. So I want to, uh, call it there and say, you know, thanks for coming to check this out and uh, if you have any questions, just let us know.

And, uh, thanks very much.