09 - Transparency Exchange API: How We Will Share xBOMs

Thank you everyone for staying for for the talk. Um, just before I start, I'd like to ask you for a quick show of hands just for me to set the pace of the talk. How many of you know what an asbomb is? >> Perfect. Great. And how many of you know what an axbomb is? Okay. No, that's great. That's great. Uh so my talk would be about OASP transparency exchange API which I personally think is one of the main things that's happening in the supply chain security space at the moment. I'm very excited about that. I'll try to to engage you as well with this. Uh very quickly about myself uh I founded company called Realiza in 2019.

uh currently we work on a tool which deals with asbombs xbombs called rearm uh I'm one of the core contributors of transparency exchange API so the project I'm talking about and uh I'm participating in bunch of asbomb groups like that's uh the subject I'm very active on um yeah I'm also playing organizing not organizing actually anymore but playing u social deduction games, Mafia, Werewolf, Blood on the Clock Tower if any of you like familiar and so I love to chat about that. Okay. Um so there was a very recent opens open SSF uh white paper regarding asbombs which uh I have a reference in the slides like on the last slide so you can actually find this uh and it lists a

bunch of use cases related to asbombs and this is a very compressed version that I put in here. Uh so the most important one most people familiar with is uh vulnerability and risk management very important and uh then you can do a bunch of other stuff with sbombs like you can track updates of your components know if something's outdated u license management uh license risks very important what if you're using some incompatible license that you're not supposed to use ax management so It's end of life, end of development, end of support, end of anything. Very important right now. So, how do you know that the component you're using is not supported anymore. So, you could use an asbomb for

that actually. And then, uh, product vendor risk assessment, instant response. So, when you do instant response, you want to know what you're dealing with. If you have an asbombs, this should make your life easier. If you have, I'm actually readily available. And then compliance very big thing driver of everything I mean it's not the most important but it's really the driver and I'll touch it again uh in this talk later so and now there is actually a lot of bureaucracy and various documents involved in software supply chains. So what's an xbomb? So as sbomb is a software bill of material. Xbomb is a bill of material but kind of not for software actually it includes software

it's software and other stuff so I list few examples here one is Hbomb which is hardware bill of material so let's say your laptop like what's inside on top of software or software on top of hardware that's inside maybe that's more correct AI bomb so you're using this there were a lot of talks today about AI So you're using AI. What are the actual models? MCP servers, all the components that that go in that would be your AI bomb. And then uh Cabbomb, cryptographic bomb. Actually, I missed the talk, but I know there was one on on quantum. So Cabbomb is actually a list of all your algorithms, and you can use it to figure

out which which are quantum safe or not. So things like that. Add the stations. I don't know if you're familiar there are like very hot in this um area. So adistations are like signed statements uh about something like for example adistation can bind your asbomb to your software and it's a signed verifiable statement uh VDR vex so um vulnerability disclosure report vulnerability exchange bill of vulnerabilities so this are a lot of documents that relate to vulnerabilities in the field common life cycle enumeration documentation certification formulation like lots lots of these documents. So this this is like all like huge actually amount if you think about of paperwork that we're supposed to be dealing with in uh in supply chain

security. And then uh like bomb is not that popular in 2025 because everybody thinks or knows that asbomb generation is actually a solved problem. Like it see like you have bunch of open source tools you do boom you have you have an obomb that's great. Uh there is just one issue that like all that data that goes as your in your asbomb is actually frequently hard to obtain and that's really everything starting with component identity author license and then what's inside. So existing tools do a very good job in actually figuring this out and like finding a lot of those things but many still get missed and uh sometimes you will have asbombs with no licensing data

very frequently and there are a bunch of like open-source crowdsourcing websites where you can sort of enrich and and find it but generally this is this is hard to find. So what's the easiest way to find all this missing data? So let's say you bought or software from somebody or you just downloaded the software. So it's very simple idea that the person or organization who built the software or maintaining it in the first place are the best source of your data about all those things. So why you just don't go and ask them? And here is like the the shocker slide which basically it it appears that everybody wants this data from others but nobody really or very small number

of organizations really want to share this data. Okay. So here's here are some reasons why. Um so a lot of people question why they need to share in the first place and then what would they share and then is it is it like safe for them to share. So they say, "Oh, if you get my ass bombed and you know all my dependencies, then it's very easy for you to let's say hack my software if it lands uh somewhere where you don't want it to be." And uh there is this friction on the market that people want data to they want to have data but they don't want to share it. Um and here is where back to compliance.

So big event for asbombs was log forj log for shell thing which I think most most of you are familiar with and this is where a lot of this regulation started to emerge. Um I'm putting Canada first for all like anytime I speak in Canada. Uh but uh so this is recent one. There was like a shared vision for asbomb from 17 countries that was like a month ago or something which is actually a great thing for in the asbomb world because we now have a shared vision. Uh and there there is this document I think it's from um two years back. Uh note that in Canada nothing is actually mandatory. It's all like recommendations.

