Modern software systems are frequently described as “complicated,” but that framing obscures the nature of the challenge. Complicated systems can be decomposed, reasoned about, and managed through clearer processes and better tooling. Complex systems cannot. They are shaped by a web of technical interdependencies, incentives, institutional history, and human behavior, and they often fail in ways that are difficult or impossible to predict.

In this RedMonk Conversation, Rachel Stephens and guests David Pollak, Chris Petrilli, and Æva Black explore how complexity emerges across large organizations, open source ecosystems, and security-critical infrastructure. Drawing on experiences from enterprise environments and open source communities, the discussion examines why transparency, incentive structures, and institutional knowledge matter more than formal process, and why many attempts to control complexity instead amplify it.

This is a RedMonk video, sponsored by Spice Labs.

Links

David Pollak
Chris Petrilli
Æva Black

Transcript

**Rachel Stephens**
Hello everyone, welcome to RedMonk Conversations. My name is Rachel Stephens. I’m the research director with RedMonk and with me today I have just a pantheon of esteemed guests. I’m so excited. We are going to be talking with this group about the challenges of complexity and why this ends up being an intractable problem for most of our organizations. With me today I have David Pollok, the CEO of Spice Labs. I have Chris Petrilli, a distinguished security architect at a Fortune 100 financial company. And I have Æva Black, a distinguished technical advisor at Nullpoint Studio.

Okay, let’s dive in. David actually proposed this podcast and recruited people to come talk. I’m so excited. David, what made you want to talk about this?

**David Pollak**
Complexity is this background chronic pain that we really don’t talk about. We design our solutions for individuals and don’t think about the complexity of the rollout. Today’s before we got here is a good example. Chris upgraded to a new version of an operating system and all of a sudden things didn’t work as expected.

**Rachel Stephens**
Yeah, cascading failures across interconnected systems is rough.

**David Pollak**
Yeah. that I think sums it up so well because we do have these cascading failures and nobody knows and people go with their guts and you know, then doorbells stop working when a data center across an ocean has a bad DNS entry. You know, it’s like all of this complexity is just, I think, becoming untenable or maybe it already is untenable. So that was the interest for me. And I know, you know, Chris and I were talking about it at Monktoberfest. I think it underlies a lot of the work that Æva started with OmniBOR, which is how do you start using math to deal with complexity?

**Rachel Stephens**
Chris, can you tell us just a little bit about what you’re working on, what brings you here today, and what gets you excited?

**Chris Petrilli**
Yeah.

My career has really been tackling a lot of complexity across the last 15, 20 years. and it turns out that complexity shows up in a bunch of ways, right? It shows up as what people will typically think of as, I need to manage 10,000, 50,000, 500,000 servers. I need to scale up to terabits of traffic. need to handle, millions of transactions per second.

But in my current role, I’m dealing with an organization that is generations old, the tech industry likes to think of everything as very new and very shiny. And, you know, our first tech came in in the 1960s, in the very early 1960s. We still run mainframes. We still run kind of batch processing models, and we run 2000 microservices. And those are all interdependent. And you have the complexity of organizational challenges, right? We are very lucky to have staff that have been here for 15, 20, 25 years. And that means when they leave, that is an enormous amount of institutional knowledge about all the interdependencies and all of the complexity that’s accumulated over the last decades. So it’s a fun challenge, but I think it’s also one that a lot of companies are struggling with.

**Rachel Stephens**
Absolutely. And Æva, can you tell us, so definitely I want to hear more about OmniBOR, but tell us what you’re working on and how you are getting through your days.

**Æva Black**
Yeah.

I started down the sort of journey of building more and more complex systems a long time ago, just before the recording started, we’re talking about like early days of databases and open source. For me, that was MySQL and scaling it from 10 to hundreds of servers and then OpenStack and scaling to tens of thousands. then more recently, just before I met David and what led to work on OmniBOR, trying to look at how do we understand cybersecurity through the lens of the open source ecosystem, sort of community of communities that we’ve built that now underpin basically the entire planetary digital systems. And when Log4Shell happened, when XZ Utils happened and the growing litany of these incidents really well summed up by the the xkcd comic of one developer in Nebraska maintaining a little tiny block, we all love to point to that because it’s such a relatable And so incredibly common situation. There are thousands upon thousands of those tiny little building blocks Whether it’s DNS in one data center that knocks out a doorbell Or one developer getting upset and just deleting their code because they don’t want to deal with the drama on the internet Leading to a hospital going offline.

