Software Bill of Material - a Way to Prevent Black Swan Events?

I'm gonna sway this topic a little bit differently and don't ask me about cables. So I don't know anything about cables, by the way. Software bill of material seems not to be logic for ciso, but I have the pleasure to also do emergency management and asset management in our company, which is a notable size operation. So I guess assets now cross the billion mark. We and I had the pleasure to manage lock for Chase. So I have a little bit of a burning platform, which I brought to you. And to BE'S comment, I think we need to address the leadership in the conference a little bit more.

So what I would love to guide you to is how do we create momentum here for some joint activity. So I wanna win you for something you probably can take home where we can create a little bit of a momentum in the community. So let's see if that works. So for some of us, the end of October has an important mark to it because that's when you have to file your IRS filings, right? Tax declaration. So what's the commonality between black swans? What are black swans? We talk about it in a minute. And the tax declaration. What do you think? By the way, who of you filed it on the 31st?

Can I have a hand? Okay, so everybody did it on time, but I admit I did it on the 31st. So very last moment. First of all, if you miss the boat on it, it's gonna cost you because they fine you if you hand it in light, right? They changed it this year, I guess. They continue to tighten this cruise time. It requires bookkeeping. So the first thing is you look for some type of receipt, which has notable size for a tax declaration, you can't find it. That's producing quite a bit of a sweat.

And you wanna do that ahead of the curve because by the time you declare this the last year, you already should have had your bookkeeping in order for the next year, right? Most people forget about that. You need to know where to find things. So having a certain amount of order in your files is quite helpful. And even if you miss stuff, you should have a strategy, how to cope with that, right? We always have missing links. We all have Porwal organizations that don't provide all the data you'd love to have. So it's helpful to find ways around it and still operate from it.

And as usual, no excuses, right? So if you, if push comes to shop and people start asking you and you get some interesting question from your tax department, you should have the right answers. Otherwise things could get quite ugly. So what happens if you miss the boat? I guess we had a few items that you were well aware of, right? Just to give a little bit of a recap over the last eight to nine years, it started with heart bleed in 2014, you had all sorts of things like shell shock blue keep most notably. And from a personal experience, CHE was quite ugly.

And then somebody asked me, Well, we thought this was a, was a chop wall done? Do you think that you're already ahead of the curve?

And oh, we were actually pretty miserable. B host, we had to do a lot of searching. We had to turn everything upside down. Not exactly a pleasant experience.

Actually, I never want to get into the position to do such an operation again. Ideally I could patch on time, then I don't have to worry, right? So to the previous speakers note, I would love to sleep. And then another person said, Could you please make sure those events don't hit us on a Friday night? And I said, Be my guest.

I can try, but no guarantees. So it's all common to them. They're kind of black swans you, you were actually, that's kind of a surprise. We all thought we would be safe, right? But eventually we couldn't rely on software that was provided because we had a couple of issues with that. So most of them were unfortunately vulnerable, which means they create organizational impact almost immediately. So if you go further than that, what do you do for bookkeeping ahead of the curve, right? So the question we have to answer is, what problems do we want to solve?

And the first problem we have is surprises. You don't wanna have surprises. So if you wanna get ahead of a curve, you need to know where things are. And if the shit hits the fan, then you need to know what's important, what's urgent. Otherwise you start digging in the wrong direction, right? With limited resources, I can tell we, we had about 2000 people worrying about luck forche for about two weeks solid, right? That's an enormous impact, right? So just by looking at those people who were already bound for vacation, that's not a nice discussion you have, right?

The second one, we don't know enough, right? We all have these vulnerabilities. There are usually an open source, but they're also in bespoke applications. So stuff you create yourself. So don't assume your dev teams are always top notch, right? There might be also the bell curve. So they're good ones and bad ones. Those teams alone would probably create similar problems you get from open source, right? And it's typically very dynamic. It's widely used because good things get reused very fast, right? But unfortunately, there's no maintenance contract attached to them.

So you can, you can't call anyone to give you a patch. So there has to be someone who has to do it. And then there's more stuff you can pour into the fire, which is like quality flaws in your development cycle, right? Things get brushed over because you need to go production, right? You have to keep a tight timeline. Your business is expecting more, so you skip over some of the tests, right? And then the other part which we will look into is also outsourcing. Not everything I do, I do it myself. I pull it in and I probably don't wet stuff properly before I use it, right?