But th those other things like like CRA which coming in two years that's like a huge uh piece of legislation regarding security. So any product with digital um elements on the European market essentially falls under CRA. So that that's a hu because right now we're dealing with I don't know like defense industry, healthcare industry, fin so only regulated industries but this really makes it like everyone is going to be involved and you need to have uh like a lot of people a lot of organizations would need asbombs. Um so documents in the US and some recent documents in India mainly for financial industry which are driving it. So regulators are driving regulated industries to adopt asbombs and then

they're pushing their like those regulated industry pushing their contractors and that's how it's propagating. So we get we get our sharing like data sharing train moving. It's moving slowly but let's say but steadily. So, how do people actually share these documents? And um number one is email. I think you know and it it it's not meant to ridicule anymore. I mean it's uh I I do that too because how else how else you do it? Okay. I uh there are other options as well. I just um yeah I mean that that's the guy who who needs your sbombs. That's basically his his effort. So, OCI registries. So, you can put if you're using like docker images,

docker containers, you can put uh asbombs near them. Uh there are like trust portals for example like for various compliance standards that you can also like put your sbombs in there. A lot of custom solutions. I not listing them all but this seems to be pretty popular. So you get some URL and you put some password protection. You ship you give password to your client and say okay just go and and find something. Uh and this is like Cisco standard. I I didn't find actually any evidence that it's used in in reality but they're pushing for it. So they want their devices to have well-known/asbomb uh with my and that's basically how you can find asbomb for it's a pretty pretty

interesting idea but uh you see so there a lot of custom solutions and number one is email which is maybe not the best so here comes uh transparency exchange API so what we're building here is unified distributed way to source authoritative data across supply chain. So we want everybody to have the same API upstream downstream and you can go in and out and source all the information you need. So that's uh the big uh the big idea and there are other use cases. So you can quickly retrieve all these compliance artifacts uh answer your life cycle questions, purchasing decisions, uh compliance and this is really cool but this is coming like in the next versions. This what we call insights. So

you can ask questions such as do I have lo for J anywhere or am I affected by this CVE? Is it anywhere in my stack? So you can quickly go like you can get this insights from from the API. Uh so what what's T built on? uh so first of all is uh product component data model which very important I'll show you on the next slide and then uh there is discovery mechanism and there is consumer open API spec which is a pretty mature stage uh there is publisher API spec which we just start it's very immature at this point and insights coming coming later. So product component data model. Uh so the idea here is when you get some

product you get specific version of that. So right now frequently what we see is the ASBOM what you have is some snapshot of latest offering of uh of some software but it's not necessarily the thing that you received or the thing that you had in production or from CRA perspective if customer buys certain device they need a document specific to that device and not some kind of some abstract latest. So in transparency exchange API we respect that with this model. So this is like log forj everybody knows it has two main components log forj core log 4j api. I think there are more but I'm showing this two and then those are real and pretty recent releases of log 4j not the

ones that are like log for shell or anything like that uh and you see each of those releases so it has specific versions of this components inside and that's what what uh the transparency exchange API respects and I'll I'll show you how in a bit. So discovery uh how does discovery work? So we have a thing called uh transparency exchange uh identifier I think. Yeah, it says index but I think it's identifier. Yeah. Uh so transparency exchange um identifier which is um assigned by manufacturer that's very important uh according to certain criteria. So it would be uh like so this is the schema and the idea is that manufacturer can use one of many types. We already

documented those four but uh the other ones like GS1 etc are coming uh probably pearl package URL somebody familiar with the concept okay package URL is uh going to be also ACMA standard like uh supported by OASP and it's like in the same standardization group as transparency exchange API and uh that's So this part is package URL. This is the way how you can identify software. Uh your UID is specific likely to your T- server and that's what I I will show in a demo. But there are like other things. So the idea is that you have this authoritative domain that belongs to manufacturer which would have a well-known uh slasht thing and that well-known slt

thing would uh point you to the actual T server that from which you would store everything. I I'll show you the discovery on a demo in a second. So once you discover thing you would go to product release and then component release and what they have is collections of artifacts which is basically a set of all these documents that I mentioned earlier and uh this set is tightly controlled. So uh when you add, remove, modify something uh this creates a new version of the collection every time and uh every version essentially is stored in your T- server. So you know every time there is a change this is tightly controlled and I already mentioned insights this is

uh this is something that's planned for the future of transparency exchange API and right so there there may be more and um more questions but those are the ones that really uh frequently important because uh if there is a new zero day report or something you want to quickly know So you remember right that the time spent to discover if organization used log forj and where so with t those questions should be answerable instantaneously. Okay so I recorded demo but uh I want to show it live because I recorded just in case and it's very short demo. So the only thing I'll point here is um you see I start with uh this uh T TI. So