The interdependencies here are mind bogglingly complex. I don’t think any human can. And so the struggle to understand how do we model, how do we display, how do we make actionable insights from this mess of information?

With OmniBOR trying to map out a software bill of materials for a large open source project. It’s huge. Hundreds of megabytes of text.

And if you just look at the mathematical relationships, not all the metadata, it’s a hundredth, maybe a thousandth of the size and much easier to store, transmit and model.

**Rachel Stephens**
Love it. All so if I’m trying to parse through some of the ways that we make the system complex based off of what everyone mentioned so far, it’s scale makes things complex, interconnected and disparate systems, socio-technical issues, having a large history that you have to take into account and not being able to work on Greenfield projects all the time, security issues, dependency management. I don’t know if I got all of them, but there’s a lot of different elements of complexity.

One of the things that came up in advance of this call was complex versus complicated. Does anyone want to dive into how you think about that?

**David Pollak**
At least for me, complicated systems have layers, complex systems don’t, or the layers are blurred. So it’s the intertwining and sometimes the invisible intertwining that is the difference between complexity and complicated.

**Rachel Stephens**
So it’s like the ability to reason about the systems. that fair?

**David Pollak**
Yeah.

Yeah.

**Æva Black**
Yeah.

**Chris Petrilli**
And I think to talk a tiny bit about that, I think with complicated systems, we have rules, we have patterns, we have recipes, we can clearly articulate the constraints that they’re operating within. But when we talk about complex things, they don’t have those clear boundaries on them, right? They don’t have a way to clearly articulate the constraints that we’re operating within.

They’re often operating in new and unexpected ways. And to Æva’s point, a lot of that is combinatorial complexity, right? A lot of it is the fact that, now you’ve got a thousand dependencies or 2000 dependencies.

You know, I think about some of the jokes that we make about like Node.js applications, for example, you you pull in 500 dependencies that each pull in another 50 dependencies that each pull in another 20, right?

How do you reason about something like that? And I think, especially when we start to talk about the impedance mismatch that happens with what I’ll call corporate world and open source world, right? There is this complexity around what we call supply chain, I can clearly talk about a supply chain when I buy something from Oracle or Broadcom, What does a supply chain actually mean when it’s just some software I got off the internet that’s managed by some nice person in their spare time?

And while we like to talk about all of these huge projects in the Kubernetes and the Apaches of the world, That have huge amounts of funding behind them. It’s actually those other things, those other little libraries and dependencies that you’ve built up that are really hard to reason about, And we just take them on without thinking,

**Æva Black**
Kubernetes has a huge budget behind it at the LF and the companies that run it. And Apache is one of, if not the oldest sort of independent open source nonprofit foundation, but they have such a small budget. That’s the sort of comparison between the two is challenging. They’re both really large and widely deployed and depended on for critical infrastructure, but one has no real infrastructure budget.

**Rachel Stephens**
Let’s dive into open source and how they manage complexity because I think there’s a lot that we can learn organizationally from how open source operates. as you’re saying, Æva, it’s not always that they are incredibly well funded or that they are all that their projects have varying scopes and sizes. what can we take away from open source as we’re thinking about how to manage organizational complexity?

**Æva Black**
My go-to is to ask for transparency or suggest we should increase transparency where we can because transparency helps us at least understand the complexity and in some cases turn a complex system into a complicated system. If you can’t see it, of course its behavior is unpredictable.

**David Pollak**
So my take on some of the Linux distros is they are in fact complicated but not complex. The amount of coordination across the open source projects in each of the distros strikes me as relatively small compared to, for example, when I was at Cisco, the coordination across product lines. And, you know.

It’s like, okay, what are we interoperating with? What are we making commitments to our customers about? And open source seems to have a lot less of that and is yet successful at cross application data sharing. So there feels like there’s something there, but I don’t quite know what it is.

**Rachel Stephens**
So you’re saying the less formal structure but better coordination regardless.

**David Pollak**
the outcome is better and yes the the outcome is better with less coordination or maybe the the constraints actually drive better communication.

**Chris Petrilli**
I mean, I think one of the things and I think Æva’s right, like I shouldn’t have compared Kubernetes and Apache because obviously there’s a multi-order of magnitude difference in budget. I think about, you know, I’ve been working with the Python Software Foundation for more years than I care to admit. you know, their budget is still tiny and yet they’re the technology underpinning a trillion dollar industry. Right.

