How to Have Perfect Vulnerability Reports and Still Get Hacked

so this is the last one the best one I hope so the title of this talk is how to have perfect vulnerability reports and still get hagged and our speakers for today is Zach Newman and Luca Guera welcome thank you thank you so welcome and thank you for staying for the last Talk of the day thanks a lot uh so today uh Zack and I will tell you you more about how we can have perfect vulnerability reports and still get hacked because yes we needed someone to explain so I am Luca and I work as a senior engineer at sysdig I during my normal uh work work day I work on a project called Falco that is runtime

Security based but my background is pretty much everything security from security research to engineering so I really feel a bit right at home here at besides and hacker summer camp week so and I have the pleasure today to speak with Zack who is an awesome uh researcher and research scientist at chuard a company that does specialize in supply chain security so a lot of the cool stuff that we'll be talking about today and also uh he he's very expert about crypto where crypto means cryptography so you can take a look at his blogs I I wish could understand half of them so what uh actually are we talking about today so today uh we'll be

of course we'll explain how our vulnerability report can be perfect while we get hacked so in order to do that we'll take a look at how this vulnerability reports are produced so what are the uh what are the tools that we use software composition analysis we know we have heard so much about SS bonds so we'll take a look at that tool and how the whole process works and by understanding how the whole process works we know pretty much where the blind spots are that none of this spoiler none of this technology is perfect but they are actually useful and we so let's get started of course we all love vulnerabilities we all love looking

for them patching them all that stuff and uh if you think about a time when maybe you you weren't you weren't shipping software to production maybe a happier time I'm sure you were happier I was when I wasn't shipping software to production I could ask myself how much vulnerable software I wanted in my production environment and of course I want none why which stupid person would ever have a vulnerable software especially software that you know it is vulnerable in their production environment well as it turns out really in the real world you can't have that uh we all know that you can't have a system that is automatically at the latest and greatest version and and of course we

are not even thinking about zero days we think about vulnerabilities that are very well known to everyone and yet every time we read on Twitter or x that you should patch your system immediately and it's very hard to do in the real world and I just found this uh while I was taking a look at the content for the stock I just found this tweet x uh that that was saying basically that there are environments that run Cent five that are critical business production environments that we rely on somehow so uh yeah it's it gets hard to do the theoretical thing but we're not using Centos s here uh we are we work at Cloud

native companies we all use modern Cloud native environments that um so uh we have containers and so containers are based on the idea that if it works on my machine we'll ship the entire thing as a file system structure and it will work the software will work we got there uh and and we're happy but we're also dragging all the vulnerabilities we have in there within the container and now we don't have to care about the host we have to care about a lot of containers that are potentially vulnerable so how do we even start at keeping track of all these vulnerabilities and everything that we have in our systems well fortunately we got tools we've got

software composition anal are vulnerability scanners uh we've heard about them we probably used them I've used them and I also worked on one so I think uh uh I think we're familiar we're they're PR too much a magic box if we think about the container image uh you take your container image and you just shove them into the magic box and out comes a list of vulnerability of vulnerabilities this is really useful this is awesome because I can take any container that anyone generated even a third party vendor open source whatever I have I just push there and I get the vulnerabilities think about when log for Shell hit you could use open source or

commercial solutions that are pretty mature you would just run it on everything you have uh in your clusters and that would just work but let's take a look at how the magic box wors if you think about it the magic box are actually at least two magic boxes one uh is is a Content detection part so you take the image and you try to figure out what's in there and the second detects the vulnerab is uh the the stuff that is in the middle uh it we call it an asbb software build of materials it's basically a list of things that are contained in our image and in our software so well let's focus on the first part first so content

