IATC - Your critical system IS (NOT?) vulnerable: CSAF, VEX, SBOM and the future of advisories

oh hi i didn't see you there i was just practicing for the tom jones concert later uh up next we have uh alan friedman and jens weisner talking about s-bomb and advisories so if you're interested curious about uh software bill of materials if you want to learn more about how those relate to your organization how they are currently being conducted uh in companies around the world then tune into that one and come to the discord chat for a conversation with the panelists with the discussants we'll be there waiting for you discord and the i am the cavalry track see you there this talk is about your critical software and is it not vulnerable it dives into csev wax and s-bomb and

the future of advisories i'm jan zwiesner and with me is alan friedman

so why do we should you attend this talk because we need different approaches we need new approaches thinking about vulnerabilities and you will be asked customers will be coming to you and ask about how to secure your supply chain and there are some new things in this talk it's not s-bomb because you know when ln is on with me on the talk it's about s-bomb and this time we talk about vex something different something about communicating that your product is not vulnerable and we draw we try to draw a bigger picture how to do this on a better automated way and there's a policy version of this talk because knowing alan we did or there are a lot

of changes coming and supply chain security at the moment is not good it's not working properly and from my experience it's not it's it's next to impossible to really secure completely secure the supply chain and with the executive order of 14028 and the european union legislative framework there's a lot of change coming and by the way we are from the government and we are here to help you so i'm from the german federal office for information security we are more or less in the role of csa in germany we are defensive only historically defending or securing governmental networks and since 2015 we are also responsible for securing critical infrastructures in germany and alan well and i've been at ntia for

six years uh and part of what we do with the department of commerce is identify areas where we believe we can help the broader infosec community help itself so we've tackled issues like vulnerability disclosure field upgrade of the field upgradability of iot and uh perhaps uh most noteworthy recently uh software bill of materials or s-bomb we're going to talk a lot more at that but essentially our role in government is to help the community uh organize because we know that these solutions aren't things that the government can unilaterally push there needs to be strong effective partnerships between companies uh government and of course hackers so a lot of what we're gonna be talking about today boils down to

vulnerabilities right and of course we all know the vulnerabilities that have their own logo and their own theme song and their own breakfast cereal but at the end of the day this is the table stakes for proper security right known vulnerabilities should be the easiest part of security and yet in many ways it's not a lot of these vulnerabilities many organizations whether they're making software selling products or just running things don't have a quick and easy way of answering what should be a very simple question am i affected uh we don't have a clear answer to that today now uh we're going to know a lot more about potential vulnerabilities with software bill of materials or

s-bomb that's going to really change our visibility into a lot of that that's one of the key points behind s-bot but wait hang on a second jen said uh that everyone knows about s-bomb but i i'm not sure everyone does so we're going to take just a quick moment and sort of review hey what the heck is this s-bomb that folks have been talking about for a while so first not a new idea been around for a while uh just the last three years ntaa has worked to bring together a large diverse global community uh to help bring folks together to find out what it means and how we can implement it and at its core an s bomb is very

simple it's a dependency graph right we don't write all of our software from scratch we use other people's software s-bomb is just a way to capture that so my acme application or my acme appliance that we're doing an embedded device in our toy example has exactly two dependencies top level dependencies bingo buffer and bob's browser bob's browser in turn depends on carol's compression engine and that's really all this is it's not that complicated now implementation is always a little tricky but a couple of things for each of these software components we don't need that much information what's the supplier what's the component what's the version what are some of the identifiers right does it have a cpe or a perl

and then where did this data come from the other thing i want to flag is uh that we try to be very explicit about known unknowns so for example we know that carol's compression engine doesn't have any further dependencies we simply don't know if bingo buffer has dependencies or not and that's okay uh and of course one of the core themes you're going to find in today's talk is that everything needs to be machine readable right if we're doing vulnerability management manually we're doing it wrong and so we have ways of conveying this uh in xml and json today there are two popular formats that are being deployed today cyclone dx and spdx um you want to learn