If I look at the Python community and it’s had 30 odd years to develop as a community, and then compare that to what I see in kind of the corporate world. I think the thing that, that the open source world often has, especially like the Python, the more mature communities.

They have things like release managers and people who are kind of very transparent and communicating about how the whole process is working. Whereas in the corporate world, I don’t feel like we have that kind of formal structure, even though we often have more rigid SDLCs, right? Software development life cycles. We don’t actually have the kind of transparency in release management, what’s changing, what’s coming, what’s being deprecated, what’s being added. What do need to be aware of? we’re going to deprecate this in three releases. So, you know, I have yet to see a corporate environment that operates with that level of, of maturity.

And I think to Æva’s point, like that visibility h elps reduce a lot of the complexity and turn it into just a complicated problem.

Now all of a sudden I understand what’s coming down in six months a year, even maybe two years down the road. And I’m not to say that the entire open source world does that, but there are definitely a lot more of those in the open source world, I think than there are actually in the corporate world.

**Rachel Stephens**
It feels like what you’re saying is corporate world has conflated rigidity with structure, but the kind of structure that we actually need is processes that increase transparency, not that increase hierarchy. Is that fair?

**Chris Petrilli**
Absolutely. I think, you know, if we talk about communication and I think for a lot of companies, the pandemic was a wake-up call about how they communicate, but it’s still, a lot of that communication has no artifact. It has no visibility, has no place to be understood, right? If you look at whether it’s the kernel mailing list for Linux or, the Postgres core teams mailing list or Python dev or like everything’s there, Like it is out open, visible. Sometimes it’s dirty laundry, But it’s knowable. And I think that’s one of the biggest differences between complicated and complex is that complex always feels unknowable at some level.

**David Pollak**
One of the things that struck me while you were talking, Chris, is also the career incentives in big companies versus the incentives in open source. Because if your career is advanced by hoarding information, then that’s the behavior you’re going to engage in.

That increases transaction costs, but there’s also probably a bias towards complexing things, making things complicated so particular projects can’t be stopped. Once there’s budget for this, you’ll never un-budget it because it’s absolutely necessary.

**Æva Black**
I mean, it’s certain companies are well known for having rewarded complexity in their internal design processes. As an example of how to not build long-term scalable maintainable systems. And open source tends to, not always, but the social conditions of it and what we…

sort of ascribe maturity and longevity to our projects, which can be maintained by someone other than their founder.

**Chris Petrilli**
Well, I think to Æva’s point, I two things I’ve said so many times, you hire PhDs, you get PhD problems. That’s not to say that a PhD isn’t an enormously valuable education, but you have to be careful if that’s the perspective that you actually need to solve a problem or not. And I do remember the first time I made staff engineer at a tech company. It was made very clear that like,

The only way you make staff engineer is by shipping a new thing, By creating complexity, basically. And we don’t recognize the I would say gardening, the weeding that’s necessary to turn complexity into complication, to start to actually define it and make it knowable. It’s absolutely critical, but at least in the corporate world, it’s not typically rewarded. You get the promotion, you get the bonus because you ship the new thing, not because

I made everything more manageable, more understandable, more predictable.

And I think it’s because we know how to quantify or think about the new thing, the, you know, a new system, a new service, a new product, whatever that is. But we don’t really know how to think about quantifying all of that other work. Right.

**Æva Black**
If it’s okay, I’d like to pivot a little bit towards security. So what you’re talking about is kind of a corollary to Conway’s law. You ship your org chart, you get what you measure, what you’re incentivizing. And so if you’re incentivizing and rewarding complexity, you get more complex systems. And if your organization rewards those who build complexity, you’re going to get products that become a complexed over time.

Whereas, if you build a social system for maintaining software that incentivizes secure defaults, easy to use, maintainable outcomes, then you would get those. And I think that’s a divide we have between corporate culture that rewards fast to market, new product features, and disincentivizes secure by default, which takes longer, that disincentivizes maintaining products that have been on the market for five years.

And gosh, imagine if we had those. Imagine if we had a world where the economic incentives aligned with creating products that people could rely on, that were stable and maintainable, and where people could, maybe without a PhD, maybe they didn’t have to, but if they had the ability to get in there and fix it themselves.

which is kind of describing open source.