detection yes that's great how do we do that uh you take the container image and and it's got layers you get a squash file system representation of the layers and your software composition analysis tool will just go and look for any piece of metadata that it can find uh to find the the packages and the dependencies that are installed there so the package go has that embedded in the binary or in if you open a jar file you know that it's basically a glorified zip with stuff inside you might find manest that they may contain uh good information uh but sometimes stuff doesn't well I mean doesn't really go wrong but some stuff cannot be detected here because uh uh we

need for software composition analysis to have enough metadata in there in order to you know find what this software is and if it exist and it didn't make into the s bomb then uh it's like uh um our our friends at shenard has going the term for this that is softare dark matter it's not in the sbone which means that we don't know what it is and we don't know it's there but it's still there so we did uh according to report that Zack would tell us more about uh software Dark Matter composes might compose even more than 60% of the software in an image so uh for me the question is more like do I

care about that is there any piece of software that that I'm actually interested in so let's take a look at an image I got a Pache I scanned it with a software composition anal tool I got my asone it's a bunch of stuff 126 packages categorizes as dbn first of all do I care about the ones that I see yes I do so uh I know that the httpd server is the HTTP binary if I list the dependencies I'll find that basically there's a bunch of the of libraries that are dynamically linked and each and every one of those has a corresponding package so if we find the vulnerability say in the regular expression libraries

I will actually be able to uh to understand that this is vulnerable and it's going to affect my server so I want to know that but if I go back and look at the list of things that are in the image in of the httpd if I some stuff I probably don't care about and we talk about that later but is there anything missing I looked at it and after a while I figured that the httpd software itself is missing like the one thing that I downloaded the image for actually was not there in the list of software that contained that was contained in the image and if you work on this kind of software and if you know how they work

it's actually quite obvious because there's no additional metadata that is put there at build time that actually tells you that this is the httpd server it's probably a binary it's actually a binary that is built with compiler and then it's stuck in the in the image so it doesn't come with any additional thing so we know we know it um the question is what if we build the software build of material as bomb not just by uh running software composition analysis but we could put our own data in there and so here comes the um discussion about esom Zack is a great expert at that so uh thanks Z for telling us more about uh

the espon yeah so the the issues luuka just told us about all had to do with this content detection phase right if we had a perfect list of all the software in our image ahead of time we wouldn't have to do that and that's what the promise of the software bill of materials is um so you can think about software composition analysis the content detection as reverse engineering you go to Taco Bell you eat a quesero you taste it you squeeze it you try to figure out what's in it and then you go home and you try to make the same thing uh but often you don't quite nail it you you it's very very hard to figure out

what exactly is in your container image uh and this is true of food as well uh and so a very overused analogy but overused because it's quite useful is that an esom is an ingredients list for software right it tells you what's in your application what's in your container image and then there's maybe a warning at the bottom it says may contain cve 2014 0160 um and Es bombs can be produced in a number of ways uh one way to do it is exactly like luuka was just saying uh sort of this post Haw software composition analysis um and we do this by looking inside a container image looking at metadata like the uh app uh database on your devian instance

um but you could also Imagine creating one of these lists of ingredients at build time uh why CU that's when you have the most information that's when you know what you're actually putting in there um and so these s bombs will contain package information dependency metadata uh cryptographic hashes of the content so you know exactly what is and what is not in in kind of that um software and so uh here's an example you don't have to read every line of this just trying to give you the flavor of it uh but it's like a text format it tells you some metadata about the format itself that's spdx is one of these formats um tells you kind of okay here's

a repo on you know GitHub that that we're tied to uh it tells you metad at it about who created this so in in this case there's a person that created it there's also a tool that was used to create this and this is just for a very simple hello world kind of binary um it gives you some information about individual packages so in in this case there's just the one package hello bin tells you where the source came from it tells you what the commit was that it came from it tells you the license of it and and so on um and then it tells you a lot about like the dependency relationships within that within that

