Building SBOMs with Blockchain Platforms – Jon Geater, RKVST
Jon Geater, chief product and technology officer for RKVST, explains the role blockchain platforms will play in building SBOMs to better secure software supply chains.
Transcript
This is texturong TV. Hey guys. Thanks for the throw.
We're here with John. Geeter Who's chief product and Technology officer for archivist. They specialize in a lot of blockchain Technologies.
But today, we're not just talking about blockchain. We're talking about how to secure the software supply chain using blockchain. Hey, John, welcome the show.
Thanks. Mike. Good to see you.
We've been talking about how to better secure the software supply chain probably for years now, since there's been some major breaches and the question keeps coming back. How do we know who did what when and how do we make the supply chain immutable and that naturally leads to a lot of conversations about blockchain, but how will all this come together because not a lot of folks have a blockchain platform. So how do you see these two things convergent?
Yeah, I mean an awful lot of it has to do with a bit of Will and a bit of sort of shared understanding in the industry really just maturing. So yeah, like any supply chain the software supply chain depends on a number of people kind of coming together sharing evidence and then understanding what that evidence means so that you've got a collective idea of as you said you who did what when where did the risk kind of end with one company and come into another company? And then how do I trust that end artifact whether it's a manufactured piece of electronics or whether it's just a pure piece of software.
Do I know that it's been created correctly? And so what's happening now in the industry with software good of materials with the guidance coming out particularly from mist and sequisa in the US but there's some similar stuff happening in Europe is a growing understanding of getting right down to the fundamentals of how the software is produced how it's handled. How we stay on top of vulnerabilities and things being discovered and then how we act on that information to stay safe.
And so what we're starting with the software bill of materials. Is this really simple basic building block? It's kind of ingredients list of what is in what's in the box what's in my software?
And if you know what's in your software, you can kind of take control risk. So all of those things like log4j, for example that came up or the casare or the solar winds you pick any of your sort of celebrity breaches the very first thing you want to ask if you wake up in the morning and the news is running this big kind of cyber security story is oh my goodness, you know do I have log4j in my estate? And before the S bombs came along before we had this kind of shared understanding of the ingredients list for your software.
You just didn't know you had to wait for somebody else to tell you. So it's just sort of step one of this mature supply chain process and then where Technologies like blockchain or platforms and evidence Registries and that kind of thing come in is providing a way for people to get access to that information reliably. So I know it's there what I need it and maybe when I needed is kind of on the days sent to me, but more likely when I needed is several several days weeks even years in the future when something happens and to go back and get it and make sure that it hasn't been shredded that there's nothing being inserted and backdated people can't delete things and hide them from me when they become embarrassing that's where the two things come together.
It's like super important information and reliable secure delivery of that information to the right people at the right time. The perception is that blockchain is hard to implement and maintain so when do you think this might all be feasible? Well, I mean I'd have to say from my perspective.
It's feasible now. We but archivists we we do that already today by kind of wrapping up the the blockchainy stuff with apis and kind of familiar access control. I mean something something that happens rather often is that blockchain in general gets very quickly.
So to put together with Bitcoin type philosophies and memes and things and something that's very true and very interesting in things like Bitcoin is this idea of not your keys not your crypto and and so you will find corners of the internet to laugh at people who have the Bitcoin style and because it's like, well you put it on an exchange we put it on some kind of cloud wallet. If you don't own in control those cryptographic keys yourself personally, then you're not in control of that thing. And that's yeah if you've got a lot of time on your hands and you're a very specific squeezy expert and things like that that you know, there's some some mileage in what they're saying that but it's not practical because you can't expect everybody in the entire world.
Have full control over every possible detail of their technical life not only keys but their access controls and their policies and all that sort of stuff. It's just it's just too much. It has to be packaged up and delegated and presented in a way.
That's that's feasible. And so yeah, what we're doing and quite a number of other people in the industry now are coming together to do is to wrap up these principles core principles of sort of immuted ability and security which sit under under blockchain but make them available with a familiar traditional ID system so that you don't have to do your own keys for your own crypto you just log in with your two-factor device like like normal and you get in and dealing with things like simple apis and user experience user interfaces that present the information in a way that's actually kind of actionable and understandable without requiring a PhD in computer science to get to get under the cover. So undoubtedly lots and lots of more work to do more Innovations coming more standards coming into the marketplace that kind of broaden the appeal but I have to say in sort of short answer to your question that it's it's available.
Now there are platforms out there that that can offer you this kind of immutable shred proof. Fireball Supply chains How we operationalize s bombs I think at this point people have the concept that you know, we have a list of ingredients here that are in the components. A lot of times those components are updated and changed in a lot of times people are trying to figure out so if I get all these different s bombs, how am I gonna like actually turn that into something that is intelligence that we can act on and so what would the workflow look like in your mind?
And how is that all going to come together? Yeah. That's the question.
I think great question. Um, so it's gonna be automated it's gonna be integrated into existing workflies something that I really enjoy. I was talking last week to one of my my own devops Engineers guys actually kind of build and and keep my company going and one thing.
He said he really is kind of enjoys about using our products not platform is That he just inserts a single line of code into his existing workflows. And then the whole thing's audited and the whole thing's verifiable. He just doesn't have to think about it anymore.
And so we've got on the kind of producing side a number of ways. It's not just us. This is a sort of growing growing Market really of being able to produce and publish this stuff.
We're the one loaner in the workflows already exists. So you use Microsoft devops example, just put it in your template and off it goes it's done. So then operationalizing on the other side, that's the bit where you know, it's a working progress.
That's let's say we're seeing a growing number of Saw tools. These are the security automated orchestration response tools starting to read software bill of materials. Look for things that look a bit spicy and alert their users or got to do some trust scoring that kind of thing, but we need to have a lot more of that.
So a lot more automation on the inbound side so that when you install a piece of software when you take an update, maybe if you have machines or software accessing your your Enterprise Network and making privilege requests at that point, you need to be able to look inside the contents of that machine actor see if there's anything in there which is just recently become discovered vulnerable and make a real-time contextual decision on it. So, I think there's there's two things really that need to happen. There's integration into these tools and workflows on the consumer inbound side.
That's one thing and that is starting to happen. We have some pretty pretty interesting use cases out there with zero trust iot device. for example based on honest forms and vulnerabilities We need to do much more of that, but the other thing that needs to happen, which is a bit more of a mindset shift is doing this constantly, you need continuous Assurance because just because your software hasn't changed.
It doesn't mean that the context hasn't changed or the environment hasn't changed so you could be perfectly happy one day. Nothing changes in your estate but the environment or the attack context or a newly discovered vulnerability suddenly changes the arithmetic and the risk judgment on letting that software into your into your facilities anymore. And so those two things are what really needs to to grow in order to properly operationalize s bombs.
Do you think we'll ever get to the point where we have the equivalent of say like a red light green light for when somebody submits an application's will be able to just look at it and say this has vulnerabilities that are unacceptable risk. This has a component that we don't want to use and we'll be able to just have that immediate analysis before we decide to run this thing in a production environment. I I think I think we will and we do as a mentioned the moment again, we have some some Partners doing that already and there are other other players out there also doing it in in similar ways.
It's just not very widespread right now. So the the kind of thing that needs to to develop on that side is the standards. So it's easier to exchange these documents, you know, the critical thing with software bill of materials is that there's no point in having one unless it gets to the right place at the right time to make exactly those decisions you mention and so we obviously need the standard.
All moving them for one place to another and then for understanding what they mean when they get there and that's developing that's coming and that will that will grow the breadth of the thing but then the the next thing that we really need to do in order to kind of get red light green light is to understand the context. So yeah, I've been working in this space for well over 20 years now and the best that we had here to four was CVS. So the corn vulnerability system and CVSs which developed which is the vulnerability scoring system that tries to give you an idea of how dangerous something is but the problem with that has always been that it's kind of black and white and it says this is either dangerous or it is this is bad or it's good and it didn't make it very easy to take context into account.
So if I've got a piece of software and it has a vulnerability in it But that's inside a box which is wrapped up in a different interface which is installed in a facility which has barbed wire and armed guards and you know isn't accessible. Well, maybe my priority of my cyber fixes should be somewhere else which is accessible. Even if it's a technically lower risk thing and you you each each person has to take their own risk and their own circumstances into account.
And that's what's been missing. And enabling rather than a red light green light enabling something which is like a constant Amber. But then tells you where to look and helps you to actually prioritize the daily work of keeping a facility safe and secure.
That I think is where we're going to that's not here yet, but when we get there and I think we'll get there pretty soon. It will make the world considerably better because now people can assess their own risk, they know their own value and they can actually do the right thing rather than just kind of reacting blindly to the latest great big red button vulnerability which may or may not be important to them. We're going to be collecting a massive amount of data.
So where will we store all this stuff? And and now can we analyze that data and new and interesting ways we haven't thought about. That is a fantastic question.
So yeah, the s-bomb stuff comes out of a wider initiative. For zero trust architectures. This is this is where a lot of the the wind is blowing right now and in all of the kind of directives and the literature and the guidance that we're getting from nistancy, so and others it isn't just the software bill of materials.
It needs to be transmitted. There's also kind of letters of attestation from people to say I have created this in a good way. There are what they call life cycle process artifacts or I build it in this way.
It was signed at this time all of that kind of information and one of the other things that is really positive for a zero trust approach to security is that you gather information from all kinds of places. You want to go to the best. Most knowledgeable source for the information you need right now.
Hey, if you want to know the time you ask gonna tell me Clark, but if you want to know the weather you go ask the weather station, right? You don't cross them over you go to the right place. And if you don't trust that weather station, you ask three just in case one of them's compromised and they kind of spread.
Risk, and all of these zero trust Concepts do rely on getting data from a lot of different places. So where it will be stored. Everywhere probably, you know, sometimes you'll have duplicate copies of things.
Sometimes they'll be centralized. Sometimes they'll be on Beacon Services. I think that's a little less interesting in this context than how you trust it because what's emerging as a kind of new core pillar of data-driven services and connected industry all of you know, what's going on Behind these these initiatives is that you need to know the provenance of what you're dealing with.
It's not so much what it is. But where did it come from who made it who sent it to me, which could be different things and why do I trust it right now in the context of the critical decision that I'm making? And so the key thing that we're tackling.
The technologist on the sharp end of this question. The key thing we're actually tackling is how do we make a a layer and a set of services and a set of Standards where you can actually validate that thing. So no matter where it comes from you can do a check you can do an attestation or a verification on that piece of data that's coming into a state and say yes, I know where that comes from.
I know why I trust it and this is actually making my decision making better rather than the brother said situation we have in many cases today where actually data coming to your organization has the opportunity to poison your decision making and actually sort of sell your bum steer if you like, so that's you know, where the data lives doesn't really matter. I think we have to be open to getting it from everywhere but where the attestation Services live and where where and how we transmit that that Integrity information. That's the big challenge that we're all we're all chewing on right now.
Do you think someday will be applying machine learning and deep learning algorithms to that data once we start aggregating it all I mean, what kind of AI can we get? How smart can we get? Absolutely, I mean one.
One way I sometimes like to think about this whole puzzle is that rather than doing something completely brand new and revolutionary what we're doing is good old-fashioned best practice, but just at much much higher scale. So if you think about things like software bills and materials, so that's always existed and it a nice comparison here is with things like food labeling where the software bit of materials is kind of like ingredients on a packet. So if you have a nut allergy you want to look at those ingredients and just check there's no nuts in there.
And for some people that's okay. It's good enough, but for other people actually you also need to have that kind of process handling statement that says, you know prepared in a factory that may have previously prepared nuts. And and if you're that sensitive actually that's a problem too.
You need that extra bit of information. And so in that sense these kind of handling artifacts and all the software lifecycle stuff that's coming through is only a reapplication of best practice from all kinds of other places where we're already mature insensible. And so we're trying to just scale it up so that you can do all of those kinds of checks without having to hire another three Global populations worth of people to do all the paperwork and check and visit the factories and whole clipboards and things like that.
So with the AI it's a similar challenge. Right? What we're trying to do is really speed up the process of taking a hundred different documents reading them all instantly finding that needle in the haystack, which is the importance security vulnerability to us in our context and then flash a beacon on the dashboard of the honest regular worker day security engineer who then goes and fixes that thing so to two things that are definitely happening for AI helping are that massive scale analysis of all the data and looking for anomalies.
That's a good thing. And also there are some companies working on Cyber threat intelligence of actually kind of natural language reading through these cyber threat reports because a really time-consuming thing for our expertise. And these very rare kind of cyber Security Experts who can actually read and understand that report and work out what it means is the time to Simply get and read all these reports and then decide what to do about it, like gets a half past four in the afternoon and now I can start work.
So the AI is actually reading those picking out the Salient points and feeding the experts faster better quality information, so they can spend more of their time actually doing their job rather than working on Administration or reading. So those are two really encouraging developments that are happening right now. All right, great.
So what's your best advice to post because I think a lot of people are scratching their heads about where to get started. Yeah, so definitely operationalizing s-bombs and software supply chain stuff is is tricky there are a lot of mandates out there but not a lot of actionable guidance, so don't try to do it manually. I think this is the first thing.
S bombs look deceptively human readable because they're in this sort of beautiful structured XML with English language words in do not attempt to read the manually, it won't scale that way. So you've got a lean on your tools vendors to start consuming the S bombs and adding them to your Automation workflows and some some people are already doing this is starting. So it's a matter of just applying that pressure to the tools vendors to take this seriously and add the SBOM into their Suite of decision making information.
the other thing that you need to look at particularly short-term is that s bombs actually are not the first required thing the first required thing that's coming out of the guidance from the OMB recently is actually the letters of attestation. About how the software has been created so very simple statement from the vendor saying I promise I have read the rules and I've complied with the rules and here is my irrevocable statement and that irregular word is really important here is a statement that I make that I cannot delete. I cannot shred.
I cannot change later when you come and challenge me that says I followed the rules and I've given you the best quality software. I possibly can and so prioritizing those attestations from the vendors and starting to get the the promises and the transparency into the supply chain, which is so vital to having trust and security, you know in our cyber security Those that those are the two things do long-term medium-term. Get on the vendors get integrated.
Immediate term get those letters of attestation start pulling through those promises and transparencies that people get used to the process. All right. Hey, John.
Thanks for being on the show and sharing your insects. Well, thanks very much. All right guys back to the studio with you.