**David Pollak**
So Michael Nygaard wrote a series of blog pieces, he was in the Clojure community, about how software should be carried as debt rather than assets on balance sheets. And the size of the debt or the debit on the balance sheet should increase each time a line of code is not changed.

His assertion was that will create an incentive to reduce the number of lines of code and have fluid systems, which, you know, that flows down to having people who understand the systems and having incentives to keep the people who understand the systems around. And Chris, I think this goes back to your earlier point about your current employer having people who’ve been there for 15, 20 years who know the systems.

**Chris Petrilli**
But I think the question then becomes, do you, well, one, how do you transfer that knowledge? Right? It’s almost generational transfers, right? But I do think that Michael was onto something around, everything you ship is legacy, we in the industry like to talk about legacy systems, but that’s everything that’s running in your data center. That’s all legacy stuff, right?

Some of it has a longer legacy. Some of it has a more sordid legacy, but it’s all legacy, right? It’s all friction that keeps you from moving, And I think to Æva’s point around security, know, the drum I’ve tried to beat for the last more years than I care to admit is that simplicity and velocity are your two most important capabilities or measures.

from a security perspective, simple systems tend to fail in more predictable ways.

So building a system is as simple as you can possibly achieve, and being able to change it quickly, which I think is, is related, whether we’re talking about, for example, you the constant vulnerabilities that come out every single second of every single day, your ability to fix something, Whether it’s a user experience bug or a security bug, right?

And when you run into teams, for example, that I’ve seen in various companies where like they’re terrified to make changes, It’s almost fear-driven development, Because they’re not confident in their systems, they don’t really understand them. they’re very complex. They don’t have good test suites. you know, all of these things contribute to lack of confidence in making those changes. But from a security perspective, That’s how all that stuff just kind of accumulates as cruft that eventually will be compromised.

**David Pollak**
And it’s kind of frightening that the adversaries know more about our systems than we do.

**Chris Petrilli**
I mean, I remember the joke at several places like, I hope they at least leave us a decent inventory. Like, and I, you know, at my last employer, which was a kind of FinTech company, you know, one of the things we actually realized was our inventory system wasn’t linked up in a way that made sure that you had a feedback loop. At my current employer, we still have an individual listed as responsible for hundreds of systems that hasn’t worked there in two years. And we all just kind of laugh about it.

And I’m not calling out my employer. mean, this has been everywhere I’ve ever worked, has had this problem with inventory changing that perspective so that has to be kept correct, I think is really important. And that is part of the complexity problem. Who even owns a system? Who do I even talk to? Where do I even start? And all of that contributes to the inability to comprehend and understand a system and define its boundaries.

**David Pollak**
I think that’s also amplified by AWS Lambdas and other systems that may run for seconds or minutes. It’s not something where the service now in a configuration management database, great, you’ve got a company like Cisco with 70,000 employees and probably two, three, 400,000 assets. You can put that in a relational database.

But how do you have all of the software dependencies for every AWS Lambda that you ran last week? How can you like even capture that with what we have? And yet those inventories are critical to know about software vulnerabilities, to know about what to remediate, to know about just how to keep version and crypto agile so that things can just be updated when they need to be.

**Chris Petrilli**
Well, and I think also understanding like, are your strategic dependencies? Right? Like, sure. The average company can think about, Microsoft, Oracle, whatever, but are they really thinking about Spring? Are they thinking about Python? Are they thinking about MySQL, Postgres? And in many cases, they’re not thinking of these as strategic dependencies that they have. And that means nobody’s stewarding that ecosystem through the company, Trying to get you know, for example, at my employer trying to get us involved in the open source community of tools that we, we have as our lifeblood, right? We absolutely need Postgres to be up, running stable. We need to understand the future of it.

And so I think there is a need to engage with that in a healthy way.

**Æva Black**
And what you’re pointing at is incentives at the business management that are fundamentally misaligned because they have assumed a degree of continuity in something they are not influencing to ensure that business continuity. And I think the framing of something like Kubernetes or Linux as critical infrastructure component or Postgres or Spring also belies the complexity of those systems in turn, because, well, a Linux distro has a couple thousand packages in it. And those in turn have lots of dependencies.