application it tells you okay you know your package depends on this package depends on that package and and you can embed kind of the whole graph in this plain text format uh which is not very nice to read it's not super human friendly uh but there are tools for kind of visualizing and so on and so where where did these things come from uh for a long time as long as people have been consuming software they've kind of wanted to know what was in it and so uh for a while what we did is we just said hey take take your lowest paid intern give them you know Microsoft Excel and have them like make

a catalog of all the you know libraries that you're installing all the libraries that you're importing um and then you know sometime around 2010 or so uh the spdx group uh formed under the Linux Foundation uh and actually this project wasn't designed with cyber security in mind it was designed for open source license compliance uh and at first blush this might seem unrelated right what a what a licenses have to do with vulnerabilities but the first step in both cases is knowing what's actually inside the application if you're linking against a vulnerable version of open SSL you could have a vulnerability if you're linking against you know a library that's agpl licensed you could have some

legal problems and so after about you know five or six years uh the Cyclone DX project kind of made an initial release and that comes actually out of oasp and so this is interesting because we're starting to see a cyber security focused group really investing s bombs and spdx along the way has picked up a number of features that make it useful for vulnerability analysis uh after a few years of that uh folks started to notice hey it's not actually that useful for you to tell me just this application contains this Library what if they didn't call the vulnerable function what if they you know like it it doesn't give you enough information about exploitability so Vex or vulnerability

exploitability exchange came on the scene around 2019 which lets you mark soft were as affected by a vulnerability not affected by a vulnerability and so on um and then in 2021 uh the US federal government issued an executive order 14028 that says all vendors to US government must provide s bombs and there's some some details on timing and so on but has caused a mad scramble and a billion companies have started uh uh to to solve all your all your organizations esom problems if only you write them a fat check um but missing from all of this I think is a notion of quality uh and so on the right I have an empty nutrition facts label because

maybe that's technically compliant right uh the ntia has has guidance on the minimum elements of an es bomb and it talks about identifiers for components it talks about version numbers it talks about dependency relationships nowhere there does it say that you actually have have to have httpd in your htttp image sbom right um and so Luca alluded briefly to this term software dark matter which is which is a term ter my colleague came up with to kind of uh describe if you have say like a container image uh and you go through the eson for that container image what percentage of files can be explained by that esom ideally you'd want it to be 100% you you'd know you know uh these

things come from the OS and these libraries come from this package and so on uh but actually if you look at popular images on dockerhub you you actually find a majority of files are unexplained they're they're sort of if you run popular scanner tools the scanner tools can't tell you the cause of a number of these packages and there's a couple of reasons why in Luca luga did a good job illustrating some of these uh the big one is that scans are missing software that you're not installing via like a very well defined package manager uh and so if you're if you're cobbling together your container image by you know copying files in from here and copying files in

from there all of those are going to be not accounted for um and any esoms that are coming out build time which is which is kind of my preferred time to be generating these things that is a good way to not have this problem of dark matter but you need a lot of support from the build tooling and that's that takes time to put in place you need your compiler to support it you need your you know you need make to support it you need all of that um so I'm going to turn it back over now to Luca to talk about okay so even imagine we solved all those problems we had a perfect eson that had

all a list of all the software in your container image we done and um you may note by looking at your watches and the fact that we still have some more time on this talk the answer is no thank you Zach so yes uh I really now I imagine I have my perfect test bone either SCA generated or we actually wrote it uh with any build time tooling with any help or a combination of the two now what well now we turn to our vulnerability database and we do the magic so the problem is there are many vulnerability databases and these are just a few you get like the MVD that I'm sure that many of us have looked at uh

we've got some open source some open source Parts like G up and gitlab we got vendors we got paid for vulnerability databases that have their own goals and scope so what's going on there well it means that in your scanner whether it's software composition analysis or vulnerability scanner there's another Magic Box inside that's the magic box that even if you use open source you might not be seeing it but they have the code to deploy it yourself it takes all these databases and squashes them together into one single vulnerability database that can be used to detect and building that dep database it's is much much tricker than we can think so um in in a lot of cases this is great

