 Thank you everyone for coming this afternoon. I know it's late Friday afternoon and the conference is nearly about to end so Thank you all for being here. We all appreciate that real quick introductions My name is Parth one of the co-founders at Kusari This is a supply chain security startup and our one of our main focuses on the project walk and you know securing the supply chain Via secure a build as well as the knowledge graph Hello, I am Mihai like the Taylor Swift song. It's me. Hi behind my russack I joined Google five years ago to build TensorFlow security and Since a year ago, I started working on walk with a ghost because open-source security team and This talk today is going to be about walk. What is walk? What can walk do and so on But first let's start with the context So imagine some ten years ago five years ago people started thinking I need to implement this thing but there is already this package that does the solution that I want So, yeah, sure. Let me depend on left pad left me depend on this other dependency and so on and Suddenly we realized that our dependency chain is very huge very fractal like nature and very very complicated and Recently there is the executive order and similar legislation that asks us to take into account our dependencies and have a better control over them and Everyone started generating s bombs and now the question is what do we do with those s bombs? Dump them into database, but that's not enough. We need to do more and guac is Giving you what to do with the s bombs? So basically guac is first a knowledge graph of Software metadata so starting from the s bombs from south satay stations From all of these artifacts You can build a knowledge graph about everything that you have in your supply chain and then you can query it You can build integration on top of that You can expand and answer any questions about supply chain and question security so as a positioning compared to other Solutions in the supply chain stack guac is at the green level So at the red level at the base we have the trust foundations Starting with reflections on trusting trust and trust but verify we have six store then on top of that We have attestations salsa as bomb vex and so on Then from the other end you have policies, but instead of basing the policies directly on the attestation It's better to base them on some aggregation and synthesis layer and this is where guac comes in and As a company let's say you have your own software your own dependencies inside the company and outside Of the company and now you follow the legislative order and you build s bombs with spdx or cyclone dx or whatever other format You want to do what do you do with that as I said before we put them into guac? And just copy them there and now the question is what do you do with that guac is not just a static database In fact as soon as you insert something into guac it tries to link it to everything else that is inside there So I ingested some components it detected that you depend on this artifact by this artifact comes from this other post story It creates the link between them and you can start asking questions about the entire chain So from there like you might be wondering, okay, like yes, what do I do right away with guac, right? It's like, okay. I have I have the all these S bombs attestations and so forth. Can I put them into guac and can I locate them quickly? Can I figure out okay? What packages actually have s bombs associated with them what have salsa attestations or something? But at the same time what don't have salsa and s bombs so we can find all this information very quickly So if you're starting off in a journey if you're just like, oh, I'm just generating s bombs. I'm just generating Attestations I want to store them somewhere that I can query them quickly and also at the same time utilize all the information within them to make actual decisions but at the same time do it because I'm expanding my Supply chain I can figure out now what other packages that don't have these s bombs and attestations and what what we're wanting to do next to Generate them and so forth So let me start off We're gonna be switching back and forth between the slides between the slides and the actual demo So so I'm gonna come here. So what I'm gonna show off here is What we're gonna do is I'm gonna have multiple components of guac running on separate terminals In reality and when you actually use it in in the you know in your demo in demo environment or wherever you want to use it We have a docker compose as well as a helm chart So all this stuff will come up for you automatically, but I want to show them off individually just to highlight all the different features and so forth So the first thing I'm gonna kick off is this Just stream that that's just stream. So that's the pub sub Layer on top of it and we're working to you know, I think people have like other pub subs They might already be using so we're looking to see if there's we could replace that or make it modular. So and so forth So the first piece I'm gonna click off here is just the graph database itself, right? So this is the graph QL layer, which is going to be the in-memory database. I'm just kicking that off What it does is also it's gonna kick off this And let me switch over to it. It's here So it's also kicks off this playground area, which are where I can query more information and so forth And we'll get back to this later on in the demo So going back to the terminal the next thing I'm going to kick off is the ingestion piece So this is the the guac ingestion. So this kind of takes all the information that aggregates from everywhere and Ingest that into the graph database So it takes all the vast bombs and salsa attestations breaks them down into individual components and nodes and edges and puts that into the database The collector subscriber is another service. Like I said, this is all individual peaches I want to show off individually, but you don't have to be thinking about this or worrying about them This is all like in the background, but I'm just kicking them off individually just to talk about them So this specific service basically allows us to Allows guac to be the dynamic database basically like like what Mihai was saying, right? It's not just static We want to see if there's more information out there via depths.deb OSV or some other third-party Provider grab that information and ingest that into the database to expand out your view of the knowledge of the supply chain So here I'm going to kick off the depths.deb collector, right? So it's going to reach out to depths.deb and pulling all the information that it can This one is the OSV one that I spoke about the OSV certifier So it's going to go in and check the OSV database to see if there are any vulnerabilities associated with the various packages That I'm ingesting and automatically certify them And that's we kicked off. This is the visualizer And for some reason it crashed so this is the demo gods, of course And there we go. So it's running So all good. Yes So the first thing I'm going to do is I have we have this repository guac data and in there is a bunch of XPDX like clone DX, sol sata station, so forth There's various things in there that we want to start ingesting So I'm just going to kick that off and right away We can come back to this other view here and you can see the ingester Automatically picking up all these things and you can see the various things various different things that it's trying to collect So for example, there is a has as bomb. There's a salsa attestation There's certified vulnerability and so forth So it's taking all this information and breaking it out into into individual nodes and edges automatically for you Whether it's XPDX, Cyclone DX, salsa We want to support other ITE 6 in total attestations and so forth. So that's all in the works So let me before I move on so let me kick off the thing to premise it So let's say for example, I want to query This thing So it went I was a little bit too slow So what was supposed to happen here in this demo was basically I was I knew this specific package is Is a dependency on one of my one of my S-bombs? And I automatically when I ingested it It went out to depth.dev and depth.dead knew about it and it knew that there was a source information There's a source the source of it was this this URL here And it found that information and it put that into my database automatically for me at the same time the Once I come back to it a little bit later The the certifier is also going to run and it's going to tell me Oh, there's is there a vulnerability to associate with it or not, right? So it's going to be continuously doing this in the background for us at all times So even so for example, right, we have timestamps on all these vulnerability certifications So let's say, you know, you said it depending on what the user wants They can set it for you know a day or a week or an hour And it'll go back and recheck to see if the package now is vulnerable or not, right? So you're not sitting there like oh, I checked it once you can recheck it again and again And I'll keep updating the information for you so Now that I missed that step let me keep moving forward so we see in there So let me show here this piece so what I'm going to query here and This is one of the various integrations we have via graph QL This is the CLI that we have this this is one of the queries we have It's just called known query known basically tell me everything you know about this pearl and that's what I'm trying to get here So when I run this it tells me okay This this I knew because I actually this is the one I ingested Via the the initial step so it tells me oh The initial thing I was saying is like do I know if I have an S bomb a series series associated with it And where is it located so you can see here the S bomb download location is there That's where I that's where I were it initially ingested it from and this could be like an S3 bucket We did it from a local file store, but we can do it from an S3 bucket or Google cloud bucket wherever else kind of thing So we have various collectors from there We're also thinking about doing the Having like an evidence store where you can like store the S bombs and attestations at a later date If you wanted to collect them, but that's an upcoming feature and then here I want to show So this other thing I want to show is like at the same time, right? It's not just about packages and URLs It's also about you know source repositories. It can also be about specific artifact and specific hashes So here I'm gonna run this Like this if you look at this this is the exact same package that I carried up here this is that source that I showed that I Dependent package that I knew about and I queried for it and it's like oh here's a source This is the source associated with that specific package and then that can go query that specific source now and tell me more information about that source So automatically again, it's found the scorecard information, right? So now you can see there is a scorecard overall scorecard associated with 3.3.6 Which is not very good, right? So maybe you know, maybe we want to move away or maybe we can work with the maintainer to go increase that score So let me go back to these slides here So what I showed off there, right is the hold the depths dot dev piece, right? So like Because it's not a static database because it's trying to work and find more information without you doing anything extra work Right, it's trying to make all these connections automatically for you You know we have Via it's if it's the packages if it's the artifacts if it has more information I'll try to go grab it for you Right now it's depth dot dev I think we have like an OCI integration and we want to add more and more integrations as we can so that's all coming So the next thing I'm going to show off is that vulnerability piece, right? So we showed off the depth dot dev now. What about vulnerabilities, right? The the question that gets asked Is like am I vulnerable to a specific vulnerability, right? So let's let's let's look at that So what I'm going to show off here is So again, I know this is my top level oops So, you know, this is not fake because I'm doing this and Yeah, good. All right back in business. So what this is doing now again, this is another CLI that we have Another integration is okay based on a pearl that I give it, right? Tell me if I'm vulnerable and not just at the package level, but all all of its dependencies if you know if there are Transitive dependencies that are vulnerable. I want to know about it So give me all that information so you can see like a quick output like yeah Here are all the different vulnerability IDs that it that the database knows about and again I didn't do anything extra, right? I just ingested my S bomb. That's all they did from the beginning So there is a visualizer URL you can see down there So I'm going to copy that and you can of course, you know control click to do that also so I'm going to run it over here and Ignore that error There you go So you can see this is on again another Experimental feature that we have is called a guac visualizer and this is more like exploratory You can see exactly what's happening in there Inside your inside, you know the database and so for example, you can see here Is that that image that I kind of generated? I knew you know like there's going to be vulnerabilities in there Especially of course our friend log4j Pokes his head out again, and it's in there so log4j is one of the one of the Vulnerabilities that we see in here at the same time on other of course another big one is the text for shell and they're both Wanderable so you can see exactly how they are vulnerable so you can see this that there's a direct dependency To that specific package and that's how it's vulnerable at the same time Let's say if it's if it's a transitive dependency within another dependency, right? Then we can see that also so it'll show that off and you can find out okay Maybe it's not if I go update this specific package, then I can then I then that vulnerability will go away, right? We also want to this is like a visualizer still very much New and still in the works, so we want to make it easier for like you know So for example, I know that this specific package is bad. I want to know where else is it used right? I want to know where else the specific version of text for shell might be used So this way I know I can go update those quicker so I can click on it and go update that So all those kind of different features we can do right because we had the data for it It's just that we had to have to work on the integrations in the and the visualization so the next thing I want to show off is like You want you know there's a specific vulnerability, right? There's a specific vulnerability associated with If so I know a specific vulnerability ID am I affected by it? Right, so that's what I want to know and is there a path that leads to that specific vulnerability, right? Whether it's transitive or direct dependency, right? So here again, we can do a similar thing is like we can visualize that again Copy this over and we can visualize exactly. Okay, where Where in that path like as I'm as I'm going down Where is it? Where is it affected by you know, is it a transit dependency? What layers do I need to fix what the packages do I need to fix to be able to remediate that so again We can visualize that so those are the various integrations and we kind of have You can imagine that in the future when we have also vex integration This would also show yes, that's attached to each node and you can see oh, I'm using this package that has a vulnerability But I'm not actually using the vulnerable part. So I should be okay Exactly. Yep. So vex is another thing. We have an open PR For vex and so we want to start integrating that So right based on this we have a graph QL API and so forth We can do various things right so we can you can do policy checks You can do patch planning like we kind of talked about and figure out okay Where where are the critical things that we need to go fix quickly? So again, let's let's do a couple more demos here So the next thing I'm going to show off is for example Oh, I did miss this one thing. So I'm going to show this off here real quick is I did not show off the salsa piece so I want to show that off and Orientation because it's such so large is kind of getting messed up But again, you know, we ingested the salsa attestation I think later on me how we'll kind of go into kind of showing off more details about what it ingested But for now we know that this specific there is an assaults attestation associated with it And you see the package URL as a guac generic, right? So that's that's we're inferring the package right now, but that's going to get get modified once the you know once salsa gets updated to use the Resource descriptor type Which will include a lot more information. So this way then it won't be inferred. So it'll give you much more accurate information And again, you can visualize and so forth. I'll go ahead. So you mentioned you ingested salsa attestation, what did you mean by that? So we ingested into into the graph database itself So all the parameters and all the predicate all the various attributes of the predicate and so forth are part of this So you can use it as a for policies and so forth. So is that separate from the S bomb is that or is that Is that attestation part of this bomb? So it's so it's separate from the S bomb, right? So the salsa attestation has an artifact, right? It's based on a hash usually So it's going to be connected to the package via the hash that's associated with it So when you query kind of like I want to know something more about this package, right? The package could also have an S bomb You could also have an attestation salsa attestation associated with it and so forth So the attestation graph is separate from the S bomb graph No, they get linked. So the documents itself you can do an LS on the documents The document itself is separate. It's a separate file that gets ingested, but you link one. Yeah As soon as it gets ingested, it's all one graph. Yes. Yeah So the next thing I kind of want to show off here is for example Right, I want to be able to certify bad and I'm getting that that error again So what I'm going to show off So here the next thing I want to show off is the For example, you know, you know in the news or something cams up Maybe be a threat or something that a specific package might be bad or a specific source might be bad or an artifact Might be bad. So I want to be like I want to certify this bad meaning that I I don't want anybody to be using this thing And then at the same time Then figure out, okay, where am I using this? We're what what else depends on that specific package or source or something that I need to go modify right away Because I know that it's bad and right now we're doing this manually for demo purposes but you can imagine this being like a Threat feed kind of coming in and giving you this kind of information and I think counterfactuals if you want to explain that Yeah, I'll get to that later. Okay, sure So I'm just gonna do this again manually. So I'm just certifying the log for J1 bad, right? Of course, and then I'm going to certify this specific source bad So I just kind of want to show off. Okay. What kind of what do we see out of this? All right, so what I'll do is I'll run the last query that we have it's called query bad Original name, right? So this is gonna be you can choose now, right? You can choose the information like just to make it simple for the user We have like a drop down here and you can choose. Okay, which certify bad did I ingest? So in this case, I want to see log for J. So what this actually outputs is going to be the reverse kind of graph, right? So it's gonna be okay. I This is the thing that is bad And what do I need to go update kind of thing work? What depends on this? So right again because I ingested that bad vulnerability That image that had that log for J and that's the only one luckily We can see that. Okay. This is the only one that I need to go update So that specific image that I have is the one that's using log for J and to go update that Similarly, let's do it for that that source one now. So again, if I query bad, I clicked on the source So you can see a bunch more output here copy this drop here and This gives back a bunch of things. So again, you see that that node here That certify bad that I just generated manually and you can see that here are a bunch of other things Other nodes we have called has source that and all these packages down here are all considered They're all they're all coming from that source. So now I know oh, these are the packages that are actually bad And I need to be worried about them. So again, like I was saying we could always You can dig in deeper like, you know, we want to make it so that you can click on that Click on that node again figure out where else am I dependent on that where else do I need to update it? They can also do like a json output. So you can you can be like, okay Now I know this is the bad thing where can I use this in another query or another policy environment or something that I can figure out Okay, what do I need to go update quickly? So you can use this for example into scenarios one is there is a vulnerability under embargo You want to see how much you are affected before you Drag people into fix it. You can certify bad the node about that vulnerability the package And then you get the blast radius and the other scenario is let's say you discover you find out from news that Some CICD system has been compromised and you want to see okay, maybe this entire repository is compromised I want to see how do I use that repository in my organization? I certify bad that source and then I see the entire best radius and lastly what we want to say as One of the cool kind of integrations you can think about is we kind of shifting left right now We have all this knowledge graph. How can we you know help the developers upstream right before it reaches? You know some kind of a policy engine can we make this information available to them quicker? So what this is showing is kind of like we can have like a VS code plugin that utilizes some of these queries that we have in Realizes the information that we have within the graph database to be like oh this you know For example here is like a specific hash right this that we know that this specific hash is actually either certified bad Or might contain a vulnerability and so forth so don't actually use this right maybe use something else So giving that information quicker the whole whole mentality of shifting left So this these are the things that we kind of want to do as we go forward with the project So all the demos that you that you have seen so far are based on the graphical interface of guac So we try to make guac as modular as possible all the components of it can be replaced if needed or can be extended So going from the bottom up we have in integrations with different other projects in the open source ecosystem in the supply chain ecosystem you have like Different documentation different formats for attestations We have a collectors and you can write different collectors So for example if you want to collect data from an S3 bucket or from an internal data store data lake and so on You can write your collector and it starts ingesting documents from there After the documents are collected they need to be parsed and translated into the vocabulary that Guac uses to ingest into the database So you can write your own parser like if your own company has a different format for specifying the dependency between packages or Anything like this you write your parser for that you link it to guac and it can work This also helped us so salsa just released version 1.0 recently It was just a few lines of code for us to change and now we support all versions of salsa So 0.1 0.2 1.0 without any big change in the entirety of guac And we have a roadmap in the future to actually not even need to recompile guac when salsa changes or any other format changes We'll do basically some predicate dictionary whenever you see this in the format this is how you should parse it and Then once you get the to the database to put stuff into the database This is also handled via the graphical interface so right now for the demos we have used an in-memory database but as the roadmap in the future we want to do more persistent stuff and Initially we started with Neo4j for the initial demo, but now you can switch to any other database you want so if you want ArangoDB or let's say Spanner or something like that you can write the resolvers for that and use that and finally on top On top of that we can build Applications on top of guac. So we have shown you the visualizer We are going to improve the UI and so on but that's a demo that you can use that you can write your own tools either use the CLI or write your own IDE plugins and so on and even we can even use the GraphQL client that is available from the GraphQL server and the general flow that we envision is You want to experiment with some new idea You first use the GraphQL client and you experiment with that so I can show a quick demo of that Sorry Yeah, so this playground here Okay, so we can have the documentation for the entire graph for the entire guac knowledge semantic Knowledge, but we can also run some queries. So for example, I'm running a query to see what all of my dependencies are and I have Run the query I specify. These are the fields that I want to receive and in this case the first thing that I get is a dependency for this Docker is This dependent package this Gorung and I get all of the information because that's what I specified in the GraphQL query But maybe for my application that I want to build on top of guac I don't need all of these fields. So I can delete some of them. I can integrate more I can use the documentation directly from this Once I am satisfied with the playground I can then write an application a CLI or a plug-in for some product And I have that at scale that works on the my entire database Going back Okay, so for the roadmap I already hinted that we want a persistent database and actually we want the community to tell us like this is the database format that we probably want to use and We can work together to get to integrate support for all of them another thing that we want to do is harden the ingestion Start ingesting your documents into your local instance of guac whenever there is a problem report the issue for us We know that all the s bombs that are generated are not always complete and sometimes one is bomb I contain some information in one field in other place. It might contain it differently We want to validate all of our assumptions and make sure that we can adjust all type of documents Another thing that we want to do is associate identity for every attestation that we ingest such that later You can imagine somebody certifies bad one package. Somebody says that this package is vulnerable to some dependency some other attestation says no, it's not vulnerable we detect this conflict and But using the identities we can decide okay I'm going to trust more this attestation because this person has more reputation this organization has a bigger reputation the other one that Gave a false attestation. I can look to see what else they attested in my graph and I can see the entire blast radius from them Maybe discard all of their attestations So like we said the back support You know coming back it's like okay am I vulnerable to a specific package is the package You know does it have the in the execution path is it vulnerable is it so it's not then we have x and so forth So that's coming the license information. There's been a lot of requests for this So, you know, either it's from the s bombs or from other third-party sources Get the actual license information into the graph database I te six this is in total attestation types, right? There's various intuitive attestation types, you know There's one time there's sky and so forth So getting all that stuff ingested and the predicate dictionary like me I mentioned right so that would make it easy easier for us or not recompiling right so we can if news new Types of attestations come out we can support that via the predicate dictionary The evidence store evidence store like I spoke about briefly is like can we you know if you want to store the s bombs and Other attestations in like an evidence store that you can quickly go query and pull up the information That's also possible and we want to do that and then yeah the GraphQL interface right because it's so flexible We want to keep expanding the integrations, right? We want to do the policy engines the VS code plugin like I showed create more more CLI tools update the UI and so forth and you know just And if there are more queries that people would like to see you know We had we did we showed some simple queries here But if there's more queries that people would like to see you can get that integrated and and the third party tools can start Utilizing them without having to do their own implementation yeah, and we are going to do a better list for walk very soon and The There will be like the block the Repository will be tagged and you can then see the guac documentation the go documentation and so on We have a monthly community meeting. There is one actually next week on Thursday I have a link there and you can also watch the previous community meetings on the YouTube channel We have a slack channel where everyone can join and the mailing list that we would expect to get more activity and Basically, we want to build a full ecosystem on application build the top of guac We have our documentation website that just got put up and should be ready for the better release It's part of the better release process If you discover any issues any new features that you want to do please report us to github Or to slack channel to the mailing list. We always welcome those we are open for any PRs and Looking for advice for contributors and tech advisory members and you can scan the QR code to get to the repository where we have All of this information. I keep forgetting there You mentioned your dependency on pearl So how Important is it that you have pearl references for the entire graph? What because all of libraries may not have So is that a problem? so we tried to ingest dependency first just using salsa and we discovered that there are a lot of gaps and Sometimes the name wouldn't match what the repository was for the source so we couldn't get the scorecards information Now that we integrate with devs.dev We can get access to the entire ecosystem that devs.dev handle so for example if we have let's say tensorflow We get all of the tensorflow Python packages from setup.py That devs.dev ingest and everything that is associated with them the source repository the scorecards and so on and Then for the C++ if we don't use devs.dev We will have to actually handle Okay, tensorflow is built using basal the dependencies for C++ are specified in this way in basal We would have to write our own parser. It will be much much more work With devs.dev if devs.dev would have C++ dependency information We can just get the information from there and go to the repository and so on So so pearls like we're kind of pseudo pearls kind of thing So we're guac is kind of using its own kind of format for the pearls So we are ingesting We created in that format so that it's easier for to search and so forth But if we can't it like I said like if you saw it before there's a generic package if you remember It tries to create the based on the name if it can find it more information It'll try to generate its own type of package so that we can keep track of it inside again within guac We also have another another relationship type called Like packages similar kind of thing so for example later on down the line you figure out Oh, this is the actual pearl the actual pearl for this specific package So now my the one you kind of generated automatically you can link it together So like now I think now if it searches for a specific package with a specific pearl or for the old one You get all the information you knew before so you can you can go back track that information I mean there is talk about hardware bombs now. Yes They use software ID tags So do you use pearls? That's WIDs interchangeably in your graphs So I think we haven't looked into the hardware piece, but I think that's something we definitely want to look at So I think that's something we'll have to get back to you on that So what we do each time we parse a document we try to interpret that document into the guac ontology and into the graph Well guac vocabulary and we can get like okay This is the tree for this artifact from from this pearl our pseudo pearl in guac This is how it would look like or for an artifact identified by a check some it's identified Let's say by shot 256 and then later on in just another document that talks about the same thing Even if it's identified by something else We can also ingest an attestation that says these two things are similar and this identity provides Evidence that these two things mean the same thing Depending on that hash Word format right what spec it is Well, thanks I noticed the the clay you're using is called guaconi. Is that some suggestion of like a guac slash macaroni culinary crime or something like that? So it's supposed to be guac all in one, but you can also interpret it as guacone No, it's a serious question with the roadmap stuff Is there any particular project that needs more help or with the call to action like what's the priority amongst those? Where where can we help? So I think the persistent database I think we want to get that I think that's probably the one of the most important features Probably people put the community would like to see so I think we want to you know figure out Okay, what is the best database that people want to use? And then I think the second piece of course the hardening the ingestion So try it out and let us know if there are you know ingestion issues create issues or you know Create open PRs and try to fix them yourself. So we welcome that I think those are two main ones and then of course and then identity at any and trust I guess it's a day for Australians to ask questions Can't tell that Well, I'm wearing blundestones actually Yeah, sorry, I win. Okay. That's enough Australian inside humor. Um, yeah, what happens when the documents change? So I have my sulfur Attestations being ingested my S-bombs being ingested what happens when they change and I get conflicting information So right now we have we store for every edge the type of note We also store which document provided it. So when the new document comes in we'll have a pointer to the new one And we plan to do like some scanner that will look over the database and identify conflicting information Counterfactuals and once you identify that we can detect. Okay, there are two documents that provide this information They the information they provide is conflicting the second document is newer the old document is old We can delete everything that was pointed to from the old document and give only the new one Yeah, and we can show that to the user for the user to decide right if they what they trust more like it Maybe the new document is coming from a bad source or a bad trust right then we can delete that Yeah And I think one other thing that we're looking at and then we're very interested in the space is a sort of the Bitemporal sort of databases right where hey we can potentially also go back in time So you can say yep new data has invalidated the old data, but Like for compliance and audit reasons, you know When we deployed this piece of software we actually weren't aware of this vulnerability when it existed and we can actually look You know one of our goals and on the road map is is going to be going back in time and seeing like what can we What can we tell you know, what what info what do we know when is Important any other questions Back I guess I had a question that was very similar on If you're ingesting two different s bombs for different versions of your software Do you have any capability to do analysis on the differences and what may have come up? Yeah, so we store both the s-bom so that if the s-bom got stored we know okay There are two different versions of the s-bom and then you can do some So for the package basically we have okay. Where did that? Where did this package come from a top-level package? It came from you know this to us there has to s-bom associated with it And then there could be two different ways to traverse the gaff so that's possible. Yeah Yeah, and another thing on that is also if you actually like look into each individual evidence or dependency actually tells you like How did we end up coming out of this? If you query all the dependencies you can make your own judgment on Today today we have information like okay. This came from this spdx s-bomb this came from this cycle DX s-bomb You know you can trust which tool was the one that created it What we're trying to do is also trying to get S-bomb generators to also provide more information on how they derived it and also kind of like, you know There's a lot of talk about like oh, what's this done during the build was this done during analysis What's this for the soft code that you derived it and so like each of them have like different Different information available and then you want to be able to analyze that any other questions So I just want to show off the this documentation site You can go in and find you know all the docs that are associated with it and all the different use cases that we kind of showed off today They're all in there So if you kind of want to run it yourself let us know and and you know, I think this is this is a good meme right here and then Another one is I had to delete the pictures for copyright reasons, but you can imagine Bruce Wayne and What's his name? Talking here about s-bombs. So Thank you so much