more about them google them get in touch uh but how are we going to be using s-bomb so right here's the the formal definition which is it's a formal record containing details supply chain relationships uh various components used in building software now s bomb is something that can contribute to the entire life cycle of software and i want to be clear very few people have ever claimed that s-bomb will solve all of our problems in fact one could argue that by itself s-bomb may not solve any of our problems but what it does do is it creates a common data layer that can inform how we produce software how we choose software by software and then how we operate software and i

would say it's very difficult to have an sdlc a secure development life cycle if you aren't tracking your components it's very difficult to responsibly select which software you're going to be running on your network or going to be using in your product if you can't see what the dependencies are and of course how do you do vulnerability management if uh you don't know not just is there vulnerability in this product but in any of the components as well and in fact there's some language to describe exactly what those these use cases are in the president's recent executive order so we're going to see this uh more and more problems the more and a bigger part of how we

think about software but uh ellen ellen are you i i stop this talk shouldn't be about s-bomb i'm sorry for that but um you wanted to talk about vulnerabilities it's true and and forgive me those of you who know me know that once you get me started talking about s-bomb that's what we're going to talk about because there is a very important link uh to sort of tie in how s bombs relate to vulnerabilities right because we have all of these things out there every month they're going to find more of course the coming few days we're going to see a lot of great talks by some really cool hackers about all the great vulnerabilities they've found

we're never going to run out of vulnerabilities the thing to acknowledge is we need to think about them from a data perspective from an operational perspective so how do we communicate vulnerabilities we actually have a solid data layer today now it's not perfect uh but cve common vulnerable enumeration allows us to have that first level of data which is to say when i talk about a vulnerability and you talk about a vulnerability we know we're talking about the same one so is it perfect well it's better than one nothing but i don't know yen do you have any opinions on the efficacy of cv absolutely so if there's a cve it's great but there are a lot of

vulnerabilities which doesn't get don't get cves or vulnerabilities which get silently fixed by the vendor and they don't request the cve so what about these and how to track these and what to do about it so it sounds like it's really hard to actually build a soup to nuts management program just based on this it's better than nothing but we need to do better and absolutely and from the point of an end user you need security advisories you don't need the vulnerability because as an end user okay there's a vulnerability in library epsilon but how do you act on it and you need a security advisory it's true the if just having a number doesn't magically

fix things we need to know what to do about them and there's another core point here which is that not all vulnerabilities are actually exploitable uh so for example everyone loves to talk about heartbleed depending on how you measure it openssl 1.0.1 has between 600 and a thousand different function calls you can make two of them call the code that has the heartbeat function which allowed reading of random memory from an internet facing device which was the heartbleed vulnerability um so someone who's using that could just say hey you know what i'm just using i don't know the prng i don't know why you use that prng but i'm just using that chunk so the code

isn't there uh and in fact there's some estimates from vendors that have said actually for using vulnerable components in downstream products a small minority of those products are actually affected does that mean that it's totally okay to use vulnerable components no still something that we need to pay attention to because even if it's 10 well that 10 is going to get you and so what we need to do and what the approach is as we're thinking about s bomb and vulnerabilities is to understand how we can think about and communicate whether or not a vulnerability is actually putting something at risk we need a way to communicate that this product is not affected by this vulnerability

so i'll give you an example of where someone's had to do this recently the zephyr project which is a great real-time operating system platform developed by the linux foundation for iot it's a wonderful project if you're in that world check them out help them out they said hey this amnesia 33 vulnerability right buried deep in the networking stack it's a dns bug that affected potentially uh hundreds of millions of devices but the zephyr team did the homework they've got a good product folks they've got folks that think about security uh and they said we're not affected like we heard about it people said hey uh you're in the iot space does this affect you and they had to say we are not affected

by any of these vulnerabilities in any of the current releases or in any of the long-term support releases and that's really important right that's something that their customers are going to want to find out the challenge is that that doesn't scale that well uh there's going to be some challenges because right if you're a manufacturer that uses zephyr you're probably using tens or dozens or maybe even hundreds of other components and if you're an end customer with a factory floor how many hundreds of suppliers do you have so we need to have a way to make this scale right how many device types are on your factory floor so one of the core challenges we're