because if you think about it vendors especially vulnerability um uh sorry uh distribution vendors tell us exactly which vulnerabilities are in their packages and they know it because they maintain the package and they know exactly what to look for so uh that's great and now with uh if you think about GitHub and gitlab for example we have uh package maintainers that can put data in a standard format there in their package so that uh you can take a look and it's written in some format that a scanner can conform to however not everything is uh that great for example we have all we have been speaking about the software package type before if you think about

the Java go whatever we spoke about it but not all software can be uh reconducted somehow to this kind of package types think about the httpd server it's not a you know it's not a good package or it's not anything like that so what do we do there and also we got software that come from vendors so it's not in an open source ecosystem so what you do with them uh and also vulnerability databases are a beast of their own they all have different goals and they're so they're inconsistent from each other because they're slightly different but also between themselves they can be a bit inconsistent so of course let's take a look at an example I

like Concepts but I scan images I want to be sec secure so in order to be secure I scan my psql image and in the s bomb that was generated by SCA I can find pogress so we don't have the HTTP problem uh it's there it's version 15.2 this is great now let's go to the vulnerability checking part so we got eight vulnerab there are actually Four because four of them are just duplicated but that's okay because uh the Debian maintainers that have compiled that security list know what they're doing so if there's two libraries that are affected by the same vulnerability from op SSL they will uh they will Mark both also I really want

to know about this op SSL vulnerable version because I have pogress and pogress is going to connect securely I hope with OP SSL so if there's a bug there I I do really want to know is that is that all no if I go to nvd the National vulnerability database I can take a look that there's a vulnerability with the CV ID and that vulnerability is uh something about pogress itself so uh we had pogress in the sbom uh we had somehow data about the vulnerability but we couldn't match the vulnerability so we don't have it in the scanner output why is that so I also took a look at how the the Asom is generating and what

database I'm looking at and the package here is detected as a d package so Debian software and the scanner knows that it needs to match Debian software with the dean Debian security database does the de Debian security database have information on that vulnerability yes it does but it only applies if the package has been distributed by a de maintainer because this is how it works by contract that database Works only for that and if we take a look at the docker file for that pogress image we find that pretty much the docker file had the AP reple for pogress and not for Debian because of course pogs use their own uh repository meaning that our scanner is

unable to find the vulnerability that sounds sad but you might think I know I know I saw the database before you can't fool me it's there I I know that there is this National vulnerability database database maintained by the US government from nist so it's something that's really in part of standards of the standards body so what it's there it's called POS SQL can I match it maybe can I do some kind of match to find to put that data in there and that's really tempting but and scanners have attempted but it looks like it everything fits in it's it looks perfect like I mean that's great but if you try to focus there you

will notice that it does not and there's no standard way to match information coming from any vulnerability database including MVD just generically with with everything else uh for example I'll give you an example of what I tried to do at some point as usual I tried to do a lot of stuff but we had this or. bouncy castle cryptography library for Java that's called bcpr jdk jdk6 in the Java manifest and it's vulnerable to something and I don't know if you can read it but it says that the CP which is the nvd way of telling you a product name is bouncy castle colum bc- Java it's okay so maybe I can try to match that somehow not sure

what not sure how uh but then I found another vulnerability and it said that the same software had the CP name of bouncy castle and you cannot read it but it says Legion of the bouncy castle Java cryptography API with dashes in the middle and that's the the name so the idea is that uh this database for example has probably not been designed with this purpose in mind and trying to use it just directly to match vulnerabilities it's probably going to end up with a lot of false positives and a lot of problems for whoever uses it so which means that I believe that the information is somehow there we are moving somewhere and uh uh we we have uh