So when push comes to shelf, where do I start, right? I start at home with my own dev teams, right? So how do I create a dev cycle? Even with DevOps, I can get automation that helps me, but I need to still be diligent. And I think one part of the SI role is to change culture.

Culture, how you go about things. So you need to do think security first, otherwise you're not gonna make it. Same thing for sourcing, right? If you pull stuff in, let's say open source data, open source libraries, you wanna look at that. If you can actually trust it, it's a, is there a risk attached to it you can need to carry? And then even in outsourcing, the whole thing gets complete more complicated because you don't even operate it yourself. So you just run on other people's operation. You have to rely on, So do you do a property due diligence? What libraries they use?

You probably recall in, you have to talk a lot to suppliers, a lot to outsourcing, allow to operators, Can you patch it? Can you make sure that this thing is fixed on time, right? And eventually it expands into your ecosystem.

Yeah, we are not alone, right? You all have suppliers, you have customers, you have partners. So anybody who is in your ecosystem is equally affected. And why do we keep reinventing the ve? Why does everybody do the same things again? And then again and again. So everybody does bookkeeping, but can't we agree on accounting rules? So what software bill of material, Simply speaking, it's a response to people who have got annoyed about black swans, right? They thought we have to do better, We have to do a bookkeeping, we have to have a proper accounting rule set.

And eventually it's a formal machine readable inventory you could use to exchange information about the very detail of data. You need to know when vulnerabilities are critical, right? So you need to know where things are and how deep do I need to dig and why can't I find it? And why do I always need a bespoke scanner that hopefully gives me late minute information?

I mean, eventually you probably benefited from folks like Wallace or other scanner companies who were able to provide a select scan operation for finding a lot forche library. But you could pay anyone, right? And what I want to know, I want to know it before it happens, right? I can't know it before it happens. If I need to use a scanner, then it's too late.

Yeah, the train has left the station already and there's a minimum requirements you can agree upon. It's not something we need to invent the, by the way, the American government has passed a presidential order last year that basically indicated everyone who's participating in a federal contract to provide that very software bill of material. And so we have a list of what's already needed, what's necessary. And the clear thing is you need to build into automation, right? Because there's too many moving parts. You can't do that manually.

And the more you do, the more you pull in from your ecosystem, the more it has to be automated across borders. And then beyond that, there are certainly additional items that usually come with that. And you do already licensing. You have the obligation to figure out where's your stuff, where do you need to pay for? How do you do proper bookkeeping there? Why don't we attach the software details with it? And so eventually what we do about holes, right? So you always have to operate on a lack of information. And so the first thing is you start anyway, right?

You, you deal with the host you have in your database and essentially start setting standards. But this is something, and that's where I come to a common effort. We should all agree on a common standard. There are already standards proposed how I exchange information on the software componentry. And I guess we should widely use that. First of all, we need to learn how to do that. But then we should quickly agree also across an ecosystem, across industries, how to get into a standardized representation of that.

And interestingly, most people you work with already have to do it because most of them already have a a business in the United States. So they are involved in federal contacts. And when you talk to them, they would have to admit, Yes, I have to do this because otherwise I'm not part of that game, right? So that stuff has already started to come into existence.

You, we can leverage that. What we need to do now from let's say a European, or at least a national perspective, you need to leverage it, right? You don't have to invent that wheel again. And so when you think about an ecosystem we already have today, there's a lot of stuff you already used where your dev teams naturally communicate with their sisters and brothers and other organizations and they already have that exchange what's best practice, right? And I could use that as a best practice too. So eventually when I look at it, I need to look holistically, right?

I bring in everything from my supply base and also from my peers. So when we have that discussion in, in the Daks community, we found actually everybody of us has similar issues, right? We already went into the same direction. Why don't we agree on a common effort? So when you think about what are the excuses, well, the thing hasn't happened yet because it's hard. It's not simple, right? You have to do a lot of things to get an idea. How is my software organized? How do I put it in a proper repository? How get the suppliers to provide me with on time information?

How do we interact with the dev teams? How do we automatically update my own registry every time I do a poll request, right? That's a quick question. Now also for cloud, you always have to question how much does a cloud a hyperscaler do for himself? And how much does he provide services you could use for your own operations or build teams, right? It's the shared responsibility model.