trying to get to that we're going to need to handle within a world with s-bombs and remember we're getting there is how do we communicate that a device is not exploitable and so allow me to introduce you to one of the most poorly named projects in all of infosec uh the vulnerability exploitability exchange or vex uh now a couple of things i want to talk about first is let's we saddled with the word exploitability in that it's used as a common part of cybersecurity policy both at the you know policy people in global capitals as well as how do i manage my system um but we you know we've been around infosec long enough to know that that

term is very loaded and if you try to say you know a particular vulnerability is never exploitable well you're going to run into trouble because you know someone is going to be clever and figure out how to chain things together so let's use the word affected not like gosh alan you're really affected um but does someone need to do anything i as the customer the downstream user is there anything that i need to do and in fact uh we can even define it formally right actions are recommended to remediate or address this vulnerability now this could be learn more about it right the action could be um hey you remember how we told you to definitely not plug this blinking

box directly into an internet connection because bad things would happen could you please make sure that you listen to us and we told you that three years ago right that is an action you have to take so they might still be affected even if it's you know context dependent or it could be something as simple as apply a patch or tune your ids or segment your network or something right there there are lots of things that you can do to address or remediate a vulnerability now the opposite of affected is of course not affected it just means you're good no action is taken uh so that just means you know here's a vulnerability it's out there but it

doesn't affect our product it doesn't affect this code now there are a bunch of reasons why that could be right the vulnerability is not present right the compiler ripped it out it's not exposed i've got existing controls um my engineers are very good so they sanitized all their inputs that were going into this function that's fine uh right there a bunch of ways and in fact we're slowly working on making that level machine readable but in the meantime simple trade-off of affected versus not affected no change is necessary so if we wanted to implement this what will we need well a couple of things first it needs to be machine readable and automatable right the goal here is

to ultimately have this be part of our automated systems we're thinking about this so we need a couple of details we need descriptive data right tell me about the software in question and then the vulnerability status right is it affected or is it not effective and then as much information as you can give me to help me make a decision not all of it's going to be machine readable at the beginning but enough of it is especially being able to point and map to a piece of software and then having the vulnerability status so high level required fields for what we're looking for is the metadata right where did this data come from uh you know what's what is this vex file

and then a product id right this is referring to zephyr or this blinking box by this manufacturer and then some way of tying it to vulnerability so what's the vulnerable id vulnerability id and then what's the product status so right is it affected or not affected that's its core now all of this kind of sounds familiar doesn't it yes absolutely it sounds like a security advisory you're damn right it does uh now again when we talk about security advisories those are not traditionally machine readable right some of you have seen them it might look like this they're like this or like this or like these right these are complicated and messy and by the way what we're proposing

is not a traditional security vlog advisory but a negative security advisory right the goal here the whole idea of vex is to say i am not vulnerable uh which is right the opposite of how this works but there's no reason why we can't have those especially if we can automate them but and besides how hard can security advisories be very hard very very hard because my team is tasked with reading them and processing them and determining if critical infrastructures in germany are affected by them and issue warnings and do a lot of stuff around them and currently we are already swamped with security advisories you can't they are correlated to the number of cves we don't have

proper figures which go back for such a long time but they are correlated to cves and you see the more or less exponential growth and about exponential growth we learned something about the last year so it's not a good sign and i think by the way it's pretty impressive that we don't even know how many security advisories there are cves are at least a little centralized there's no centralization here absolutely and there's also no automation so if you my people scrape the websites and some of them are support portals some of them are behind logins and um they're very difficult to automate and we put took three advisories for example one from csa one from schneider and one from i think

siemens and they're all in different formats so one is html pdf and you see everything you also support portal try to automat automate this it's very very hard and they are machine readable no they are human readable they are designed to be read by humans and their structure is different their language is different and it's very very hard and we if we look at the timeline so there is this there there is a security researcher internal somehow a vendor com becomes aware of a vulnerability he analyzes it finds okay correct and they release a patch and an advisory and what we are trying to address is the time till the asset owner does something at

the moment vendors who take good care release their patches and advisories and vendors and and asset owners um it takes far too long to reach them and for them to act and there are so many um for example uh when we had the exchange vulnerability uh it we tried to address them and it took ages for for the operators to react and we need to optimize automate it and there comes csef into play and with csev the common security advisory framework well at first it's a standard it's a standard which defines a json format machine readable my file or system it's not only a file it's it's a complete ecosystem and if you have ever dealt with security