And I looked at the numbers for Debian recently. It’s great. They make tons of these available. It’s easy to go look at the complexity of Debian. the average release is, I think, about two billion lines of code. If you trace all the dependencies back for the packages in them, you add it all up, it’s billions of lines of code. And if your company web services all run on a Debian image, maybe it’s customized down to a tiny little cloud image, it runs a lambda, who knows? How can you say that those two billion lines of code aren’t critical path? And which ones aren’t? If you haven’t done the math, if someone isn’t doing that maintenance. And think this is where industry has become so comfortable in externalizing this risk and assuming that it will just be there tomorrow. And as the world changes and things become more complicated, both technologically and politically and economically, those assumptions are being tested every day.

**Rachel Stephens**
I think now is our time for CRA, If we’re talking about changing of incentives, especially as we’re thinking about the components that make up our software stacks, I think the way that CRA is going to impact all of this is going to be huge.

And also I think it’s going to be extraordinarily complex for people to try to get their hands around what this all means. What are you seeing as you work on this?

**Æva Black**
In a nutshell, the CRA attaches to every company who’s putting a product with digital elements on the market in Europe. It attaches to that product a regulatory requirement to put security first, to think about and manage these risks, to track and be aware of, respond to vulnerabilities, respond to active threats and incidents, and participate in ensuring that the customers who are using or depending on that product are safe.

It’s one of the biggest levers that governments have is funding something. The NSF in America, the other big lever they have is punishing something, applying a fine. And the CRA has some pretty massive potential fines for companies that, however they’re gonna enforce it, I don’t know.

But the potential fines are, I think, about 2 % of global revenue, which is a lot for companies. And it can be applied not just to the company, but to some of the directors in certain circumstances. I’m not going to try to interpret the law, but it gets some real teeth going. And their thinking seems to be it’ll motivate companies to take it a little bit seriously, whereas all of the CISA Secure by Design initiative. I contributed a bunch to that, I think it was great work. It inspired a lot of action, but it had no teeth behind it.

**Rachel Stephens**
Interesting and it’s definitely something we are watching closely because we think the ramifications are going to be large. So we’ve talked about wanting to have simple systems. We want to have incentives aligned. How do we actually accomplish it? Are there ways that people have found to build this transparency and or to try to shift some of this complexity culture in their own organizations? Are there things that we could do?

**Æva Black**
I’ll point at the elephant of SBOMs SBOMs were an attempt to require transparency in the past, what is it now, five years and change. it’s still a struggle to get organizations to share more than a single layer of dependencies.

**David Pollak**
I find it very interesting that we use Git to manage our source code. mean, almost every large organization is using Git. And everything in Git is all about the mathematical description of a particular release of a particular collection of files and not having that as part of the SBOM spec.

And, know, that once again, this goes back to the work in OmniBOR, being able to have these intrinsic identifiers that people can measure their systems, not just did my build system tell me something, but go and measure what’s actually there. I think that is a big part of what we need to be able to do to at least inventory our systems and start.

Searching through them to be able to find commonalities, it’s what we do with antivirus, what we’ve been doing with antivirus for over 30 years, which is antivirus is a catalog of known bad hashes that are then compared to the files on a system. But why not just keep the ongoing hashes of all the files in the system?

And, know, I’m sorry, I’m moving slightly into sales pitch mode for Spice Labs, but part of the complexity is having the right model for being able to measure and store and query. And when you don’t have the right model, and I would argue that SBOMs are not the right model, If they’ve been the right model. know, it, Log4shell would have been a nothing burger.

**Æva Black**3
SBOMs are built on the same model as what we used to label punch card decks 60 years ago. I’ve found pictures of old punch card decks that have written on them like hand notes, author, version, the same way we label an SBOM, the minimum elements, is the same way we labeled software when it was a stack of cards.

We know better. We have machine readable, automatable, scalable means to do this. We need to move past a handwritten human-assigned name for something which is changed at every step of the supply chain. If I write some open source code and Chris downloads it and makes a change and then David puts it in a product or whatever, it’s changed at each step of the way. Git lets us track that cryptographically. Why would we use the same SBOM or the same terms of, you know, name version and author?

**Chris Petrilli**
So one question I want to ask both of you is I’m going to stick my my architect hat on for a second and that is

When we talk, we’ve been talking about SBOMs and dependencies and

All of that applies to a single unit, whatever that that’s a service, an application, et cetera. How do you think about that as it expands out to talk about, you know, I’ll give you an example. Like we have one application that is dependent on 85 other applications that each are made up of potentially dozens, if not hundreds of microservices. And, you know, one of my charters is all of our ransomware and disaster recovery, right?