and uh Zack will tell us a bit more about uh as an industry or as a open source project as people that work on these things uh what are the newest uh opportunities that we have what how is it that we can try to improve the situation and what are we experimenting on yeah thanks luga so if you wanted a talk that ended on kind of a doom and glue note you should have gone to an offensive talk uh we're going to we're going to talk through kind of you know Luca mentioned a bunch of problems but I think many of them are if not fully solvable things that we can mitigate um and I'll I'll give you a lightning tour

of some of the most exciting stuff happening in the space uh so the first is that there are some Alternatives that are that are popping up to that nvd uh and so Luca you know I'm not going to show you the same slide again but had bunch of logos you know it's got VB it's got the nvd it's got the Debian you know security advisories github's got its own and competition is actually really really good here especially as the world moves to more and more OSS whether the software products are OSS themselves or they just depend on open source software um you know sort of a a world where we open- Source packages fit really really

nicely into the schemas of these databases is a good thing um and so I think uh the hope is not obviously that we have 20 mutually incompatible databases for ever but rather that we can kind of take the best ideas from each and develop sort of interoperability around that in a way where we can match packages to software really really nicely and so this is this is a great example of where there's some Innovation um there are better links to packages and so one is uh for GitHub security advisories all of these are kind of tied back to Source repositories and if you have Source actually we no longer really have to play this guessing

game around like oh is version you know 1.5.3 hyphen Deb like later than or greater than you know or before this you know 1.5.2 like that's that's a really tough game and if you have the source and you know what source a package was built from you can kind of cut out that that sort of step in the middle another thing that we're doing is is we're sort of evolving so uh nvd as luuka mentioned has these cpes which is their naming scheme for software packages uh there's a couple of Alternatives that are emerging uh there's these package URLs or Pearl and that's this very open-source repository focused uh kind of identifier for a software package inversion uh

there's these software Heritage identifiers these SW IDs that's what you see to the right and that can identify not just you know Source but also specific lines of code which is actually really useful for knowing where a vulnerability is coming from uh and then you have these uh s SW IDs which are uh Gish XML that is not going to fit on my screen so I don't have an example um but another thing I want to talk about is sort of this talk has been largely about false negatives and that's a really really big concern your scanner tool tells you you're all good no vulnerabilities but actually you know you had htpd in there and it's got some

zero you or some well-known severe vulnerability um but the flip side of that problem is false positives and I I argue that these are actually two sides of basically the same coin and so uh my company has a report uh freely available uh don't have to give you your email or anything I think it's kind of interesting where we basically just went out and scanned these like popular images on dockerhub and we said how many if you're using one of these things as kind of the base on which to build your application how many vulnerabilities are you just inheriting like off off the bat um and the answer is often hundreds uh right and so maybe none of these are

exploitable maybe none of them really matter but like wouldn't you rather see that number be zero so you didn't even have to go back and check um and even if you did even if you went and checked all of these and you said okay we're all good we're actually accumulating you know multiple vulnerabilities per day on some of these images on average so it's not that just this one and done it's this kind of ongoing task and I've heard people say you know for every week of time that happens in the real world we have you know 10 engineering weeks that are that are spent investigating the false positive vulnerabilities that are popping up and that's just like really a

ton of work and not sustainable so there's a couple of approaches we can take to kind of get around that um one is to sort of have less stuff in your applications and in your container images and so you can see on the left these are kind of you know just the default images for node python PHP on the right you see the sort of slimmed down versions of these same thing often they're based on uh Alpine Linux which is a Linux drro uh that tends to be pretty minimal in its footprint as opposed to uh one of these you know many of the images on the left are based on you know DB and runtu which are

basically full-blown you know operating systems which come with all of the stuff that you'd want on a server running on its own if you're running in containers ah you can get rid of a lot of it and so you just by doing that you're going down from hundreds to maybe tens or even single digit numbers of vulnerabilities uh but even that you know doesn't get rid of all the false positives and so cytic has some really cool research based on the same technology that powers their open source tool Falco um about hey you have a bunch of vulnerabilities in your images but if we actually look what's going on at runtime these packages you know or like