advisories and automation you might have known common vulnerability reporting framework and this is the successor to it and this is what we're um what we're trying to push forward and why is it why are you guys have doing this in oasis um oasis is it's historically based or located situated in in oasis open and i convinced my management that it's something we need to do because we are tasked by law to assess the impact of our vulnerabilities on on create critical infrastructures and therefore we read the advisories because we can't determine because we don't have an s-bomb if a product is actually vulnerable so we need to reach the advisories and have to rely on them and therefore

that's the only way we might solve this issue or i we hope to solve this issue and by the way there are big big companies contributing or working in the development of csef and i personally got into this because a colleague from siemens we met at the p-search meeting and you told me yes we're doing the best we can but our advisories are not reaching the customer what can you do what can the government do to to get it to the customer and to reduce this time to react and then we we dove delved into this and we found that this there is already csef in the div in the making and a colleague in my team he really pushed it

forward and we made a lot of progress within the last year i should also add that your colleague tomas has gotten me involved he called me one evening i was on my exercise bicycle and uh somehow that turned into a 45 minute conversation where he told me and convinced me this is a great project so it's something that's why the us and german governments are giving this presentation together that's right that's right and to to walk you through to walk you through the whole process what is done today and why it is so painful um so um we at the moment the vendor produces a machine readable advisory as you saw pdf text whatsoever and then

he publishes it and there are usually are often there this is there are several cves and several uh vulnerability scores there and often 10 20 no worries then the user has to search for it has to be he might be subscribed to an rss feed he might get a notification via mail sometimes it's only in a support portal where you get no notification then you have to download it and you have to um read them you have to read all these advisories and that's what what part of my team is doing every day just go through these advisories and and sort them according to criticality according to which how the impact of of these vulnerabilities of the fixed

vulnerabilities might be if they are not addressed and then when we are going we are prioritizing and after the prioritizing um and a customer and an operator and end user would have to look okay now i have these advisories do i have affected devices am i affected and then if i have if if i'm affected so i have to do a risk assessment so should i patch when we think about art mania and should i patch now should i patch in the next cycle or should i accept the risk these are the three options you can take and they're nothing more these are you have three options but determining which one of these three to take is

extremely difficult and if we automatic or automate it if we automate it um we will benefit hugely we expect a huge benefit for the whole community and um if we look into a csev document it's a simple json file it's a simple json file um put put one up it's not rocket science it's the the thoughts which went into this work quite extensively and thomas did a great job doing that and really creating this ecosystem around it not only a json file but a lot of different things like vex and now i want to show you the when you when we automate it automated so now we have machine readable advisories and they're being published and then

the search for new uh for for new updated advisories and the download will be automated and because we we will get a repository and a system around it where to find advisories on the websites and thinking about where to download them and then the evaluation phase starts so do you have affected devices um this can also be automated because now you can have a magic algorithm which says okay i have this this type of system this this advisory okay they match so i have to look into these but you can reduce the number of advisories you have to read quite heavily in theory the it would be best not to have to do anything but

well you you reduce your workload quite quite extensively and you can also do some kind of um some some help how to um act on the if you have um um you could for example um put mitra attack framework into this and throw this in the mitral attack framework and now see how your system reacts or you could do something like like a digital twin where they you have these advisories what's the effect on your systems which are affected it's the um everything everybody talks about the how to act on these advisories but nobody talks about the input data and this is the the time frame where the timeline we just talked about and if we would switch to csev it would not

work no at the moment because the vendor would need a content management system sometimes some system to manage their advisories although we have this standard and it will be published soon probably next month um we the asset owner needs an asset inventory and asset inventory on the asset owner side is something which is still not perfect let me put it this way and then we need some magic algorithm to fit these two together and this will be the next challenge and by the way on the asset management side you know it's one of those things that you know people can innovate and make as many cool do tools and widgets as possible but at the end of

the day the basics are still there right all of what we're talking about says we still assume that there has to be a certain amount of minimum competence uh for for building out the asset management side of things absolutely absolutely so if we think i want to sum up the benefits of csf so i hope i will gain a few people from like i don't need to burn good technicians people with good technical experience and skills by just reading these files and on the asset owner's side as well so you need a skilled person to read and to act and you don't need them anymore they can do better work they can do the work they were they want probably

