Exchanging BOM data with DBOM
I’m DJ Schleen and welcome to daBOM.
I’m on a journey to demystify Software Bill of Materials and on this podcast I’ll be investigating technical, regulatory, and practitioner stories in and around the SBOM and -BOM movement.
Along the way you’ll meet the people and teams responsible for creating and maintaining the various Software Bill of Materials formats, and we’ll also dig deep into all types of Bill of Materials including SBOMs, SaSSBoms, IBOMs and any other type of -BOM that you may have heard about.
If you’re interested in software security, the software supply chain, and want to know what’s in your software, you’re in the right place.
When the video call finally connected, I saw glitching Chris Blask sitting behind a studio mic, and in the background an open door revealed what appeared to be a lake – with sun glistening across the water.
For a brief moment, I thought Chris was working near a dock, but in fact, he was actually working on a boat.
A boat in the middle of the waterway, far from any shore, in the Florida keys.
The internet connection wasn’t the best as Chris took me on a virtual tour of a floating home and it took a bit of time bouncing between satellite and 5G to get things stabilized. As he walked around the boat and climbed up to the top, he showed me the solar cells, the generator, and the setup for his internet connection – but just before returning to his microphone, he did a slow 360 degree panorama of his surroundings.
I thought to myself… I’m on a journey to find out more about the DBoM Digital Bill of Materials project, and on the road, it leads me to a remote location surrounded by beauty and sunshine?
Welcome back to daBOM…
I’m here with Chris Blask. Good to see you, Chris. I think you’re one of the most interesting people I’ve met. You’re located right in the middle of a river and probably have one of the best technical setups I’ve seen in a while…
How are you doing, man?
I’m doing good. I’m glad I got a chance to show you the boats and enjoying the life on the water and hacking the world.
You’re one of the co-founders of DBOM. Give me a little bit of an overview of about what it does and how you decided with some of your co-founders, to get this project started.
Like a lot of things it emerged. From my perspective in 2018 at a Cyber Senate in London, we had a panel on supply chain, but we ended up going there and realized there wasn’t any supply chain security whatsoever. And no way to say to anybody what’s inside anything.
Over the next year or so, into early 2019, and it was Mehdi Entezar, had a standing call. It was just the two of us this week and we had an hour long, classic hour long, epic conversation and DBoM was the result.
You think about it from that perspective, UNISYS mostly still makes mainframes. They take a bunch of Dell computers turned into an actual mainframe, sell it to Citibank to run the global economy. As a UNISYS employee at the time for both of us, the conversation was basically, we can just write this down and they can see it, using a distributed ledgers or there are ways to do this today, but we’re not doing it.
Anybody can go download DBOM node code and stand one up. You don’t have to ask anybody. It doesn’t matter what you do with it. you. Can create a channel, for example. And you can use a Mongo DB or a blockchain of hyperledge or whatnot, and you can attest to things in that channel.
If you do this for your own purposes, just to keep track of things good for you. But you can invite someone to subscribe to that channel, like your business partner. If I was a vendor, I might stand up a DBOM node, create a channel where I want to put the attestations downstream to my major integrator.
SBOM is one of those attestations, and it’s the attestation we’re all talking about now. That’s what Kate’s been doing for, for many years, right? How do we actually write down the contents of software? DBOM is one structure you could use to share the attestations about all of that.
This is more than just software bill of materials though, right? You can transmit any kind of artifact, VEX, I saw something about carbon footprint, those kind of things. So is this like a wrapper for this kind of information that you’re sharing from one place to another, or one, like a vendor to a consumer?
Virginia Wright at Idaho National Labs, described DBOM best, I think, in two words at least; instrumented plumbing. DBOM is a way to share information and specifically the attestations.
Attestation is an interesting word. When you think about it, you attest to things. Businesses attest to each other all the time, and probably should do it more and probably should automate it. When we look at IP control right now, it concerns people a lot in threat intelligence sharing in supply chain intelligence sharing, but how are we doing IP control now?
We’re writing contracts and we’re signing them and assuming our employees are probably following them. As we build automated attestations into lots of systems, we’ll find that we have better control of, for example, knowing where our IP is gone, establishing channels. We’re doing this with contracts now. You are allowed to share this IP. We’re not really instrumenting that.
Looking into a bit of DBOM, there’s this trust model associated with it. We have SBOMS… how do we share them? How do we ensure that they’re not tampered with from the provider to the consumer of these things? And then the privacy information around it, there could be IP in these documents.
How do we ensure that prying eyes don’t see them? This is sort of what I’m getting the DBOM is pretty good at.
Right. Next week at Dale Peterson’s S4 conference I’m giving a talk, where I’m trying to explain just this. There’s one slide, if I have this right, that helps us think about it because it may not be a network diagram, but it’s a relationship diagram. You have a vendor here. They’re connected to an integrator there. You have CISA up here. They’re connected t, the ISAC and you have a SOC operations group, and they’re the solution being sold to a critical infrastructure asset owner. They buy the water treatment system. How do all these things connect?
DBoM is one way for those parties to represent their relationship in real time, basically.
So you mentioned CISA. Is CISA using DBOM right now?
Chris Blask: CISA and the federal government are very aware of DBOM. We’re all trying to figure out how SBOM sharing works at all, and how all these different acronyms, there is SKIT and DBOM and GitBOM and SLSA and GUAC and all the, you know, SPDX and CycloneDX. Even the folks working right in the working groups where we’re trying to figure all this stuff out, we haven’t figured out how it all moves around. That’s the maturity level we’re at right now.
In fact, the talking giving next week I’m doing it as if it’s 2030. I think it’ll take it about that long. But by then everybody could be doing all these things and it’ll be obvious how it all fits together.
What are the biggest challenges when you’re discussing SBOMs in these working groups and where it goes now. People are really starting in the industry to say, hey, we need an SBOM for everything.
Right. In fact, there’s an SBOM Everywhere working group,
I like to look at where we are over time, right? That tells you regardless of the details, how fundable things are, how fixed it is, can you walk out and just read this up? Or, what stage are we at?
Two years ago in these same working groups or the ancestors of these working groups, Presidential Executive Order, and vendors building in, getting big, huge companies that write their own software that have tens of thousands of programmers, they’re doing this now. All the major government contractor, you’re doing this now. Now you’re building it and you’re assuming it. On the issue of policy, even though it may not be required by DOD, you’re doing it now. So if you think you are a stakeholder in this, if you produce software, if you consume software, if you take other people’s software and build solutions for other people, you should be looking into this.
I think you hit the nail on the head. A lot of people are preparing for it. Even folks that aren’t in a regulated industry, they want to create these. They know that they’re going to be valuable for inventory, for license information, for file integrity and these kind of things. But they don’t know what to do with them after that.
They just store them with their releases, which I think is a good baby step, right? It’s step number one in the whole process of dealing with these things.
Looking inside big software houses is a great example of it because some of the companies I’m talking to aren’t selling their software, they just have 40,000 programmers. They write their own software, big, huge companies, and security is important, but security mostly gets done when it saves money. These companies are not all doing this just so that they can stop the wily hacker. They’re doing it because they spend millions and millions of dollars writing code and moving it around and handling it, and it’s better, faster, cheaper if you know where you put it and what’s in it and where it came from.
You know it may take some effort, but once they’re in place, you find out that writing the same line of code costs you less money.
For example, let’s say someone publishes out an SBOM or DBOM out to a consumer and there might be Log4j in that SBOM listed out. How does the consumer find that out? Is there some sort of query ability for DBOM?
Yes and no. Again, DBOM is the instrumented plumbing. You could say if that customer out there, had a DBoM node, they had some channel between them and their supplier, that the policies is there expressed what they thought that relationship was gonna be, I’m out sourcing SOC operations to you, integrator. Therefore, when an IOC and integrator are compromised comes from a reliable source like CISA, that not only says, there’s a vulnerability… I accept vulnerabilities, they’re all over the place. We’re not gonna solve all those, but if there’s a vulnerability in one of the products in the solution, you sold me… and there’s an IOC, there’s a reason to think that someone like me, a water facility… was attacked by a nation state actor using a known vulnerability, and a known product.
That information, that indicator of compromise that IOC is shared in the world, you, the integrator are going to bloody well know about it. You’re going to have the relationship with the vendor so that you can get the VEX, the vulnerability exploitability exchange document or whatever that turns into. Yes, this is vulnerable, and it’s exploitable… but not if configured this way or if the network doesn’t, share that information with the integrator and the integrator’s going to implement it through their SOC services.
In that example, the asset owner doesn’t need to know about the SBOM doesn’t need to know VEX… doesn’t need to know about the IOC. They need to know that they’ve got a responsible party that is going to listen. If there’s an integrator compromised, if someone like CISA or some serious organization says, we’ve seen this in the wild in a level of definition that includes you. Not just all devices on earth, but all devices at water facilities in nations of this political alignment, then someone should be able to look that up and have it taken care of.
I noticed there’s a bunch of APIs and SDKs around that you can use to integrate to create new connectors, different kind of storage mechanisms, Postgres or even Ethereum. How does that work from a technical perspective? How does that enable people to get that trust, get that integrity and those kind of topics or those kind of things?
Well, I don’t know if I can really answer that right now I work for a company, Cybeats. I have a bias in this direction. But that’s kind of what Cybeats SBOM Studio does. Creating an SBOM and moving an SBOM around is one thing. But again, you use the right term. It’s an artifact.
How does that artifact work with everything else? How do I dive into all of my software catalog and find where an individual library is? Companies like Cybeats are coming along to make those tools, but we’re seeing what people are doing with supply chain intelligence and it’s not just sharing it. A lot of it is for internal uses because, you know, having lower costs and being more competitive is what businesses are supposed to do.
The creation of SBOMs almost seems to be like a commodity right now. But what you do with them that’s like that mystery juice that we need to find out.
Yeah. And I can say this, without commercial bias. It ends up being really simple. It’s really straightforward stuff. Technically it’d be complicated, but once you see it. File Explorer… when Windows 2 came out, I was a Unix geek and I’m seeing a File Explorer and all my friends are joking at how silly it is… It’s like, no, that changes the world. You can just look and it’s there.
If you’re in this world right now, what do you actually do to solve this question? You literally call meetings, send out calendar invites. You’re most expensive, best… you know people who are mostly overworked, have to start writing spreadsheets. The capability automate this is sort of laying around to be done.
That comes into the whole artificial intelligence conversation, right?
Are we gonna get to a point where we can ask a question and say, Hey, do we include this license and just have that information come back? Is that like a potential client for this technology?
The real answer is you don’t ask the question. You build questions like that into your systems and they’re answered as they come up. What you get is the answer. The answer is, you’ve just been alerted that yes, this affects you, and yes, things need to be done. And if you didn’t get that answer, then you’ve already asked the question, but you didn’t have to spend the time doing it. You built it in.
That’s a great observation. Automated systems should be automated. You don’t need to have that input to actually trigger an event.
Leaving aside on any of the technologies, look at the world today. My wife and I have been married almost 40 years. In the city of Toronto at the time apparently you put your job title on it, so I was a forklift driver and she was a word processor. That was a job. There were floors and floors of people who were word processed. Where are the jobs today? Reading contracts. Literally reading the things that you wrote and signing yourself and trying to figure out if it applies to a thing.
Automating that in is inevitable and the cost savings, the efficiencies and the competitiveness. It’s not a matter of good, bad, or otherwise. That whole area is pushing the inevitability curve, for the next 10 or 20 years. 20 years from now, I think it’d be really unlikely to have this conversation where you’re literally reading through your contract.
How does DBoM handle policy? Is it an enforcement? I noticed on the website we have policy control listed out there. How does it do that and what does that mean in the context of DBoM?
Enforce is maybe the right word for it. Instrumented basically. Some of the use cases, I like the National Manufacturing Institute of Scotland. I love their use case because if you look at it, you’ve got an airframe manufacturer and you’ve got an engine manufacturer and you have their subcontractors and you have a National Air Force.
You know what we’re trying to build here is to allow the flight engineer for the National Air Force to look at a single blade in a turbine in a motor, and know the software that was running on machine tool that made that blade. How do you do that?
DBOM allows you to have places to store this and you have an Oracle that’s reading your policies and enacting them that says, gets us a request from an authorized user in this example, and it just ratchets up the DBOM chain. Contract says, I’m allowed to ask that one and ask the integrator whose systems ask, upstream all the way to the small Scottish manufacturer whose machine tool itself was writing the attestations to a DBOM channel.
This is a great example of the bill of materials in general, not being just for software. Because when we hear a lot about software bill materials, everyone’s like… well, I have SCA tools, software composition analysis, and that’s an SBOM in disguise and it’s not.
We talked a little bit about file integrity, license information, the contents, even a font that’s sitting in your software can have a vulnerability in it. But even if it’s not a vulnerability, it’s like… What version is it? This is inventory management and that’s been around for years in the manufacturing industry, and it looks like we’re taking these concepts of how we manage inventory and even to the machines that build these parts as you’re discussing and finally getting these together. To the manufacturing point, it’s the same kind of thing we need to do in our build systems that are building software. Open source build systems. There could be supply chain attacks coming into that. That’s touching your software.
Think about these open source compilers that are out there to compile C++ or Rust, or any kind of language. We don’t have the skillset to really know if that’s injecting malicious code into that build. So really we want to know what’s in that software that’s helping us build our products.
Coming from an OT and a manufacturing, my first major job was making Sears catalogs. Right. You know, so I got to see all of the supply chain. And bills of material literally make it all work. The big machines don’t really matter. You’re assuming there’s a big machine there. There’s this piece of paper, a bill of material, and it says, here’s the thing. And that puts the information on that physical piece of paper, is there because there was contracts between organizations.
We’ve always had these structures. As the computer people, we can automate it and we can use it for our purposes like security, but we’re not inventing the wheel.
Do you say that we’re catching up as an industry, as a software industry, we’re catching up to what’s already been done?
Oh, yeah. OT is so much more advanced than IT. It’s been a fascinating thing as an OT, IT person, for over 30 years. IT has had this sort of adolescent moment where it’s like we’re all grown up and we’ve got all the money and we’re the ones and the OT people, oh, they’re so old fashioned, they don’t really know anything. And it turns out we’ve made a lot of hot cars we drove into walls really fast. OT has been building the infrastructure for 6,000 years. They’re really mature on reliability and process and supply chains. This is all going on before people use electronics.
The OT, IT thing has gone back and forth a little bit. OT folks can feel that they’re behind because the cyber folks, all the cool kids, all the cool stuff. We make a cool car and drive it into a wall really fast. OT and supply chain and logistics and all this stuff have a lot to teach cyber.
It also goes into continuous learning. If something goes awry, a building that’s been around for 70 years. If you have the bill of materials… the compressive strength and the content of the concrete is, the quality of steel, the bolts that are put in. We saw that whole building collapse in Florida, couple years ago. There’s a lot of investigations coming after that, asking questions. That helps feed into building codes and things that we can learn to make our structures more sound and safer.
If we take that lesson to software, we could probably get the same kind of results and make our software more secure and really more resilient. in general, from a software perspective.
And that’s a positive feedback loop as well. That building isn’t terribly far from where I am right now. That happened again because while those processes are better in building codes and so forth, it’s easy to hide things and lose things because it’s not electronic and it’s not all automated.
The systems we’re building today for supply chain security will, in fact, like DBOM the topic of this conversation, will get built into those sort of things. So building inspector is not wandering around hoping they can see something and pulling documents and reading them late at night, but they’re seeing the building… Find what they have to do the job. And that seeing means seeing who touched it, where it’s been, and it’s all right there. That would stop a lot of structural collapses today if people could actually see the information in the time available.
You can always see the information if you have the time. But you also have a budget and you have auditors and inspectors and so forth, and they’re working the best they can in the time they have given the efficiency of the system.
You had said 10 years from now, 2030, that’s when we’re going to potentially figure out this IT SBOM thing. How do we get there? What do you see as the near-term future versus that long-term future?
There’s a lot of incremental steps.
I’ve seen this over and over again in my life. In the early 90s, got in the firewall world. I thought everybody in the world was gonna get on the internet and they all need firewall.
If that happens in five years, you start doing the math. How on earth could anyone ever scale up manufacturing, production, shipping, receiving, so that every organization on earth gets a firewall in five years. You can’t. It took 20. The nature of the world allows us to get a benefit out of this.
The short answer is do what you can right now, short term, you’ll be fine. Pay attention. As I said earlier, a lot of this hasn’t entirely been figured out, but if you want to sell products into the US Federal government or kind of anybody else, and you have a software in it, figure out your SBOM thing. If you are writing the code, write SBOMS. If you’re buying the parts from somebody else, start asking them… Hey, when my customer comes to me and says they need this, how do I do it?
It’ll work incrementally, one step at a time. The very large companies that among their peers have been early adoption of this, are already on the path. They’re implementing things. Their CI/CD pipelines are merging with and evolve around this.
Another Linux project worth calling out, Custody Attestations of Code in development use. Those are the sort of things you would see on DBOM channels, so that dev teams and QA teams can more efficiently do their jobs. We’ll get there one step at a time. One thing that people will overfocus on is public policy and US public policy particularly. But it’s not the driver anymore. The driver is now efficiency, and security, and lowering risks.
As we’ve seen with the minimum specifications for software bill materials coming out of the EO. There’s only a few. Licensing isn’t even in there, file signatures. It’s very basic.
And it’s a start. Licensing is a perfect example. This is a real issue for real companies all over the place all the time right now. And again, how’s that being done? Someone in legal read the license or somebody wrote a policy saying, you need to file all the licenses somewhere so you can someday look ’em up in case… no, licensing is a real thing and automating that has so many positive benefits that’s gonna drive forward the next couple years.
Where do people go for additional resources and information on potentially joining these working groups and participating in this community?
Good question, thank you, because it’s kind of a hot topic right now. So I don’t quite know all of the working groups. None of us do.
I believe the CISA SBOM onboarding working group is taking that. I haven’t had time to be involved with that recently and trying to identify all the groups. We’re still in this stage where if you like being on the really early track, you know hunt down any of them. The CISA, cisa.gov/sbom, I think will give you a list of all the SBOM activities there. There’s five work streams. Pretty well every acronym you can think of
And you guys have a Slack channel as well, is that correct? DBoM.Io. I think you can link in there and join that.
Yeah, a slack channel there and this conversation right here. Somebody listening to this right now and finding how to find these things is, you know, I think in retrospect will be a very 1980s way of doing it.
This episode of daBOM was created by me, DJ Schleen, with help from sound engineer Pokie Huang and Executive Producer Mark Miller. This show is recorded in Golden, Colorado, and is part of the Sourced Podcast Network. We use Captivate.fm as our distribution platform and Descript for spoken text editing.
You can subscribe to daBom on your favorite podcast platform. We’re going to be releasing a new episode every Tuesday at 9:00 AM. I’ll see you next week as we continue to diffuse daBOM.
Resources From This Episode:
Applying the tools available to the tasks at hand shows us what is possible today and what is likely to be possible tomorrow. More than the intricacies of cybersecurity or the appeal of technology, this is what I find interesting.
In the early 1990s while trying to make it easier to get online I accidentally invented a firewall. When it turned out most folks couldn’t use it without Network Address Translation I fell into a mop closet and invented that with some colleagues, by carefully arranged random chance. More recently, while ranting about supply chain security in 2019 I tripped over a pile of digital chain, unintentionally placed there earlier for just that purpose, and found myself inventing Attestation Channels (Digital Bill of Materials) with a co-worker.
Pondering where we are and how the specific heck we got here remains the foundation of my Focused Brownian Motion approach to identifying the Inevitability Curves ahead. Surfing those curves for fun and profit remains the foundation of my daily activity.