this code might not even get loaded it might not even exist in your image and so even though your esom says you have this package you're not calling the parts of the code that are that are effective at all um finally we can we can also kind of get better es bombs with sort of uh declarative Builders so one of the things I was saying before is it's really hard to get good information information about the contents of a container image for instance because the build tooling doesn't support it natively uh and if you look so this is an example Docker file just from from the docker official documentation if you look uh it's throwing away information it's actually

getting rid of metadata that's in the image in the sake of trying to you know slim down and and size these Docker files are basically just shell scripts and the output of the shell script is you know an image that's got some stuff installed they're really really easy to write which is great for prototyping and great for getting something out fast uh it's bad for reasoning about especially in an automated machine friendly way uh and one of the big problems is that they're not hermetic and what I mean by that is there are a lot of implicit dependencies if you run this code today and you run it tomorrow you're going to get totally different uh images as the

output why is that because the auntu base image might change out from under you uh because the APT repository gets updated and you're going to get a different version of CA certificates you know tomorrow from what you get to today and so this style this very like imperative shell scripty style of building container images is not super friendly to Reliable s bombs but you can use a declarative Builder and so one example of that is an open source tool called apko that my company works on um that uh is lets you build oci images by basically assembling them from software packages and when you do this you're sort of eliminating that dark matter by Design the only thing that's winding up

in these container images is listed explicitly in the Manifest of packages that get installed if you want extra files on there you have to package them up with a companying metadata first and so this enforces that your esom is complete and it enforces that that esom metadata is accurate and useful and there's a bunch of other benefits to this as well uh the resulting container images are often smaller uh updating libraries is easier uh you get faster builds you get reproducible builds uh it's very friendly to caching and so on and so I think as the tooling gets better and this is just one example you can do the exact same thing for applications you can have sort of you

know GCC maybe producing better metadata you can have uh you know your your package manager for your language producing better metadata and so on and as the as we get improvements here sort of the es bomb quality is going to go up which is going to lead to lots and lots of improvements in not having false positives and also not having false negatives and finally I'm going to just tease some sort of ongoing work uh that that uh my company's working on uh on automated vulnerability analysis and this is based on an insight and we're not the first people to have this by any means that what you're not calling isn't going to hurt you and so uh we have some

tooling for basically taking a vulnerability figuring out what patch fixed that vulnerability uh what functions were vulnerable to that vulnerability if it's only in the function Foo and you don't call Foo maybe you're not worried about it tracing back to entry points in a library and then trying to figure figure out does your application actually call the code that contain the vulnerability or not uh and if it doesn't you might not be vulnerable and that's exactly what something like Vex is for and so we can sort of automatically issue Vex statements and so this is stuff that we're going to publish that's going to be all all open source and I think again it's increasing the granularity it's

increasing sort of the amount of information we have about your application and whether a vulnerability affects it and I think that's that's sort of the overall direction we're moving towards better better quality information and more of it lets us make better decisions uh so I'm going to turn it back over to LCA just to to wrap things up thank you Zach and thank you all for listening to us basically uh I just want to to end uh by saying that the the point of by pretty much repeating the point of what we said basically the fact that we have tools to try and keep track of our vulnerabilities to try and see what we can uh what we should fix what

we should prioritize and all these things but uh the idea is that we have to know how they work and we have to know what is it that we are looking for there's no single or even even like standard combination of things that is going to save us and that is is going to be working for everyone so and yeah of course no open source piece of software no vendor produced the solution will just magic work for every use case uh the idea is that we have seen that software composition is super cool it can do stuff that we need but we need to know when it can work and when it cannot when it cannot detect stuff we have seen