not so boring work um and you could even um externalize it you could can give it to a third party there's the asset inventory inform me when something's going when we are affected and you only you don't have to read so much so it's scalable even across many vendors because it's one system and if they've then they don't use different formats anymore anymore and as i said risk basic risk management is also much better well and now a little bit about s bomb and supply chain so if we think about the the chain so every supplier is also a user of a product and a vendor so so this is yeah i love the line oh i'm

just going to chime in and say that everyone is in the supply chain and most of us are in the middle right most of us uh who you know some very few of us are only operators but most of us who touch anything related to product are using things from someone and then are sending things downstream to others absolutely and this is so if some some there's some open source library which is affected and you use this open source library in your product then you are already in the middle and this is and and we again we want to reduce the time frame where products are vulnerable and th this is the same for for the operator

for the vendor as for the operator for the end user if they're if you're doing due diligence if you're doing if you want to do proper work you have to implement this because as i said most vendors are also suppliers it it goes around it's a recursion and for for suppliers there are also benefits because who is doing that there are software products which try to do this based on cves but then again without vex without a system that tells you that this cve does not impact the product you have to do a lot of work just to find out oh no i don't need to do anything so it's it's the same here if you are

wender as well and i probably took a slide from ellen because i wanted to ask you what does this mean for wax well so i think there's there's uh as you were saying there there's a lot of value here for reducing human load uh and right the whole vision here is that it should be scaling uh and as we think about risk assessment um this is only going to work if we can actually make this machine automatable and help people use the s-bomb to focus on what we should be prioritizing right if a vulnerability is if there's a vulnerable component in my supply chain but my product is not actually vulnerable then no one should care right we need to sort

of be able to cross that off our list as quickly as possible so how are we doing this uh in the vex side of things uh first vex is going to be a profile in csaf now for those of you who don't live in the standards world profile is just a way of taking a big messy standard and saying the stuff you care about it's only this stuff over here so you can ignore everything else in the short run so that's a profile just allows us to say use these fields and you can ignore the rest of it for the same time but at the same time it's still part of the csaf standard so it can be

integrated into the tooling it also allows us to use the infrastructure and the systems that yentz was talking about uh this is true at the uh folks for the folks who are creating csaf documents and ins is going to talk a little about how to create them in a moment and also ultimately down to the consumption now this has a lot in common with s-bomb uh and some of you have heard me talk about how s-bomb there's is a chicken and egg problem right and this is true for the advisory side of things uh and indeed everything in security where we're trying to help data move more effectively across organizational barriers is you know no one's asking for it so no

one's supplying it no one's supplying it so no one's asking for it so how do we prime the pump well that's one of the reasons government got involved uh for vex and s-bomb the important thing is that we don't necessarily need to staple vex into s-bomb they can be separate but the important thing is they should be mappable so that i can when i get an s bomb can say all right let me go and see if there is a vex document that applies to this so i can go and and find out uh okay my my you know my automatic dashboard is blinking heartbleed heartbleed let me go find and see if there's a vex

out there and again using automated tools so that i can now turn it off uh and so i think that's really the power the power here is vex complements and supports s-bomb and continues to follow that model of machine readability now uh how is this going to be implemented well first right there has to be a product security team uh so right the good little product security team is actually doing their homework to determine whether or not it's affected whether or not a vulnerability affects them now that's something they should be doing anyway and this is one of those components where on one hand for those who are sort of a little uncertain say well what if

what if there's a terrible product security team well we can't help you with terrible product security teams but what we can do is create some very real incentives to help the team that is doing a good job uh be rewarded and the story is pretty straightforward which is to say um whenever in some of you are in product security you know this whenever a new vulnerability comes out good customers who are very worried haven't heard anything or maybe they just don't know where on the website check they're going to call you right customer support costs skyrocket whenever there's a major vulnerability even for things that are not related so i've talked to the head of product

security for one of the major switch manufacturers and whenever a different switch manufacturer has a public you know public widespread vulnerability his team gets overwhelmed with calls saying are you effective like no that's the other guy the whole point is so we can now we can imagine having this automation as a way of saving a lot of cost and so that means that if you put the money into building a good product security team that can do the quick turnaround of saying let's find out quickly if our customers are affected now you can actually buy through the power of automation make sure your customers know this quickly easily in a fashion that will help them do