How do you recover something if you don’t actually understand all of its dependencies that aren’t even just code dependencies? They’re now API dependencies, whether it’s using tools like Zipkin and OpenTelemetry to visualize a microservice kind of dependency tree, Because I think it’s much better to look at what actually happens rather than what people thought happened. But that’s great within a microservice architecture, but it doesn’t help when you start to have these kind of big macro monolithic services that have never been decomposed and things like that. I’m curious, do you have any thoughts about how do you go and tackle a problem?

**Æva Black**
One of the primary problems that I want OmniBOR to be able to solve for all of us is the needle in the haystack problem, where in all of these systems, combinations of microservices and monoliths, is a known bad file. Let’s imagine that the next Heartbleed comes out and we know there’s a particular a particular file hash of openssl.h
that causes a vulnerability, but it’s compiled in nested layers and layers down underneath anything. And whatever products or services or monoliths you have out there, they’re not gonna say open SSL on the tin, but it’s in there and it’s probably causing a problem. How do you find it?

What led me to work with Ed and David years ago on OmniBOR was building a mechanism to solve that problem at scale, regardless of the organizational complexity of the environment. If you know the hash tree, the artifact dependency graph of each of the services, whether they’re a monolith and you’ve had to go retrofit it because you didn’t even have the original source code, but you can do some ⁓ decompilation and get kind of close, or it’s a microservice that you compiled on the fly yesterday.

If you have the hash tree for all of those, then you could do a very quick hash lookup. Is this hash of a known bad file that’s now published in some vulnerability database globally present anywhere across my diverse architecture? And if it is, flag those systems to your DFIR team or your incident response team immediately to let them go triage it. I think this gives a much better signal to noise ratio for the defense teams when there’s the next zero day, the next major incident like Log4Shell Does it solve it? Nothing’s perfect, but it gets us better, it gets us closer than what we have right now. Certainly better than inventorying based only on a manufacturer’s declared product name and version, or their declared top level SBOM. And I think…

And Chris, I’d love to hear, ⁓ as you listen to me talk about this, if you think it would work in the kind of environment you’re describing.

**Chris Petrilli**
I mean, I think it would. David and I have talked about this a little bit as well.

when a zero day or any kind of high impact thing happens is how do I quickly prioritize everything that’s out there?

You’re absolutely correct. mean, it’s especially when you’re talking about these, I don’t know what to call them, but these fundamental libraries like OpenSSL, right, which I always remind people was originally written by somebody who didn’t know how to write C because they wanted to learn how to program, right? That’s how we ended up with that. And it has gone so far away from that in those intervening years, but…

We don’t think about it. It’s the oxygen underneath everything, ⁓ LibXML, right? All of these libraries that people depend on everywhere. And to your point, no vendor tells you what they’re using for their open SSL or for their TLS connections, right?

So figuring out those things very quickly and then figuring out the bigger dependency graph, The dependency graph of data flow within all of these systems starts to illuminate, I think, where you need to start doing triage, As a defender.

That combined with the layering of defenses, you know, I’m, very proud of my old team that when Log4shell happened, that someone got paged and they looked at it and they said, you know what, this is not a problem for us. Like, yes, we’re vulnerable. No, it’s not exploitable. went back to sleep and was able to deal with things in a rational timeline on a normal schedule. Like that should always be our goals as a security team.

Right. Is to create those sort of, ⁓ yeah, you know, that’s interesting. We should deal with that at some point rather than hairs on fire. Everybody’s being paged. Everybody’s schedules get thrown up at the air and it’s just another Tuesday. Right. and I think also understanding that bigger dependency graph starts to help us understand where should we be layering in defenses?

because I think back to the complexity question, often we take on dependencies because we need 2 % of what it does, You took on libXML because you needed to parse a basic XML file, but you didn’t need all the weird includes and everything else that it has built into it. But there’s no way to break it apart in a way that’s useful. And I think thinking of how do we go in and start to break apart some of these dependencies into a way that is able to take on the piece you need without all of the extra complexity that you don’t?