that spom generation at build time is pretty awesome but it's not always possible to do it we should try and in some cases we might even end up with an empty ingredient list so we should be wary of that and vulnerability databases have their flaws they written by humans and you know they they have the things but if we know how they work and if we know what we are looking for we exactly know what's what's going on and we have the we have a lot of things that are happening in in general in in the open source world in the industry that uh we can uh we can look forward to we have seen how for example taking minimal base

images will reduce our risks not always that is possible but it's been a few years since I've been around and I've seen these kind of minimal base images and it's great to see that we are moving moving there and we have seen that runtime insights are actually a pretty nice way to prioritize vulnerabilities because resar say so but it's not a silver bullet you can uh you know it can help and in general uh and we also have bleeding edge research from Academia and from industry that says that hey we can even do function level analysis to try and figure this and get something good out of out of everything and try to make sense out of all this data and uh and at

the end of the day using a tool and just shov this results to Engineers will never work so will absolutely never work so you know your environment better than everyone else and you know which tools will work and by doing that uh you uh you will be able to figure this out and if if you're like me when you're in doubt you just try it and if no tool is useful to you you just do your custom thing which I had to do for my for the open source software that I maintain that's written in C++ so it's very very hard to to make all of this work but we are also moving to to get these things

going thank you so much for listening to us we have I think we have a few minutes for questions so if you have any uh we are we're happy to to know about them also we've got some uh they gave us some extra books for the for the soft that I work work at that's Falco if you ask a question and you're interested you can take this already book thank you [Applause] yes hello um when you talked about the automated the new generation sort of automated analysis tools is any of that looking across the container or is it inside a codebase cuz what happens is like for third party libraries some of the most vulnerable

are endpoint implementation kind of libraries right but a lot of times those are only called or not called as a matter of configuration right like how is this endpoint configured in this deployment and it was very easy to have an islanded code that looks like it's not called but it is called in an as deployed environment yeah so that's a that's a really great question and I think the the trick here when we're automating uh these sorts of things is to be humble about what we can say for sure and what we can't say for sure uh and so the context that uh I I'm sort of talking about is one where we have Source

available for everything which is like really the the best possible situation to be in uh so what you're describing where sort of whether uh function gets called in a vulnerable way or not as a matter of configuration that would get flagged as potentially vulnerable in a system like this because we can't say for sure that it doesn't so if you if you sort of just try to limit what you're doing to just saying what you know for sure that's already enough to get rid of many many false positives which means that we can for the trickier edge cases we can actually spend our human time looking at those as opposed to having our humans spending hours and

hours clicking not affected not affected not affected and have their eyes glaze over before they get to the sort of really more interesting edge cases uh but I think I think in general like what you want is to be able to say what like I I sort of have a vision and this is very long term but for for sort of vulnerabilities as having kind of policies associated with them that's indicate under what circumstances is this exploitable and for being able to propagate that through the through the um whole dependency graph and so if you can say ah this is exploitable when called with you know this string in front of it okay we can we can all the

way track through and say do does there ever any user provided input that gets propagated through that and if you can kind of keep that if you have the source for everything you can kind of propagate backwards from the vulnerability to know if something's affected or not now this is extremely like sci-fi uh and it's not something we're going to do in the next you know year or two but I I think as these vulnerability databases get better we're going to see increasing levels of sophistication in sort of the exploitability conditions and how those are described and so my hope is that eventually we'll be able to handle cases like the one that you're saying and this

sort of end to end graph CU a vulnerability really only exists at runtime right and so uh at runtime is kind of the only place we can make we can rule certain things out beforehand but we can't say for sure whether something is or isn't affected until we have all that information um so no answers you know firm today but but I think in the long run yeah that this sort of whole Space is moving in a direction of being able to render verdicts in cases like that any more questions uh hi so I recently completed my graduation and it's only been three months of working for me so yeah like pretty new to uh cve what I have noticed