their job better so that is actually turning this into real dollars and cents now the other thing to note is where these vex documents going to come from uh the most obvious place is the supplier right large manufacturer software supplier open source project anyone can write right the supplier makes the most sense because they're the ones who are most familiar with this but it's also important to note that they don't have to one of the core fields is the author of the data and just as today you see folks in threat intel sharing lots of information about attacks that weren't necessarily related to their products uh similarly i think we're going to see vex documents written by

experts in the field so right maybe medical devices will focus on saying okay yeah we're going to just affirmatively say we're going to tell our customers that you know these products are affected these manufacturers aren't affected uh because again sometimes it's actually quite easy to prove the negative if you know that a certain open source library isn't used in a piece of software then you can easily tell everyone to not worry about it so the other fun thing that i can imagine is as people start to use this as a claim who's going to trust them well sometimes you have a long-standing relationship or you know the team you trust your supplier but another thing that i can imagine

is happening is you're going to see bug bounties right this is literally putting your money on the line saying um we are going to pay a particularly large bounty if it turns out we were wrong uh and so now you're going to basically draw a lot of attention to this as a way of validating it so i think that's a really fun way this can do it but also i want to acknowledge that this isn't just talk right this isn't just people in hotel rooms or zoom calls building a standard folks are starting to implement this today i mentioned medical devices some of you know that the medical device community has actually been leading the way globally

uh on s-bomb and supply chain transparency they've been doing it despite the fact that the medical device community's been a little busy uh over the last uh two years um making things like respirators and working with hospitals that are busy trying to save all of our lives and so but this has been a priority and in addition to producing s-bombs medical device manufacturers are now starting to produce vex documents that are there are being built to communicate to their customers whether or not they are explicitly affected by a vulnerability so it's really great to see this out in the world now if that wasn't enough your friends in the government are here to help uh

some of you may have heard of this administration's most recent cyber security executive order in the united states called improving the nation's cyber security or 14028 for those of you who want to you know be in the know uh with all those hip cyber policy types uh and there's a great line from the introduction of this executive order uh that says the trust we place in our digital infrastructure should be proportional to how trustworthy and transparent that infrastructure is and so this is one of the reasons that people are even now more excited about s-bond than they used to be uh it wasn't just because we've got really cool new s-bomb stickers but it defines s-bomb

and identifies the value proposition i threw up some of that language earlier in the talk but it also required the department of commerce to define the minimum elements and ultimately it's going to require the u.s government uh to define some rules to assign some guidance to make sure that everything the us government buys uh comes with an s-bomb and i'll give you a hint the u.s government buys a lot of software uh and so i think this is going to have a real impact uh and in fact if you look at this report uh that the white house gave a certain small organization 60 days to write that's why my june was a lot of fun it

explicitly calls out vex and explicitly calls out csaf as well as an implementation approach so we are going to see this not just being an academic exercise and intellectual exercise but this really is something that folks are starting to build to today so problem solved right well not quite you're still going to need some of your help uh to make this work uh and and one thing where i think there's a lot of opportunity for the b-science las vegas community is to build things right it's one thing to talk about stuff that's what i get paid to do is talk about stuff and help other people to talk about stuff but standardization i gotta admit not

the most exciting thing in the world right you can have a standard all you want but if no one's building something who cares so we need tools uh and so there's some really cool interesting open source projects that are just starting uh but there's tons of room for startups or for people who are looking to build their own project or to work on very new projects uh i think this is going to be a very rich opportunity for folks to show leadership uh and either build an open source project or start a company or lean in heavily for your security startup um and uh yes are there a couple of ongoing open source stuff that you want

to flag absolutely so working for the government means you have no intention of getting rich but you can do cool cool cool programs and we have at the moment three of them running um sac visor gram is already finished it's like vulner gram which is used for calculating cvss core and sick visogram is a tool for generating csef documents i will show in the next slide we'll show it but we have more in the pipeline a validator which will check if a csef document is valid and even give you some additional remarks about usability and readability and the domain checker is if there are if you're searching for a company if they are already participating