**David Pollak**
There’s also, I think, another piece of that, which is you talked about the call graph and Open Telemetry and Zipkin and that sort of thing. And Æva talked about an artifact dependency graph. Merging those two things, I think, would be very interesting because all of a sudden you can see not just the data flow, but this data flow through components. But the other thing that’s really powerful about the graphs versus just a list of package URLs is you can see the commonalities. So thinking about upgrading a system, all of a sudden you can see the 20 modules rather than the just one that have a particular dependency in them. And that makes scheduling work a lot easier because the team that’s doing the upgrade, and yeah, half the time, upgrades require some code change, even if the API is compatible. Being able to see those commonalities is important on the engineering side. And Chris, as you pointed out, operationally and security-wise, being able to see that, have that information at the tip of a finger and see the call graphs, that allows for the right decisions to be made.

Narrows down the search space so that the search space will fit in somebody’s head rather than being insanely complex where it doesn’t fit in somebody’s head. using graphs rather than relational databases to store this information, think that is going to be a change. And if we can get that change into kind of common use and common parlance, I think people will think about the problems differently because they will be able to see the connections rather than just the list.

**Chris Petrilli**
Well, and I think it’s those connections from a security perspective I think about, right?

One of the most common vulnerabilities that we see in kind of modern microservice architectures is somebody assuming somebody else sanitized the input they’re bidding. well, obviously someone upstream for me has already done this, right?

You know, I’m hoping at some point to return to some of the work that we did at a previous employer around doing kind of distributed data flow analysis, Like, can we actually, for example, do taint analysis across hundreds of microservices, To figure out if they’re actually doing what they think they’re doing, Are they using things in an unsafe way, Because

That’s the root of a lot of these problems, right?

**Æva Black**
How do we get the perspective change, the culture change, on the one hand, necessary to get companies to incentivize the maintenance, the investments needed to achieve the outcomes you’re talking about? Chris, you’re pointing out some patterns I’ve seen in companies for longer than I’d care to admit working in the tech industry. And they haven’t changed, right?

seem from my perspective to be emergent from the economic externalities of how we build companies, how we incentivize the growth from a venture-backed startup to an acquisition or a successful exit, and then being on the stock market or acquisition by PE, all of these incentivize certain behaviors inside how companies manage the teams that build their technology. If we want more secure outcomes and less unnecessary complexity, what do we change?

**Chris Petrilli**
Well, I think we talked earlier about CRA. Obviously, you know, that’s one set of incentives, right? Which is, we’ll call it the stick side of the carrot and the stick.

One of the things that we always struggle to illuminate coming from a security perspective is.

how are we saving the company money? How are we avoiding risk, right? But like, how are we actually reducing workload or reducing, especially rework, right? So, you our team works very hard to try and put out libraries and frameworks and other tools so that other people could do not have to do that work, right? And that’s been well received. I think that figuring out how you build I hate to use the word value proposition, but how you build that kind of operational efficiency proposition. Because, you know, without derailing this conversation into a discussion of AI, much of the appeal is around operational efficiency, right? Whether it achieves it or not is a separate conversation, right? But that is the selling point, right? Is that to this day. Somehow you’re going to be able to compete with faster with less work, with less money, with less. So, if we’re about what you saw from all over America, and you know, especially in the U.S. because of the science and the science of somehow you’re going to be able to do it faster with less work, with less people, with less. So if we’re talking about how do we sell this into corporate America, and I’m going to specifically talk about the U.S. because financial incentives are different in different parts of the world, The U.S. though is very short-term this quarter, maybe this fiscal year focused, right? When we talk about publicly traded companies. But even when you talk about a private company, it’s still that culture bleeds into it. How are we going to reduce spend in other areas, to pay for this kind of work? And as much as I would like to see people do it out of the goodness of their heart, because it’s the right thing to do, because it’s going to make the world a better place, that hasn’t always been the best bet with corporate America, So how do we reach out and offer other parts of the organization time, money, workload savings, right, out of things like this. I think David talked about like, okay, well, if you’re, let’s say you’re, you’re updating libXML from one release to another, hey, maybe we should be looking at all the places we use libXML rather than saying 40 different teams need to go do this, And, potentially have the ability to get some scalability out

**Rachel Stephens**
I feel like that is a wonderful place to close things because I think that we have covered a broad range of things today. This has been absolutely delightful and chatting with all of you. Thank you for giving me your time. And I am looking forward to more conversations because I think we could have branched this off in about a dozen different directions at various points throughout this conversation. So there’s so much more to explore. But thank you so much for talking with me.

**Chris Petrilli**
Thank you, Rachel.

**Æva Black**
Thanks for having us.

**David Pollak**
Thank you.