 Hello everyone, all right, so I think we're about to start The question today is why is there no free software vulnerability database and I'll be your commenter together with with my current dog. We Both work in a small company called next be and we deal with Software composition is primarily so the question really is why is there are no free? Voluntary database, right? Why? and weirdly enough the database in that space are mostly proprietary and privately maintained And it's surprising because most of the information you find in these database are about free and open source software code and It would make sense that the data about free and open source software code be up in itself and so we'll discuss a bit the the specifics and I'll present you how we're working to build series of tools which are themselves free and open source to build a free and open source and open data database of open source component vulnerabilities And hopefully the the benefits will be in pro security and for software applications using open tools and open data for everyone so One way to think of it is there's no reason to put the tax on oxygen especially in this time where This is really important and I feel really that Putting a tax by having only proper resolution for our security is a bit like if you were to put the tax on oxygen By the way, so while we where we talk don't hesitate to Put questions in the Q&A system Michael is not trying those. I'm watching them too Oppose any time if you have questions Otherwise we'll try to answer them all at the end As you go Okay, you're probably aware that Components with a non vulnerability, so that means there's a non bug which could be exploited and Be a threat to the main to the the integrity and the security of a software application is is one of the The top 10 OWASP. It's the open web application security project Consider as one of the top 10 most critical application security risk And there's been a lot of widely publicized breach around the open SSL struts And the likes over the last couple years The thing is that it's surprisingly difficult to to to actually identify which of the software packages That you have that are a Subject to these vulnerabilities and and the server reason one of them is that most of the tools and database I've historically been designed primarily for use with proprietary software components for instance Is there a bug in Adobe acrobat or is there a bug in Windows? And that could have a secret impact And so that's one thing the other thing is that the the the data source has not very comprehensive most of the time It's it's difficult because as you may know, there's tens of millions of open source repository on github you have hundreds of thousands of Python Java script node Java packages in each of these repository and in aggregates millions and millions of versions and And There's no really easy way to get at the data for real all of these you have in some case package repositories but the information is really scattered in many places and You have these efforts from the Department of Commerce and the NTI and the US called the National Granted Database or NVD Which is trying to aggregate and has been doing a great job for a very long period of time To aggregate all the data about known vulnerabilities of software package. It's actually The problem there is that it's dependent on on voluntary submissions And you have two cases or you may not be aware of that that you may not submit anything Or you may not want to publicize your security issues there maybe because they still need to be worked out and It's a bit especially true for smaller projects when This information may not be really available so basically as We see more and more free software being used as the essential building block of all the software we use today we need a way to efficiently identify Which first package we have and what are the security vulnerabilities such that we can weed out at least an easy most likely easy win to Identify potential security issues. There's many other Areas to work on for security, but at least that's the way I see it fairly low hanging fruit that that we could attack and ideally The approach should be based as I said, we're talking about free and open source software The approach the tools and the data all of that should be based on the pandala and free software tools All right, so let's dive a bit now a bit more in details on the NVD So it's been maintained by the US Department of Commerce. They they've contracted. I think MITRE cooperation to help them specifically on the curation of incoming vulnerabilities so they can be reviewed scored eventually Enriched with extrameter data But one of the things that's pretty typical there is It reflects very commercial vendor-centric point of view When you think about security a very simple example each Package is identified with something called a CP Which I think stands for common platform enumeration or common product enumeration and one of the essential key In this product identifier is a vendor identifier Which makes a lot of sense if you think about Adobe Acrobatrider, so Adobe being the vendor acrobatrider being the product or Microsoft Windows 95 Microsoft being the vendor Windows being the product makes a lot of sense to a vendor It doesn't really make a lot of sense when you think about a package an open source package If you're using it in the context of a Linux distro is the distro the vendor or is it the packageer Do you care about upstream? Is this something you've used and built from source there's Many different things and really are you using a force is it patch all these matter a lot from a security perspective And not on that none of that is really captured easily in this notion of a vendor So the other thing is that there's a lot of impedance mismatch also between that naming a convention for Identifying software components and and what software developers think about you know if I'm building a node-based application using JavaScript, I think about The name and the version of my package and maybe just the name and not even the version. Maybe I using the latest I Can think in terms of package be they rpm debiancy if I'm thinking about on the distro but hardly think in the The same way I would think about large commercial software components and There's also single so is that there's there's a lot of data which are of much less of interest to us when you When I mean us, I mean when we do software development using components Which are heavily and essentially based on open source software such as hardware notes I'm sure it's very interesting for a software researcher to know. There's a hardware vulnerability in a Cisco router But that's not super useful When you build a Java based application And as we said earlier, there's two issues in terms of the data first it's Contribution based on vulnerability contribution voluntary contribution, sorry, so that's the first problem So we don't have the full subset the full set of non vulnerabilities only a subset There's several sources that may not be covered there You could very much have had the bug that was entered on the bug tracker which happened to be tagged their secret issue It was fixed and closed that security issue will go unnoticed maybe except in a changelog and You may not be aware That you're using an older version and there's a newer version that has a security fixed Secret issue fixed and and so that that can go unnoticed and again That's a difficult thing to have all these sources of data being aggregated and the other thing is that there's a this cottage industry or more than a cottage industry of commercial vulnerability at that aggregation industry and they tend to Fragments also the problem even more because they're trying to bring their own secret So saying oh, we have our own vulnerabilities, which are very unique and you can only get a get these Validities they're not public you have to get them from us and you can really only make Leverage these if you buy a subscription to our services, which which again, I think is I Understand the impetus from a commercial development perspective, but I think from a strict Perspective of security this is detrimental to the overall security it's detrimental to the open source community at large It's definitely detrimental to the software industry so What would be a solution so? element of the solution would be to Independently aggregate many software vulnerability to the source In a way, that's based on open source code and that can be recreated if needed in the decentralized fashion and That can also be easily if we build that that is was centrally easily distributed replicated mirrored without any restrictions and We've also thought about having a Difference and More useful more useful from a software developers perspective Way to uniformly identify software packages and it's something called package URLs That's something you can see on gdub. It's an initiative that started a couple years ago The problem was simply to say how can I identify a package in The simplest way Whether it's a node package a devian package a pi pi package and so on and we came with a very simple solution That's been adopted by a wasp couple projects like the check and fancy track adopted by sonar types and and I think there's been discussion that Red Hat open site of a yeah open shift. Sorry And and a few other places there's discussion to use it in spdx There's even discussion at the NTIA to use that as an identifier as a future replacement for the common platform in the enumeration So that's a second element aggregate that are second element an identifier that you can easily to relate easily relate to and that can be Used uniformly across all the different package types And that's something that's really easy for a software developer to relate to and the third element is Automating the search for non-package vulnerabilities And it's really enabled by by this this uniform package identifier and last but that's for later Is to actually crowdsource and peer review the classification and the tagging of these These vulnerabilities and that's really important because some things may be really noisy and there's an incentive for commercial vendors to have the bigger larger Most comprehensive database of everything so there's an incentive to have more Information and more data items in the database Now that means also there's more false positives more noise You could have for instance the vulnerability highly rated Which is only There's one for instance on Django, which is a web application framework on Python It's spread it as a top-level security criticality severity and It only Is triggered if you run in production This web application framework in debug mode, which is something you seldom ever do that would be a big mistake And okay, if you do that then effectively you're in debug mode You are putting the whole the whole box to the outside world But that's something rare and that's probably not something you would want to have flag systematically each time you have a Detection of Django being used as a Python application In any kind of in any kind of web application, which is pretty common package So it's important to be able to review and crowdsource this peer review All the vendors in that space will tell you but no, you know, it's really a lot of work to do this review It's complicated. It requires highly special skills In practice, I think it's something that's possible. I'll come back a bit later on that okay, so the solution I said open and So we're building a tool which is free and open source software to to automate the vulnerability search That's the last element. So you can Find based on that are whether they're based on package manifest or install package database think about an RPM database In your next box or Debian status file Or package manifest like a package that is on or a maven.xml. So being able to Normalize these and find the information that tells you I have this package installed And normalizing that to This package URL so we have a tool open source calls can call toolkit But as I said, there's also a wasp tools which also support the same standard meaning that by supporting this common Identifier for packages, we can build a database that's not only comes with its own pre pre-built Free software tools, but also can be plugged in already right out of the box in existing pretty popular Flaxing tools from the a wasp projects. I think commercial and or open source tools from sonar types and many more Other things we're thinking for the longer term is we're building eventually a graph of how packages and volatility relate to each other and We want to be able to use that to find a new interesting correlations between volatility and software Package that are present in the graph Yeah, so excellent example, so there's a question that just came in and there's effectively Talking about false positive a lot of validity scanners that report distribution packages being vulnerable Even though most of the distribution what they do Is that they apply patches pretty gently and they backboard the fix so they can release it Even though they may not use the latest version of the package And so the question is how do you track the validity fix in this context? The the answer is very simple is that we the package URL We have actually we tracking that in the case of a distro down to the patch level and Not only to the upstream version. So for instance say You have a package URL that will identify open SSL upstream it could be open SL 101g and let's say that the corresponding Debian package Would have a Build a panic tweets build eight which has plans to be Patch for certain wrong emity. We would track that information at that level of detail So we know that this version of the package even though it's the main The same as the main version of open SSL, which has an over on the BT This one doesn't have it because it's been patched and and talking about Not only correlation, so it's interesting to know that it's derived from open SSL as a main version It's also really interesting to know at the very fine level of detail that this is a version that's been fixed We will come down. There's some discussion. We've had with the rest of the team Which is to potentially come down to the level of what is the commit that fixed a given vulnerability that we could track Because when you have that you could even verify some I semi-automatically that if we have a patch that's been applied Does it match the information we have in the diff from the commit that supposed to fix the the bug upstream? So we can discuss a bit more about that in a sec Okay, so package URL The simplest way to understand that is just to look at the few strings the middle PKG column Is the URL scheme if you think about HTTP or HTTPS and Then the rest until the at sign is the namespace and name after the outside the version and there's there's also My new shade to it, but that's the the gist of it You would wonder why do I have a PKG prefix we we've summoned a few of the URL Authorities from the W3C and the white working group They really we commanded us to use a URL prefix to make sure we could register that with yana and And not be having to register many different Schemes otherwise the first situation we're using npm column as a prefix pi pi column and so on so there was an explosion of of URL schemes and so the thing is that we we have a common way to Identify each package manager platform type and ecosystem Even though each of them have their own Their own their own ways and their own convention and the conventions are very similar But they're subtle difference and we're just trying to abstract that it's very easy to understand what this URL means and And they prove very useful. They're very simple and minimalistic in their simplest way So the simple easy you can with a few extensions that you can check in the spec Eventually do complex things down to identifying a file in a package or a specific commit level all that in a simple string and That's been proven pretty useful and pretty pretty popular so far Not only in security, but everywhere where you need to identify packages and understand the origin of a package As I said, so it's already been adopted in OS projects in particular depends check depends track See, it's also using the cyclone DX bomb spec. It's using Considered for using for usage. I think in the next version of the Software product that I exchange SPDX project at the Linux Foundation It's using the tool called art open source for you toolkit In scan code, which is a tool I maintain and a few others And as I said, it's also considered by the NTIA Which has a big effort these days to develop a standard for the software a software bill of material a KS bomb and they're not super happy with Possibilities of the CP and they're considering package URL together with several others as a possible alternative or If not an alternative something that could go along with CPS and and So that's pretty pretty pretty interesting. It was introduced about two and a half three years ago now probably three years in I said it was introduced at first them in 2017, okay and and the good of life system are Not with us. I Don't have access anymore to I cannot click next on the slide deck Okay So I guess we've lost connectivity So I don't know if Michael can you hear me alright? Okay Yeah, I don't seem to have control anymore on the slides That's okay. I can instead maybe share my screen now. Yeah, you've got it. You've got a slide advanced. Oh My slide did advance Yes, I don't have any feedback there. So I don't know where is it right now. I'm looking at the package No, you're on the aggregation by life. Okay aggregation So if you can advance so stay on aggregation for now and I'll I Don't have feedback there on my side I hope I hope I can be heard remotely too Okay, so aggregation So what we do is is is Technically reasonably simple we collect and parse many daft sources in the command data model and that means trying to find the common ground to identify a package we discuss about package URL and identify vulnerabilities and and that's really that's actually something which is surprisingly difficult because Beyond the something called the CV the common vulnerability enumeration, which is the same managed by the national currency database There's a surprising number large number of references to talk about that same vulnerability And as we discussed before it's really important to to have this right because Otherwise you may Reference things that that are either noise or things that you may miss so the way we go about that is building cross references and And eventually this creates some kind of a graph where we reference packages The version that's affected by vulnerability the version where vulnerability is fixed and all the different references and References between packages and eventually references between vulnerabilities themselves so the main source for that are things like Linux distro trackers such as the beyond you want to read out through the h&m 2 And We have different formats either it's custom sometimes CVRF or oval which are two more structured the XML based formats We have application package trackers which provides security information such as for nuggets for us to Ruby gems or NPM and then you have specific project For that provides specific trackers so you have for instance in the case of open SSL upstream You have an XML file which describes all the vulnerabilities known for each of the specific versions of open SSL And again, they may be the same or they may be different from the version of The same package that would be available in the next issue that may be vandals or bundled inside Say I know some kind of security tool that that would be using that So and of course the national ranked PD NVD itself plus and that's a bit less Less of use but that's pretty intuitive when you think of it all the bug trackers of all the packages and the changelogs May contain information that can be really interesting about security, you know Again, you may have a developer that's just enters a ticket saying hey I think we have a problem there and it may be a secret issue and then it's fixed And then you have an entry in the changelog that says oh fix bug foobar, which was security issue And and there this information usually gets lost and you say well, okay It's not a big deal, but if you're using the previous version and you're not aware that there's a new version that has separate effects You don't have a direct incentive to update Especially if together with the security fix is a few feature changes Which means that you have to adapt and update your code You may not want all to update right away if you were to know that there is a Secretly fix that's been updated then you probably would more likely Tackle the issue earlier than not and So on the aggregation side as doesn't Interesting problem actually I have not listed here, which is the notion of license Because Because there's so many commercial interests in this world of Vulnerability is there's a lot of real licensing event for up and data and I Think the Suzee vulnerability feed Is using some kind of non-commercial license which prohibits commercial usage CC buy or yeah, I think it's a CC buy and see of sorts I have to see I don't want to pick on Suzee specifically, but I have that on top of my mind There's a feed of data that's been created by a project called pay up, which is also a commercial company and and they provide Vulnerability data for for Python packages and it's made available under a non-commercial license And we don't want to prohibit commercial usage. You know, I think as I said earlier on Security information about non-vulnerability should be like oxygen We don't want to put any tax on that be it for open source use or commercial use And so we we there was a project Well, not a project. There was at some point of time a company called snake Which is a commercial vendor in the space provided a free and open that I feed under the aphero GPL license Which is a very unpractical license for data in general So it was raising a lot of issues both the fact to have copy that on the one end and to have a software license applied That I made it really impractical to use And they were selling commercial license at the same time for the same data Which is the typical case. So we have also to track The license of each of the data feeds we aggregate because of that. I wish we wouldn't have to do that But that's a fact of life So we can be sure in the end that the the overall aggregates Is under license that's freely redistributable and that's well known and that's There's clear provenance and tracing of all the data item we have and that when we'll start working on creation And including peer review That also there's no ambiguity about the provenance of that data and frankly that's really something I was expecting to Avoid entirely but we ended up having to track the data item license At least at the source level Okay On the data Yes, that I'm all that I was about to say that I'm all and again, I don't have feedback at all on my side. So that I'm all The data is mother is extremely simple It has evolved a beat and we have a lot of discussion on a regular basis to evolve it and change it But it's actually you have a notion of some kind of abstract vulnerability on the upper left And you have many vulnerability references Each of them are essentially The source a reference ID and a URL you could think about a CV As coming from the NVIDIA as a source you have CV 2020 1234 as a reference ID and eventually a URL that points exactly to that vulnerability record would be an example of reference And and that way we can have many of these references as many as needed There's been a fashion I guess in the security world to create many of these IDs so red hats, for instance has the RHSA Red Hat Security Advisory to use a three or four letters prefix and then a number It's something that's been for whatever reason very fashionable very popular among Security vulnerability you end up having for a security issues a lot of different references what you don't see here things about scoring and There's a standard From the national granted the base which is called CV SS the common vulnerability scoring system There's different versions of that The interesting thing is that scoring a vulnerability is really something which is a highly subjective And you can see the same vulnerability with the same scoring system being scored differently At the NVIDIA or by a vendor So it's important we're also tracking starting to track now all these scores and The different values you can have and eventually will come with our own to join the party because you know if there's many scores We're not have one more. That's a joke But eventually we want to have committee reviewed peer reviewed scoring But the thing is we we also have to track all these front systems and then on the right side You have package and package reference with package URLs and eventually you you may have Package that has many different package URLs because it may leave exactly the same in different place or it may be an entirely different package That's related to the same vulnerability and in between the two in the middle very simply you want to track What's the impacted package? What's the result package? In most case What you care is really these two information in middle. I have a package URL Which is a known package I use be it an application of system package And I want to know what's my impacted and resolved package All right, if we want to go to the next slide, I guess Yeah, I put the next Yeah, we're on vulnerable code Yeah So the the project is called vulnerable code It's available on github. There's a channel on gear. That's also available through IRC if you want to join And Weirdly enough It's been into one not really now, but interestingly enough. It's been partially so it's partially Supported and funded by next be to the US base company Where post Michael my work. It's also we've received the grant from the European Union through the NL nets which is a non-profit foundation for the development of security and the internet in Holland and And we're also We're supported by internships to the world summer of code program and We're starting to reach level where the code and the data will Will start to be usable and quite quite quite quite usable pretty soon And if we go to the next slide So the features we're yeah, the features here is a What we're looking for is search very simply you have a package URL which says I use Food at one and I want to know is it vulnerable Does it has a number on T what what days are? What is the severity of that vulnerability? What's the version to fix again? That's very simple question, but rarely enough It's super hard to get an easy and free Spencer today In the future we're looking and we've discussed also with a few other projects about finding out Which commits introduced a bug and which commit as a fix or Something which would be interesting, which is is this code they beat in source of only be format Is it vulnerable and and provide something down to the level of the arrow the same way with Snort Or if you think about open vast where you have Detection systems actually necessary snort snort You have raw systems Typically focused on network traffic here What would be interesting is have a set of Yarra rule which is a tool from Google and open source tool to discover patterns and various like malware in code Being able to identify Is this piece of code vulnerable think about the example I gave earlier on for Django, so say we find you have Django in your code base Let us version happens to be vulnerable like every other version with a super dangerous Thing which is if you run Django in debug mode Then you're subject to that's wrong with you now If we have a rule which is able to check Not only that you have Django, but check your settings files and check whether the debug flag is turned on or off Then if we can identify it's turned on we can say okay, just do one tip a lie if it's turned off No noise no report of the room team no flagging whatsoever, and I think that's that's not something you can automate Right, maybe there's a few helpers we can have but in the end it's it's about creating this manually so the power of The committee coming together to help generate these we're not talking about crazy volumes probably a couple hundreds Day at most and probably much less than that So if you want to go to the last slide the next slide on the curation Yeah, yeah, so which is what I talked earlier on so we want to expose this data with a public correction queue for everyone to review and you have a lot of security researchers which are working on these on the on the daily basis and Rather than doing each of the each of them to work on their own side It's we'd be much better for them to spend the same time, but then it's shared by everyone so where someone spent an hour privately to qualify the security vulnerability of an open source package now if that person spends one hour But contribute that to to everyone we hope that there's a Possible very virtual system where we can really create security commands which are of higher value to everyone And the key question items could be as simply as valid validation Is there really a vulnerability? What are the correct package URLs and getting back to your question of your own? then That could be ensuring that we know that okay open SL 101 G upstream is vulnerable But the Debian package on Ubuntu for 101 G dash 3 is not vulnerable that's the kind of thing and Again, there's potentially ways to automate some of it. That's great if we can automate or automate the max but in practice, this is Not super high volume and complex enough that it's really valuable to have a community and human review and peer review Of this and we talked about commit and year-olds and of course Severity and scoring which which I think can be highly contextual because if you think about to gain this Not fictitious jungle example You have the case where the same package has the same volume team both case and the code Execution pass you have based on settings matters a lot okay Let's go to the challenges Yeah, so At this stage what we have in terms of challenges, there's really a lot of different data sources They're both messy rather than unstructured or structured Mostly incomplete and frankly we came to appreciate the complexity of the task and Why there's commercial vendors that currently dominate the space because it's it's not trivial It feels like a simple data aggregation problem, but it's it's It's it's not easy and there's much more work than we thought that they were originally doesn't means cannot be done And frankly the thing is that yes, there's a lot of data source. They're written on extra messy and incomplete yet Once you've tackled one of these data source and made sense of it There's not much of work extra work to do Beyond reviewing the new items that come in Which is where the creation come in the other thing is that? There's a lot of old obsolete and less useful that are there and it's Further than promoted somehow by the commercial vendors because they always want to be you know have a bigger thing And Here we think it's it's really bigger is not always better Especially who cares about all vulnerabilities on older versions of acrobat or windows, you know So they will make your security database much bigger the likeness they have a practical usefulness today is low So it's noise So for now the stance we're taking is to exclude commercial only software and hardware We may in the future And not more of it in the code or the the data models for prohibits us to do that It's just want to be laser focused on the problems at hand We we're trying to tackle which is open source software Valieties with open data and open code. We brought on the future plans. We're running out of time. Yes so Yeah, so future plans. So we're adding more data source. We are about to establish a website But we also have an API for the convention consumption we're looking in the future also at applying some artificial Intelligence and lightweight machine learning not so much To do any kind of fan system but to spot inconsistencies in the data and and guide the data quality improvements, and so it's more statistics and That then really deep machine learning and AI We'll need to establish a Community creation system and we're trying to reach also to a few free and open source software project or intention again, we don't want to own that in particular we want to work with package management communities With larger projects with foundation just to make the data available to every everyone and eventually being Sourced when it's prime and and had shown shown to everyone that is valuable that that can be a Really valuable community assets to talk to the sustainability and then we'll have a few questions in the queue Yeah, so sustainability So we we're looking at building some kind of consortium to make sure that these data are Sustainably available to everyone for the long run. It's not only for vomittis, but also Everything about software composition analysis And you think about it the keys you want to know where software comes from and then interesting attributes about the Software would be things like What are non-vomittis? What is the license? Are they bugs quality or other things of interest about a software package all that is enabled by being able to Know what is the software origin at first and we've started discussing with other project like fasten and eclipse steady which provides quite a bit of Deep introspection in Java and and Python packages or wasp and again over upstream and package committees Something we want to include once we prime the pump and the system for for everyone to join and That's it. So if you want to join You will be really happy if you want to participate So we had a question about the slides my understanding is the slides will be posted with the conference materials Not exactly sure the timeline for that. If you want them more urgently You can send an email to info at next be calm and we'll be glad to send them right away I NFO at any xp.com and We had a couple questions one question fleet was how do you use the Yara rules? I don't know but also Yara rules is Technically, it's it's it's very simple thing you search for patterns or string think about like a regular expression or In a more sophisticated way like a virus signature Actually, internally Yara is a tool that can recognize many patterns at once like a virus detection tool like Kla maybe or any of commercial virus scanners or Like snort, which is specialized in intrusion detection And so these patterns are small strings which will be text or byte strings and what we want to do there is Create several of these rules that allow to identify either the presence of a specific binary So something we think you have open SSL So there's a version string maybe in a possessor that show up in plain text inside a shared object That could be a way to figure out. Okay using open a cell 1g now. We may be identify able to identify with bite signatures. What is the signature? That has been introduced by a specific bug It's not trivial, you know, it requires eventually reversing understanding exactly the binary code But there's ways to build this kind of rules. That means you know, okay, I know I have open SSL 101g. I know that the code in question That's vulnerable with CV 2020 This and that is not there. It's not present because we don't have the signature for that. It's not for proof It's never perfect, but it's much better than just looking at binary and wondering whether is it good or is it bad? One other question about the package URL, but I think you've fairly well answered that at least as far as we can There's a lot of detail There's a quick note is a question also about So Leonidas is asking if we have some way to tag Standard pattern tag in the way project fixes issues. Well, yeah, so the thing is that Yes, that would be ideal. It's difficult to have each of these communities change their ways and the difficulty is that Security bugs are fixed Not specifically a security bug in many occasions So they just go as part of the regular flow of Fixing also bugs in many case and and therefore if they're not even identified as such Beyond just a change log mention. It's it's hard for ways to To tag and so that now to your point Leonidas one of the way that probably would be the most Prolific if we could find some way to unify Ways on how security issues could be reported would be not to track Role Or every distros I mean each of them have already pretty structures ways which work here at the Linux distro level Let's think about the whole package ecosystem Say bye-bye or maybe Where we can probably work with the package? creators Community and the the authors of the package management tool the maintainer of the package registry to evolve norms That work for that community and that provide better way to to identify this This thing and again to the point. Yes, there's all version numbers in many distros But Very often there's a back port it's but So there's nothing perfect. We hope to the question you've brought up We hope that it does that the data we're bringing together may help In some case when there's all the versions of a package available in this road That's not been back ported that this information is also more readily available without having to look at other distributions or Look up in a national branch database But not being able to find the exact package and and having that that information lost in translation because of the noise All right, if there's any other question Yeah, we're done that he does any questions so So again if you Want to go to the oh I have control again So if you want to go to the vulnerable code project and join the discussion here Let me put that as a last slide that's here and and I Look forward to to having fewer security bags in the future. Thank you very much everyone and have a good day