in my company I will not take a company name right now but what I have noticed is that we do Edge buom and sbom we get from the vendors and we are doing the black duck scan so we get like all the CV which are there all the high they fix but they keep the same version let's say if they are using the version 4.6 and there's already a new version available so what the vendors are doing they are using the same version 4.6 and they saying like Okay these are all the high fix we will fix dat so what are the different ways to uh address this or like what will be the advice which I can

give to the company to update the system because definitely this is not a good way and doing a black duck scan and providing that uh report to the a vendors and if they are fixing it there's no way to track it vendors say we have fixed it okay we need to rely on them so what will be the better way and again they are not updating the version so is there any tools or software which can keep track like maybe after 6 month because medium issues are not fixed so they may populate as in high issues in the later time the version is not updated so how should we address or what would be advice which I can give to the

company Executives about it Hey so uh I'd like really to better understand your question so you're talking about software that is provided by a vendor or by a project right so it's got maybe the version 4.6 of vulnerable dependency and the vendor or the open source package provider is not fixing that so maybe after months you see that that vulnerability is still there and yes yes so let's say version they have provided the as bom we do the black duck scan we found the vulnerability that okay 4.6 is affected with the three High 4 medium and let's say two low uh right now latest version is already available 5.0 which have all the fixes but the vendor says that if we

will update the version we need to fix other softwares as well in the dependency because there's a dependency based on version as well so they fix all the high versions keeping high cve in the 4.6 as well keeping the same version but moving forward right now it's fixed but after 6 month they may popul in high issue so what are the better way to address this so uh of course I don't have a a you know a solution to to these problems because they affect all of us if you have ever maintained a piece of software or if you have been a vendor you know that this is a problem because uh as as I was saying in the real word

you can just have everything up to date because for example 5.0 of that software has a breaking change so the vendor cannot do anything about it uh without maybe one month or two months of uh of development work just to update a version number so that's something that you also might not want to do in your own environment uh the thing is you said that sometimes it can happen that vendor backport patches even to the previous version I think the most important part is knowing if the vendor is doing that and having a database that works for that vendor for example I have experience with red hat red hat does this all the time if you have a you can

have a Python 2.7 which was out of you know out of support from the P from python years ago but radat will have a version of it that has all the vulnerabilities and this is yet another reason why you cannot match versions generically if if I try to match that Python 2.7 to the list of CVS that 2.7 has it looks like rat has lots of vulnerabilities uh so the the only Pro the only thing you can do is working with the vendor of the of the open source uh software uh producer so looks like we're just about at time uh so I think there's I think I think there was a question from PRI from earlier but then

we'll stick around we'll stick around if anyone wants to take it offline one okay yeah uh should be a pretty easy answer um so just to lay up right so um as far as like uh new vulnerabilities are discovered all the time you might have something that's discovered and how long do you do you feel like it takes for the es bomb to finally kind of catch up with oh wait hold on that affected everything every package in our uh in the sbom or whatever it happens to be the the relationships between things need to update uh as you get new information correct well uh I think in general if you have vul if you have a good s bomb

the vulnerab information will actually be already up to date because if the sbone tells you what the dependencies are once vulnerability is detected in a dependency you will be able to tell exactly what's going on there yeah right but I I think there is also an element of what's the life cycle of the vulnerability as it gets reported and this is actually pretty complicated because often there's like a year-long embargo period or like so from the time that a researcher discovers a vulnerability in a piece of software to the time that there's anything in the cve database at all could be months and months and months uh and then from there you have to say well okay does it have

all of the metadata that you would need to successfully do this matching and often that happens very after the fact and then as things get patched you know Dro maintainers will say okay our our you know plus Deb three version of this thing is not affected but our plus de two is and for that to get populated I I would say it sort of spirals around in equilibrium as opposed to it goes from no information to good information in a day um when I started working on these things I like to think that in an Ideal World the aspor is the same and vulnerabilities Orly get get added and never removed it was really wrong it was

really really wrong thank you so much thank you Zach and luuka that was great and thank you everybody I hope you had a great day thank you