and checks if they fulfill several requirements for generating csef documents um yep there so we have a lot of these three are in the pipeline and um sac visor grum is currently used for checking for for yeah checking the standard for expanding the standard and it has um it's like like window gram it's completed completely written in javascript you don't have to install anything you can download it at github you can run it there you can test it at siqvisogram github io and the usability is horrible so it works it works and it is a proof of concept but it's i wouldn't recommend using it at the moment because it's there yeah it's a proof of concept

and it generates valid um csef documents and you have also a json editor where you can enter code and it checks everything um and it's it's it's nice it's okay but it's it's not for official use so when there was this amnesia 33 case uh we dealt with them and we were we covered um the german companies and we contacted them which were affected and most of them had never written a security advisory never ever they were completely hit by it and we were a bit angry that we didn't have sacrifice or crime at that time of finished because we wanted to give them we don't want to show them how to or we wanted to give them just a guideline

you know governments published documents and not really take their hand and walk them through every time and there were i don't know 40 cases we we we managed or 40 winners we managed and it was too much and segway isogram would have been a great help um so for folks that are looking to get involved or or maybe you know some students or some young people that actually want to get their hands dirty on code and real project this is exactly the kind of thing that would be great helping us take this and turn it into something that scales has a little more user interface friendliness a little more applicability walks through a bunch of use cases

absolutely so yeah you have to yeah you have to do something and um and so what's right what what should we focusing on what's some what's some takeaways so now that we're sort of wrapping up our talk uh what what are some of the things yes that you think folks who are listening should be right to remember from what we've just said other than the fact that we really lean heavily into the oh really graphics so we still have the chicken and egg problem it's still not solved so if nobody asked for csef sisep won't fly and we are pushing hard towards it and we are working together with other governments in europe to get it to fly

but still we need more more commitment from other countries this would be something great if you are already a supplier a vendor ucsf it's prepare for using csef so we have um the two two major automation companies from the not standard i.t but which are producing i wouldn't say i don't like ot so much because it's so keyed but it's this the companies who produce plc who produce rtu's devices which are used in the field and we have two two major companies which are already committed to switching to csef but that's still not enough my in my opinion but we we try to enforce it with legislation this is the nlf we will try if we can snuggle it in at

the moment it's not there but we will try because um that's if how can a wender prove that they are doing due diligence and providing csef documents is one way of showing that another way could be certification and stuff but hey i'm using csef this is the quality logo it's and i should add that it's probably a lot easier to start using csaf than it is to get certified and tested absolutely you just put them out and say we're using csef and at least at the moment it's it's an advantage and it's not rocket science again it's it's just um it has a limited number of required fields and a lot of optional fields and the one problem with cvrf

was that the field definition was not specific and and some between different vendors used to the fields differently and it was not so machine readable as it was expected and we hope that for csev we did a much better job here so and again spread the word spread the word and talk about it then we will come further and maybe that is a that is a great uh mantra from the i am the cavalry world that i love to quote which is you know belong we can go fast but together we can go far and uh so let's you know what's the big picture so we know that the number of vulnerabilities rising it's going to grow it's going to get even

higher in safety critical world whether it's automotive or medical or industrial and we know that there's going to be better insights into the supply chain right as we have more visibility into this and what is that going to mean that's going to mean more advisories those advisories have to be machine readable there's simply no other way for anyone to get their handle on it whether it's the government or whether it's the companies that are trying to deliver services that we all depend on and so we need advisories for good risk based decisions we need scalability and i love the framing which is like what we're trying to do is automate the boring stuff uh at the end of the day a lot of

security is going to require smart people to make decisions but let's give them the interesting stuff and the critical stuff and automate all of the stuff that we can have and finally um publishing no not affected right just being able to say help communicate this isn't a problem let's take stuff off of our plates so we have some time for questions some constructive criticism if you have it uh and and here's how folks can get in touch with us uh that's how to find more information on csaf and on vex and of course on sbom and this is how you can get in touch with us uh and jens has helpfully included thomas information as well

so thanks so much for your time today and uh we'd love to hear your questions and would love to stay in touch please call us and if you have a vulnerability affecting a german product you can call us as well if the vendor is not responsive by the way thank you thank you