Again, they have pre-thought that if you talk to the Amazons and Microsoft of this world, they already have a solution for that, right? Most of them have inventories they provide already for that type of information, you just have to use it, right? So it's usually an incremental step. It's not so difficult, but it has to be, it has to start here, right? You have to kind of train the dev teams to think about it. You have to build it into their tool chain and into the pipeline. And then it actually works from day one. If you do it properly, you have the legacy software, right?

Or you have legacy services, right? They usually can't be audited in terms of code, right? You have no code anymore, right? Find the mainframe system with a full code base rate. But there are things that can approximate. You can still do some binary analysis. There are items that you can do. And then there's usually the topic, there's always a tension between flexibility and uniformity. So you wanna be flexible, which means you do stuff yourself. But having it in a uniform format has great benefits because it becomes interchangeable, right?

So from that perspective, there are already good standards for that. For instance, OSP already has a decent standard that can be used that's in production in many areas. So you can take care of that. And the one thing we probably have to think about, right? What already happened in the states, right? They started a X vulnerability exchange or exploitability exchange. So where all you could say, it's almost like where we have a collection of vulnerabilities in the market, but with the more a reputation than just having CVE numbers, right?

It's not just looking up what's the CVS S score of certain problem, but I want to know the bill of material that is behind it because the, the devil's in the detail. You need to figure out how far down in my supply chain do I need to dig to get the problem fixed, right? And it's not normally you, it's somebody else who has supplied that, interestingly, probably one of your biggest partners. And then eventually to get to standardization. So it starts with simple things. When you think about how can I uniquely identify a supplier, right?

There's probably at least three categories in the world that has been used. So the DUNS number is a usual one you can use. But is there a unique identifier for suppliers? Probably not. If you want to have it referencable, there has to be kind of a global name space for that problem, right? We can only do that together. We need to bring people together at the table and then agree on those standards, but at the same time start working on prototypes. So instead of over architecting it, get it more incrementally done, and I guess that's the vote I would call here.

Let's start incrementally, but let's agree on standards early on. What we already can use today, right? And so eventually, is software bill of material a common solution to Blackstone's? Probably not, right? But it's a major step in the right direction because eliminates the surprises or it reduces surprises. You have a much better transparency where things are, It helps to clarify where to prioritize, right? A lot of us probably, when you're an emergency, you need to know who's calling the shots, who can actually help me to fix the problem.

I probably have to shut down stuff, I have to patch it immediately, stuff like that. So we need to know responsibilities.

Again, a piece of information s om can help to provide and eventually you can get a little bit more ahead of the curve, right? To get things done more on time, maybe like your tax declaration, do a little bit more early than it becomes not such a pressing issue at the last day. So you spend your night to get it done, you'd probably be ahead of time, you'd be a month earlier, half a year early, maybe even more, right?

And here, every minute counts, right? When as I said, push comes to shove and you're in an emergency mode, your brain starts working in tunnel mode, right? There's no stuff you can remember, you haven't trained before. So it's important to have good and solid data as a baseline. So what I'd love you to do, to take away from here, think about SBO M as an additional solution, complementing your asset space being more detailed, but based on a common standard. Think about how we can collaborate, let's say at least on a U level to establish a common ground.

How we interchange information about people we source commonly. Yeah. Many of us have the hyperscalers, many of us have big software vendors. They all have the problem at least solve, to the degree that they want to win federal contracts in the us. So they have to have a solution, right? We can leverage that and it makes us just stronger in a supplier, in a supply chain security governance. Because what you usually see people whine in front of you and then you find out, oops, if they award myself a contract, they ask for the same topics, right?

So if you flip the metal around, they can actually do things. You want them, they just avoid it because it creates additional costs, right? So be confident you can ask them to do this. They have solutions for that and don't take excuses, right? So they usually need to do it because they're interested in the business, right? And we still need to fix the basics. Even the best asset base doesn't tell you how you do patching beforehand. So your patch cycle should be up to date and up to snuff, right?

So it should be proactively and your systems need to probably be able to be patched online without taking them down. So these are all basics. They come on top. But sbam gets you much better guidance on how to get things done. And I would want to leave you that and then open up for questions. Yeah. Thank you Frank, for this insight and quite innovative topic. Yeah. Which you would not expect normally to be a part of the top of a sea, right? But that was, that was really good. So there was no question from the online audience. Any questions here in the room that doesn't look like Right?

Just on time? No questions and we are anyway, a little bit behind schedule. So thank you very much. Thank you for your presentation.