it has this uh demo of rearmq.com which is uh essentially a resolver for the T. And here, yeah, I cannot magnify that unfortunately, but this is my web server where I put the well-known /t URL and then the UU ID. Uh uh warning this will change slightly. So I I submitted pull request recently to change this a little bit, but I'm showing the the the current version. So once I click here, what happens? it will redirect me to the T server. Uh, and this T uh server returns me again. This is the Apache log forj product that I showed recently. So, this T server and this points to specific release that I shipped 2250 and it tells me it has

two components. Uh, remember this is API and it's supposed to be parsible by robots. So that's fair. But um I'm not a robot. So I'm just showing how it works. So once you know the release, what you can do, you can uh open it, go to collection latest and you see artifacts that are attached. In this case, this is a demo that uh that I built. We have like one sbomb and it has a real link. So if I open this, so this goes to Apache. So this is a real log forjsbomb from Apache which belongs to this uh release. So another thing very quickly that I can do here, I can get this product UID

and list the product releases. Uh yeah and you can see here that there is actually a new version now 2251 and I was given this 2250. So I can actually use that information uh as something new and again this is provided by manufacturer. So this is authoritative source. Um okay so almost done. Uh so as I mentioned or or maybe I didn't this is going to be a standard uh so OASP uh Cyclone DX Cyclone DX is a asbomb standard uh they kind of created this path to standardization which is first ECMA standard uh and then ISO. So Cyclone DX is already an ECMA standard and then package URL and CLLE I believe there would be like a general ECMA

meeting in December where we hope they'll become standard and then for T for transparency exchange API we hope this will happen sometime next year so we're moving to standardization phase so again the idea is that everybody adopts it and then Everybody has single mechanism how they can go up and down supply chain source this artifacts source all the metadata and uh so hopefully there'll be less uh less questions about that u okay this uh this will be in my slides uh that you can see later but yeah bunch of resources regarding uh so GitHub repository and then Slack And this Thanks. >> Thank you very much. >> Thank you, Pavo. I >> think we have some time for some

questions. Does anyone have questions? >> Uh over there, lady in the back. Let me get up there.

>> Hi. So the one of the issues that I've seen with the sbombs is that you have to like the tools the scanners typically the um like SAS and D scanners they allow you to create them but it's by repo. So if you have a big uh repository code repository then you have like a bunch of you know repos uh is that something that is going to be solved or is there any tools that you can recommend where you can generate this bombs and um you can go through all your and crawl through your GitHub and and the dependencies. Uh I okay I'm I would answer from my perspective as I do. So other people in T may have

different views but I believe asbombs should be generated on the CI phase. So every time you have CI run you should generate I believe you should generate an sbomb and the t gives you framework to store and retrieve those sbombs. So asbombs should be built per each version of each component. There should like there is a thing that I read recently called dynamic asbomb. So it's like asbomb for your whole project. every time you have some update uh it it gets updated. So to me that's a big misconception. I think I even wrote like a blog post about that. So asbomb belongs to particular release when something changes then it's a new asbomb again if you shipped to your

client or like internally certain version of your software let's say version one and then internally you have version two which is all bells and whistles everything's fixed security perfect then if your client still running version one with like 100 vulner vulnerabilities, they don't really care that you have this version two until it gets to them. But if there is an incident with their version one, then they need to know. So that's why it's actually very important that you preserve uh original asbomb for every version and European CRA would require that and and probably others later as well because usually they start something in Europe and I mean regulate regulation wise and then others go okay there was a

question yeah Let's

Okay. So the question is uh where would it fit? Would it fit like in CI/CD or IT part organization? I would like again my personal view is a lot of parts of organization should have access like in real life what I like developers should have access security should have access devops should have access legal should have access because they deal with us bomb from my experience and then it should have access as well but maybe this access should be let's say granular like not everybody accessing the same think uh like maybe developers would have access to more like to some sort of development releases that let's say legal department does need to see that is possible but uh this should like to

some extent I believe this should be accessible throughout the whole organization and also externally yeah

Sorry. Say

>> okay. Okay. The the question was about non-disclosure agreements and how does it fit? Uh so there are different perspectives. Okay. That the last question probably. Okay. So there are different perspectives on on this. um the most recent I would say state-of-the-art what we think about that is that a system like T should be able to tell you to distinguish between information to which you don't have access and information which does not exist and it should give you the answer based on that there is some extreme approach which uh I kind of like but uh probably won't get a lot of traction which basically says that very soon everything will be public. So people who are trying to hide their

sbombs in the hopes that they won't be hacked because uh somebody doesn't know that they're using some dependency from 2015. Uh that's like not going to work long term. But I I don't know if we get there. I mean that you see my