WEBVTT 00:00.000 --> 00:12.800 And it's time to start, many thanks for everyone being here today. 00:12.800 --> 00:18.560 So this topic about software build of material, maybe not something the most fun, everybody 00:18.560 --> 00:21.080 who has already built. 00:21.080 --> 00:26.600 Some kind of application with dependencies and stuff like that have probably experienced 00:26.600 --> 00:28.480 some trouble. 00:28.480 --> 00:31.680 We have Oli Johamsson together with us today. 00:31.680 --> 00:37.360 So speaker or teacher, consultant doing a lot of things. 00:37.360 --> 00:45.240 Also member of the open world-wide application security project and taking care of this 00:45.240 --> 00:54.480 SBUM from there as well to leaders and this afternoon about this topic here. 00:54.480 --> 00:57.240 Please welcome Oli Johamsson. 00:57.240 --> 01:06.720 Hello, I love seeing everyone around. 01:06.720 --> 01:12.840 I hated you in the pandemic when I had to talk into a computer and not see anyone. 01:12.840 --> 01:17.920 As you hear my voice is really bad, I'm coming from Stockholm's Weedon. 01:17.920 --> 01:19.560 We have rough winters. 01:19.560 --> 01:25.480 So if I get in problems with my voice, I have a co-speaker over there Anthony Harrison 01:25.480 --> 01:32.760 from England, but I have somewhat better weather, not very good weather, but has a voice. 01:32.760 --> 01:36.360 But I'll give it a try. 01:36.360 --> 01:43.160 I've been in the open business for almost 35 years. 01:43.160 --> 01:50.080 I learned unix and stolen Linux, I worked with open protocols, TCP-IP, I worked with open 01:50.080 --> 01:51.080 source. 01:51.080 --> 02:00.080 I'm going to hear a call for people, I'm going to hear do phone calls. 02:00.080 --> 02:02.080 You're all doing phone calls. 02:02.080 --> 02:03.080 Good. 02:03.080 --> 02:11.600 In 10 years, I developed the open source PBX asterisk with a team of really cool developers 02:11.600 --> 02:14.320 who are all better than me. 02:14.320 --> 02:20.960 I've also been working in Boovas now for some time, and especially focusing on the Cyber 02:20.960 --> 02:23.320 Assistance Act and the effects of that. 02:23.320 --> 02:30.760 I mean, looking into what we as open source projects or manufacturers need to do, I 02:30.760 --> 02:35.040 realized that there were still a lot of missing parts. 02:35.040 --> 02:41.240 Some things work very well, but some things doesn't. 02:41.240 --> 02:49.480 So as the chief problem maker that I am, I don't do vast and I started fixing stuff. 02:49.480 --> 02:55.680 I'm going to talk about stuff that needs fixing, because I'm not selling anything, and 02:55.680 --> 03:03.160 that's the beauty, I can tell you what's wrong, and we're going to fix this together. 03:03.160 --> 03:10.920 See nothing about me, let's switch to another topic, I really like that's me and myself. 03:10.920 --> 03:17.480 For facts, open source developer, active in all of us, lives in Solentone, and also Sweden, 03:17.480 --> 03:23.800 that's why I have this voice today, and the owner of the most beautiful dog in the universe. 03:23.800 --> 03:31.880 Right, Gordon, he is beautiful, and I'm lactose intolerant. 03:31.880 --> 03:39.040 Being lactose intolerant means you have to have really good eyesight, because I have to read 03:39.040 --> 03:47.040 all that text before I buy anything in the grocery store, and even if I know how a piece 03:47.040 --> 03:55.920 of food is made, suddenly one day there's milk in it, skin-milk powder, and that would 03:55.920 --> 03:59.360 ruin my body. 03:59.360 --> 04:06.760 So that's one of the allergies, or sensitivities I have, but I also suffer from curl allergy. 04:07.000 --> 04:18.160 This is really hard, and don't tell Daniel, my friend, right, he still believes I'm using 04:18.160 --> 04:19.160 curl. 04:19.160 --> 04:30.680 No, I guess you all know curl, it's part of your life, every single day. 04:30.680 --> 04:36.200 If you drive a modern curl, if you use your cell phone, if you use a laptop, if you 04:36.240 --> 04:43.880 do, whatever you do, both after-risk and Camille, you had curl modules, was really hard 04:43.880 --> 04:49.880 to not compile weed curl, but I can do that. 04:49.880 --> 04:57.240 But this is a tough allergy, because when buying products, how do I know if there's curl 04:57.240 --> 05:12.240 inside, no one is telling me, can you imagine my life, can't buy anything wrong, 05:12.240 --> 05:20.840 it's hard, Daniel makes my life hard, so what's missing is that little text on the package, 05:20.880 --> 05:26.920 that told me if there was any direct products in the food I buy. 05:26.920 --> 05:36.640 When you buy hardware and that assistance software, where is that list? 05:36.640 --> 05:43.800 That's a missing piece, because that list would help us not only with curl allergies, 05:43.800 --> 05:49.960 but when bad things happen, we would be able to know. 05:49.960 --> 06:00.840 And bad things happen, all the time, even there are software vulnerabilities, bugs, that 06:00.840 --> 06:07.680 even get logo types and websites, they're more famous than I am, which hurts me. 06:07.680 --> 06:18.320 But this stuff happens, when logo for J happened, sorry, Piotr, Piotr is part of that, 06:18.360 --> 06:24.200 I'm not a part of the logging project, when that happened, people contacted me about Camelio, 06:24.200 --> 06:30.360 say, oh, I need you to feel informed here to confirm that you don't have this bug, I'm 06:30.360 --> 06:36.360 like, I have no obligation to you to feel in any forms or answer any request, and by the way, 06:36.360 --> 06:43.360 Camelio is written in C, right, but there was so much time spent worldwide trying to find 06:43.360 --> 06:56.080 out if a customer were a platformer service had this vulnerability, manual hours, cooling 06:56.080 --> 07:03.720 vendors, contacting open source projects, I was sitting the whole weekend, both answering 07:03.720 --> 07:10.040 and have been customers to sort out where it hurt them. 07:10.040 --> 07:16.880 Another problem is, when I talk with a patch of logging project, there's still downloads 07:16.880 --> 07:24.080 that vulnerable version of luck for J, it's still in use there's a very, very long time, 07:24.080 --> 07:37.080 long tail, do that, and even more scary was it said, vulnerability, where a foreign actor 07:37.080 --> 07:48.280 forced in bad code, June's years of work, what if another log for J would happen today, 07:48.280 --> 07:55.480 would you, the organization you work for, your customers, able to find out where they are 07:55.480 --> 08:03.660 affected, do they make their own priorities, say, well, all those down printers, they never 08:03.700 --> 08:09.180 work in a way so we can turn them off, but that website, the customer fronting website 08:09.180 --> 08:17.580 that handles our e-business, that's something we need to put all resources on, would they 08:17.580 --> 08:23.660 be able to do that, or would they say, all hands on that everyone call, place calls using 08:23.660 --> 08:34.220 master is can come in you, I wish I would get a sense for every call, so I hear a lot 08:34.220 --> 08:40.460 of that, okay, his solution to all this, the solution to almost everything including sliced 08:40.460 --> 08:46.940 bread is the software bill of materials, right, if you only get the software bill of materials 08:46.940 --> 08:56.940 file, done, you have some XML file or JSON file, no one understands, but you have 08:56.940 --> 09:08.460 to file, it can relax because you solved the problem, I wish, I've custom recalling 09:08.460 --> 09:25.820 what I'm saying, oh we have to file now, are we done, ah, ah, my computer, oh there's some animation 09:26.700 --> 09:36.540 so I get tired when I hear that, just as marketing bullshit, this is just a new file format, 09:36.540 --> 09:46.140 a listing of stuff, there will only need to do, right, and I keep hearing people saying, ah, 09:46.140 --> 09:53.020 so S-bomb doesn't solve anything, it's bad, it's dead, good, good riddance, and we haven't 09:53.100 --> 10:01.260 started, but they already killed it, all right, okay, and I hear the other side saying, oh S-bomb 10:01.260 --> 10:09.020 solves everything, yeah, this makes me a bit worried because there's some sales involved in these 10:09.020 --> 10:15.260 rumors, and if you get them in your social media, wherever you are, master it on or blues guy 10:15.340 --> 10:27.580 or any other thingy, close your ears a bit, so the way I see it, S-bomb usage can be for many 10:27.580 --> 10:36.860 different things, it started really because we needed to map all the open source licenses in 10:36.860 --> 10:44.940 a complex project, we need to make sure that the licenses were compatible and see if if 10:45.340 --> 10:51.260 you worked with a commercial project, if you had any risks involved in using all these components 10:51.260 --> 11:00.780 with these licenses, from there we have gone on to vulnerability management, risk management, 11:00.780 --> 11:10.220 supply chain management, and many other things, and the software bill materials is just one 11:10.220 --> 11:15.340 bill material, you probably know the hardware bill material that been around for a long time, 11:16.540 --> 11:28.860 but within cycle DX as well as S-bDX, we are expanding this group, cycle DX recently launched 11:28.860 --> 11:35.900 a cryptography bill materials, and this is in order to help with the post quantum crypto transition, 11:36.060 --> 11:43.900 trying to figure out what kind of crypto assets you have in your platforms in order to make 11:43.900 --> 11:50.220 priorities on where to start, this crypto harvesting going on right now, so this is something 11:50.220 --> 11:56.220 we need to do and the C-bomb will help you, but as you see there are many other things going on, 11:56.940 --> 12:07.820 and this is all to help us with our complex systems, trying to map them and perform risk assessments 12:08.620 --> 12:16.060 over the platforms, but if we go back to the software bill materials, there are many different types 12:16.780 --> 12:25.420 on the link here you'll find what the American C-SA said a while ago, I kind of agree what they're 12:25.660 --> 12:36.300 saying, but in my world they missed the thing you hand over between organization, the software 12:36.300 --> 12:44.140 bill and materials that I as a manufacturer, the software project hand over, this is of course 12:45.180 --> 12:52.060 something a little bit scary for the lawyers and compliance officers if you're in a commercial 12:52.140 --> 13:02.300 organization, so they want to see that and attest to it, but we have many different versions 13:03.900 --> 13:11.500 I will can focus a little bit on a build thing because you build environment to C-I-C-D-2 chain, 13:11.500 --> 13:17.260 you're testing to chain, all of that need as pumps as well, and vulnerability management, 13:18.220 --> 13:25.500 and that's very different from what you actually deliver, right, your test systems is 13:25.500 --> 13:38.540 proper in a part of your delivery, and then the customer's view, in the last best one forum we've 13:38.540 --> 13:46.300 been hearing a lot of stories from the US medical industry, medical devices, where customers in 13:46.300 --> 13:52.460 large hospitals say that, oh have a whole file system for the less pumps, I can't use them, 13:53.740 --> 14:01.420 but we're happy, they have less pumps, no, I have all these devices in my asset inventory 14:02.220 --> 14:08.860 and there's no way I can match them with a big pile of less pumps, the connection is broken 14:08.940 --> 14:16.780 and this is something we need to work on, how do we relate a thing we bought 14:17.980 --> 14:28.620 with the S-Pone we got from upstream, but if we can do that and have the S-Pone 14:29.980 --> 14:37.340 the S-Pone has a list of a lot of stuff with names, that's the vendor name, the component name 14:38.060 --> 14:45.980 and abortionly identifier, and this is what's needed to verify if there are any vulnerabilities 14:45.980 --> 14:55.500 in the platform we're running, that's very simple isn't it, vendor name, component name, 14:56.140 --> 15:08.060 abortion, the problem is that for one of the mayor vulnerability databases, the national vulnerability 15:08.060 --> 15:18.780 databases, national being USA of course, day decided, the vendor name, and the product name without 15:18.780 --> 15:26.300 asking the open source project or the vendor manufacturer, now the manufacturer who produced 15:26.300 --> 15:33.420 S-Pone's for their product, they have one idea of the name, but they have vulnerability database 15:33.420 --> 15:41.340 have a totally different one, how do you get connection there, many S-Pone tools today, they 15:41.340 --> 15:51.980 guess, they say that, well we have a list of combinations of stuff that I think we may hit something 15:53.660 --> 16:03.260 and we, I don't like that, and the API termed these very nice, because if you ask it to find 16:03.260 --> 16:13.740 a vulnerability for a given identifier, it can say not found, because the product doesn't have 16:13.740 --> 16:18.620 any vulnerabilities, but not found can also mean the product doesn't exist in the database, 16:19.820 --> 16:25.020 which means you had the wrong name, the wrong identifiers, and it's the same answer, 16:25.100 --> 16:39.180 how is that helpful, but it's the US of A, be happy. So we're seeing, every time we talk about this, 16:39.900 --> 16:47.420 even in the light of the Cybersilence Act, there's a flow, the Cybersilence Act doesn't 16:47.420 --> 16:52.700 say anything about giving out S-Pone's to customers, you're not forced to do that, 16:53.500 --> 17:03.100 but as a customer, I would definitely ask for the S-Pone. So we have some upstream 17:03.100 --> 17:10.380 open source projects, and they become virtual products, we have a manufacturer that sells to a 17:10.380 --> 17:18.780 customer. Do we see a chain of flow here of software transparency or the fact, because it's not 17:18.860 --> 17:26.460 just S-Pone, is a couple of other adaptations, is something called the Vexfall, which I can 17:26.460 --> 17:37.020 talk about for hours as well, and other pieces of data that the customer need to do continuous 17:37.260 --> 17:56.220 risk assessment. So I'll try to discuss where we are with S-Pones with my fully new S-Pone 17:56.540 --> 18:07.260 meter, a patent pending trademark registered, you know, S-Pone, a meter. O is for Ulla, of course. 18:09.660 --> 18:16.700 So somehow there's an S-Pone maturity scale, and this is something me and I absolutely over there 18:16.700 --> 18:22.620 in the S-Pone, Europe for them, we keep discussing, so we're not really done yet, it may 18:22.700 --> 18:31.500 change as we move along, but you have a technology that is used by O-led doctors that 18:31.500 --> 18:39.100 love it, start playing for it, see, immediate benefits of using this technology. Then you have 18:39.100 --> 18:45.020 vertical sectors, S-Pones is in use in a medical industry and mandated in a medical industry 18:45.020 --> 18:54.460 the U-S. We have the C-A-A, that says that the manufacturer is required to have an S-Pone, 18:55.020 --> 19:03.020 it doesn't say much more about horizontal standards as coming, we'll tell you more about the details. 19:03.820 --> 19:09.500 Then we have the happy world where everyone is using S-Pone much natural thing, and we don't even 19:09.580 --> 19:22.060 think about it. So let's take a look. The open source license compliance, I think we're all done. 19:23.500 --> 19:30.860 If we just get the data right, this is something you can use and should use in projects where 19:30.860 --> 19:37.180 haven't been a system with S-Pher or Linux or something else, many different components working 19:37.260 --> 19:44.460 together, you need to make sure that the open source licenses work together for you. 19:46.060 --> 19:52.700 And as I said, this is really where much of the history of software build materials started, 19:53.500 --> 19:59.420 of course this is mature technology. I shouldn't be much worried. 19:59.580 --> 20:09.740 With software supply chain risk management, we're not fully there yet. 20:11.500 --> 20:19.100 If you want to assess the open source you're using, you want tools. We then identify as they 20:19.100 --> 20:24.860 can look up projects and you can do manual due diligence for your risk assessment of only 20:24.860 --> 20:33.500 components you rely on. There are some cool stories out there. I know eBay wants told us that 20:33.500 --> 20:41.980 they are created S-Pones of the whole all the services and they found out which open source projects 20:41.980 --> 20:48.620 they relied heavy on. Went through that list and found a few very important projects for them, 20:49.580 --> 20:58.300 but that was without energy, without funding and funding enough and this is very strange. 20:58.300 --> 21:08.300 They said, well we have resources, so we fixed that problem. That's good, right. So 21:10.060 --> 21:16.700 you can do a lot of cool stuff when you get the view of your IT services and support your 21:16.700 --> 21:23.340 products. You can relate into each other, you can see how the organization works. 21:27.100 --> 21:37.740 This is the evil side, I would say. Vulnerability management, a lot of it for open source relies 21:37.740 --> 21:46.860 on a database called OSV, which use identifiers called package URLs, which we are about to bring 21:46.860 --> 21:56.780 to standardization within the OOSP cyclone DX project. We standardize cyclone DS DX in ECMA last year. 21:58.620 --> 22:03.980 Imagine sitting in meeting, after meeting, going through 600 pages of text. 22:04.220 --> 22:18.540 Because that's cyclone DX for you, but we did it and it's done. Now, for other things that is not covered 22:18.540 --> 22:28.620 by OSV, you have to go to MVD. Did I say it the nation that is the nation in the end? I think 22:28.620 --> 22:35.900 I mentioned America, USA, right? MVD, national vulnerability database. So we rely on that. 22:38.060 --> 22:47.900 Last year, they almost stopped working. The open source project and vendors 22:48.620 --> 22:57.340 default their CVs with the CV program. The MVD imports them and adds the product name, 22:58.300 --> 23:07.980 which we need to match our response. Almost nothing has been done since February last year, 23:07.980 --> 23:16.380 but year. And we have no idea why, if the last funding, this was during the Biden administration, 23:16.940 --> 23:22.380 or if the systems crash because they had reload systems, or whatever happened. 23:23.900 --> 23:28.780 And this means when in the blind, you can run all your checks you want with a beautiful perfect 23:28.780 --> 23:39.260 response, but you won't get any new CVs because they're not there. And this is something 23:40.620 --> 23:47.340 I spend way too much time discussing, then various forums and I need help. 23:49.180 --> 23:53.180 As recently as on Wednesday, we had a meeting with the European Commission, 23:54.140 --> 23:59.820 and we very stressed this fact because they're building a European vulnerability database as part of 23:59.820 --> 24:08.140 these two. And we said, we need something that works. Don't build a copy of the national vulnerability 24:08.140 --> 24:16.540 database. We need something that works. So in summary, we're moving along. 24:17.020 --> 24:26.700 Aspons are useful. I'm convinced that aspons is the tool that we need to have a full overview 24:26.700 --> 24:33.580 of the state or software to be able to do risk assessments, to manage the software, 24:34.300 --> 24:41.820 ask the legislation to see a array, will force us to do. But it's still a bay, but still new 24:41.820 --> 24:51.180 technology. And we need to get all the systems in place to be able to move forward with all this, 24:52.140 --> 24:57.340 and not fall down on every step of the way, even if you get the naming right, 24:58.140 --> 25:03.740 when it's systems federated worldwide systems for checking vulnerabilities. 25:04.300 --> 25:11.100 So the question is really, how do we move forward with all this? 25:14.780 --> 25:25.100 Right? We're at Boston. We're used to work together. We create software together. We create 25:25.100 --> 25:33.340 systems solutions together. Right? We're a community. And it's the same way we need to work 25:33.420 --> 25:42.780 to handle this. The legislators are asking us to help them. And I hear from many projects, 25:42.780 --> 25:49.820 not only Apache, Apache is really ahead of the curve, but Python, the mayvening 25:49.820 --> 25:57.420 systems, many others are onto this. They're adding aspons to looking into the infrastructure 25:57.500 --> 26:03.740 and they're joining the work. But we need more, we need more people, more energy. 26:06.220 --> 26:11.740 But I looked, when I thought to look into this, in that chain, I told you earlier, 26:11.740 --> 26:18.300 the flow of software transparency artifacts, and no one was really working on that. 26:19.020 --> 26:26.300 But I found a small kind of sleeping project within Ovas Psyklon DX called Project Koala. 26:28.300 --> 26:37.980 A nice Psy animal. And we kicked out a live again. So what we're doing is we're creating a 26:37.980 --> 26:46.620 standardised API. It will become an ECMA API called T. And anyone in the room that knows 26:46.620 --> 26:51.980 me know that I never drink coffee, I only drink tea. And that's why the call is drinking tea. 26:52.060 --> 26:58.380 The transparency exchange API. This API will be handled able to handle all types of 26:58.380 --> 27:05.180 aspons, not only cyclone DX. In addition, we'll handle various 27:05.180 --> 27:12.140 attestations like in total attestations, European Union certificate compliance for products, 27:12.780 --> 27:20.460 vex files, c-sa files, other files, that needs to follow the supply chain flow 27:20.460 --> 27:28.860 or in an automatic way. And I need help in this project. There's a URL over there 27:29.900 --> 27:36.860 and you have my contact details on the slides and on the first-end website. We need more people 27:36.860 --> 27:46.300 and we will soon need coders for this. I encourage you to play with open source software. There's 27:46.300 --> 27:54.700 so many tools available out there already. There are scanners that can take your darker containers. 27:54.700 --> 28:00.940 You can beneath the platforms, your binaries, your source code, and produce aspons of various types 28:01.020 --> 28:09.180 and kinds. There are tools to work with your aspons and manage and validate quality in them. 28:10.220 --> 28:17.980 Anthony has a large set of tools on GitHub in open source. And there are management platforms 28:17.980 --> 28:28.060 like UbOS, dependency track. Asponify was just released as one of them. And there are many other 28:28.060 --> 28:35.820 platforms like guac from open SSF. So there is a tool set. If you're running an open source 28:35.820 --> 28:43.660 project, it's not playing with this. But if you're like me, an old C developer, 28:44.620 --> 28:52.220 asterisk, can I make a new one or written in C? We need help. Because we have no packaging lists, 28:52.860 --> 29:01.180 vendor packages, bear make files. How do we create proper response? Or should we just let 29:01.180 --> 29:08.220 Red Hat and Debian and other packages sort that out for us? Maybe. Maybe. But there is a lot of work 29:08.220 --> 29:17.900 to be done here. But there are tools already, major tools that you should spend time on. 29:18.060 --> 29:29.340 The way do you go? But all you're free time. The many organizations working, I'll try to 29:29.340 --> 29:39.900 give you an overview. Who was, of course, has a long tradition of working with application security. 29:40.940 --> 29:47.100 There's a conference coming up in Barcelona and on my where you will have application security 29:47.100 --> 29:54.940 specialists. In over us, we do everything from top 10 lists, which I think you all heard about. 29:54.940 --> 30:00.700 These things you can do in software and web applications. But we also do process support in 30:00.700 --> 30:09.100 over us. If you have questions about that, we have Maxine over there. And we do software and 30:09.100 --> 30:19.820 APIs and standards. Open SSF is part of language foundation. They were created as a result 30:19.820 --> 30:30.860 of plotters working in log-for-J. After log-for-J, some people made an assessment of the amount 30:30.860 --> 30:37.340 the money spent on trying to find out whether or not they had log-for-J. All the man hours and said, 30:37.340 --> 30:44.780 if we can take a small percentage of all that funding and help open source to do better. 30:46.140 --> 30:52.460 And that was the start. So open SSF had software projects. They have a service called 30:52.460 --> 31:00.300 sixth door for signatures, digital signatures or commits and artifacts. They create a lot of 31:00.300 --> 31:10.060 best current practices and many other things. They have one person here in Europe that works 31:10.060 --> 31:17.900 a lot with lobbying, interacting with Inisa and the commission to make sure that open source 31:17.900 --> 31:25.740 software gets treated the right way in the installations. But they have a number of working groups 31:26.460 --> 31:40.700 all ranging from sea compiler options for security to diversity and espom management and many 31:40.700 --> 31:53.980 other things. The ORCVG, as well as Open SSF, has started working groups and projects to help open 31:53.980 --> 32:02.140 source projects in the face of these new regulations. So both of them are both working on 32:02.140 --> 32:08.860 guidelines and support for open source projects but also making sure that all the legislation 32:08.860 --> 32:15.900 and implementation guides are going the right way that there is an understanding on how we work in 32:15.900 --> 32:28.460 open source within the legislation bodies. SPDX org is part of Linux Foundation and they maintain 32:29.260 --> 32:35.900 the list of identifiers for open source licenses that all of us use but they also have a format 32:35.900 --> 32:43.900 for various bill and materials. A cool project you should probably look at as well and of course 32:43.980 --> 32:53.660 my home in this world cycle in the EX where we work both with a large range of software tools 32:54.860 --> 33:02.060 the transparency and shape are standards and many different bill materials described by the 33:02.060 --> 33:11.500 cycle in the EX data modeling language. Right now they are working with bread model standardization 33:11.660 --> 33:19.900 encoding of that all of these organizations are very friendly to newcomers. We don't have to be 33:19.900 --> 33:25.820 an expert but there's always something you can do there's always some discussion you can contribute to 33:26.620 --> 33:33.420 if it's about proofreading documents or if it's about action coming up with new ideas and moving 33:33.580 --> 33:41.580 forward. They usually work with Slack, they have meetings regularly, they have GitHub repositories 33:41.580 --> 33:47.660 and many are here at first term of course and they're also also other conferences. 33:49.740 --> 34:02.300 So please join the work we need help to move despondometer forward and by doing this you will 34:02.380 --> 34:08.780 learn new things. There are so many cool guys within this organization. See if you want to learn 34:08.780 --> 34:15.500 more about application security, software transparency, brisk assessments, threat modeling, 34:15.500 --> 34:21.820 join us. All right you will be part of the solution and that's very important to feel that. 34:22.140 --> 34:32.300 So we need you for despond movements. Come on walk despond walk join us. 34:34.620 --> 34:42.940 And that's what I had to say. I think I have extra minutes. I'll be talking more about transparency 34:42.940 --> 34:50.540 change API in the despond Debrunk tomorrow if I still have any voice after this. Do you have any 34:50.860 --> 35:03.740 questions? We have a microphone running. And if I can't answer, I'll ask for help. I have a lot of 35:03.740 --> 35:10.300 people here who knows. First of all thanks for the talk. As you mentioned there is also 35:10.300 --> 35:17.020 real time dependencies and I was wondering if there's any benchmark or any like service to 35:17.180 --> 35:22.940 validate generated s-bombs because there are multiple s-bombs generator and even if I 35:22.940 --> 35:35.180 miss one dependency that's bad right. That's a very good question. I am working as a consultant 35:35.180 --> 35:42.060 with commercial software developers as well and there are many vendors now trying to say 35:42.060 --> 35:49.900 sell platforms that create the exponents all over your problems and we tested a few of them 35:49.900 --> 35:56.940 and I know Anthony you have more of an answer to this and no one is right so you will have to use 35:56.940 --> 36:03.660 many tools immediate between them and what can you say. Turn on the microphone. 36:13.020 --> 36:22.700 A few weeks ago s-e-i-n-e-s we were contracted by CISA to look at various s-bombs generators 36:22.700 --> 36:31.660 and they came up with nine target applications across a range of languages so Python, 36:31.660 --> 36:43.900 Roscoe, that work is currently being reviewed. We've had early sight of some of the results 36:45.340 --> 36:48.780 that were looking at the differences between cyclone dx and s-pdx. 36:50.460 --> 36:56.860 They're looking at the difference between a source s-bomb and a build s-bomb and they're trying to 36:56.860 --> 37:04.460 understand where the challenges are and some of the highlights are some languages are far better than others. 37:06.140 --> 37:12.540 Particularly languages with good strong language ecosystems. He won't surprise you that languages 37:12.540 --> 37:20.380 like C are real struggle and so I'm hoping that what will come out in the next 37:21.100 --> 37:25.980 maybe later this month depends on what CISA's deadlines are because CISA's in a little bit 37:26.620 --> 37:33.740 change at the moment. We'll publish a summary for us to then take as a community to work out 37:33.740 --> 37:39.100 where we need to end hands. But I think it's a bit we've had a fringe event yesterday 37:39.660 --> 37:45.100 and one of the common things is we really need to have a benchmark of data that we can use our 37:45.100 --> 37:53.900 tools against. So there is a if you want to go out onto the Google SEI harmonization plug 37:53.900 --> 37:58.940 fast I think is you'll find it you'll find the website then you'll see the nine targets 37:58.940 --> 38:05.660 well on get up if you want to go and have a play. But yeah there's some really interesting results 38:05.660 --> 38:13.900 so some are very noisy have lots of data some are very limited the challenges if you are a vendor 38:14.860 --> 38:22.460 or if you're a manufacturer don't just choose one to choose a variety because you're going to 38:22.460 --> 38:30.380 get that enrichment and enrichment in sites. I should have a picture of that I have too many slides 38:30.380 --> 38:35.660 until at the time now but I think I'll continue this talk for another three hours to start the 38:36.140 --> 38:42.300 cable. But you have to have various genres and we have to find ways to mediate that. 38:42.300 --> 38:48.060 By the way our next speaker is the ride and she's going to talk about different things but 38:48.060 --> 38:54.140 Kate Stewart here is one of the leaders for the SPDX projects so if you have any questions about 38:54.220 --> 39:06.460 SPDX is here but I would say what we spend most time on right now or at least I am 39:07.500 --> 39:14.300 is the naming problem. How do we name open source software and commercial software 39:14.380 --> 39:22.060 the old days MVD work with something called CPE and I think we have to live it out for a while 39:22.780 --> 39:30.380 but we can lowly I think modify CPE's works in a worldwide perspective. 39:32.620 --> 39:37.420 The other alternative package URLs is something we're working hard on standardizing 39:38.380 --> 39:48.780 within all of us by an echema. The package URLs was created at start as a way to name stuff 39:48.780 --> 39:57.500 that exists in PIPI, Mavon, all those kind of registers debently in its red hat fedora 39:57.500 --> 40:03.900 where you have a controlled namespace but for the rest of the products where we haven't got 40:03.900 --> 40:11.100 a controlled namespace I will say using the inest names and relying on that controlled namespace 40:11.100 --> 40:18.300 instead of creating a new one is the best way forward but the naming is something we all need to work 40:18.300 --> 40:30.780 on fixing. Another question. So just wanted to follow up on what you actually started talking 40:30.780 --> 40:40.700 about here with the CPE URL thing. First of all thank you within the Clips Adoptium project 40:40.700 --> 40:48.300 we're working on creating an s-bomb for the JDK and we didn't have a Purl or CPE for the actual 40:48.300 --> 40:55.980 source code for the JDK and we were using the cyclone DX dependency track and we noticed that we didn't 40:55.980 --> 41:03.580 get any vulnerabilities until we put a CPE and then dependency track went to the nest database 41:03.580 --> 41:11.660 and found vulnerabilities. So the question is is the nest database still key to only on CPE 41:11.660 --> 41:18.380 is there a mapping between PURLs and CPE's how do we get value out of this fast? 41:19.260 --> 41:30.940 Okay I'll ask the last questions how do we get value of this fast help us okay but CPE's if you look 41:30.940 --> 41:37.500 into that database you'll find Microsoft spacing Microsoft comma spacing Microsoft dot 41:39.180 --> 41:44.620 they had no control of the namespace in history and right now they haven't added many names 41:44.620 --> 41:52.620 they added a handful of names to the CPE's last year so that's a bit out of the picture 41:53.420 --> 42:01.420 the CPE program which is I would say a global federation in east side in Europe has actually 42:01.420 --> 42:11.340 signed up to become a CNA contribute CPE's they are now encouraging their CNAs to add the names 42:11.420 --> 42:19.660 the CPE's when they file a port but this is raw the new there are new guidelines out for the CNAs 42:20.540 --> 42:27.020 it'll take time for them to change the systems and their ways of working but when doing that 42:27.020 --> 42:35.180 the names will actually come from the right place not by from a third party but meanwhile I think 42:36.140 --> 42:42.460 during a transition period you need in your response both a package URL because you want to 42:42.460 --> 42:51.260 check in OSV and a CPE or a couple of CPE patterns to check the other databases that are CPE focused 42:52.620 --> 42:59.580 the CPE program is allowing now the CNAs both add a CPE and a package URL 42:59.980 --> 43:11.500 there is something missing though because in the MED if Daniel the awful Daniel who creates curl which 43:11.500 --> 43:19.500 I told you about earlier if he has a bug there are many other products affected they have 43:19.500 --> 43:29.340 young curl packaging lip curl packaging all the way out to severe or I would say yokto there are so many 43:29.340 --> 43:37.820 curls and in MED they could add a list of affected products which we can't if I understand it 43:37.820 --> 43:46.300 right in the CNA program and that's something we need to get there as well did I randomly answer 43:46.300 --> 43:52.140 your questions the most important one is come down here and sign up with Kate and me and 43:52.140 --> 44:02.780 we'll take care of you another question we still have we hear this way hello it's a follow-up 44:02.780 --> 44:10.540 question I think talking about NVD there's the thing that they stop working last year or it's 44:10.540 --> 44:17.820 unknown what the future of NVDS and so you mentioned that the European Commission or someone in 44:17.820 --> 44:26.700 the European Union also has ideas to make European copy or similar structure and question what what 44:26.700 --> 44:37.580 does the NVD deliver that could not be distributed before what what's the key benefit of using NVD all the 44:37.580 --> 44:53.980 time well if you look at it the database can last year got 40,000 new CVs a large part of that was 44:53.980 --> 45:00.780 that the Linux kernel changed the mind and suddenly followed CV for any bug they have another 45:00.780 --> 45:12.860 large group of CVs was WordPress but historically I would say the MED took the data from CV and added 45:12.860 --> 45:18.700 a few missing items and everyone relied on them doing that so they made a severity assessment 45:18.700 --> 45:26.380 the CVS that we can also discuss for the old afternoon they had something called the CWE which is 45:27.260 --> 45:33.580 weakness enumeration a category of bug if it's a buffer overflow or something else and they had 45:33.580 --> 45:44.540 the name the CP and we all relied on them for doing that we have no idea what's going on and that's 45:44.540 --> 45:50.300 the bad part so most of the community are saying that well if NVD every comes back that's fine 45:50.300 --> 45:56.300 but we've got to move we've got to have this working so a lot of focus is on the CV program 45:58.860 --> 46:07.580 under the needs to regulation that was supposed to come into acting October last year but in 46:07.580 --> 46:13.820 Sweden we haven't seen the 500 proposed so yet it will come at some point to time it's a priority 46:13.820 --> 46:20.060 to say in east I got money to create something called the EU vulnerability database and we were 46:20.060 --> 46:27.900 real scared that it would be a new thing that would mean that as open source developers in Europe 46:27.900 --> 46:33.340 we have to report the multiple places and we can't handle that we have to report it one place 46:33.980 --> 46:42.700 and be done and I think they're getting there I don't think they're going to add on a new 46:42.700 --> 46:50.620 structure they have registered as a CNA they want the country level C-Sorts to become sub CNAs 46:50.620 --> 47:00.940 and report to them as mandated in the needs to and the CNAs so needs to direct them so we'll see 47:01.900 --> 47:08.220 this week I got the first couple of glimpse but we'll continue the dialogue and see what they're 47:08.300 --> 47:14.220 up to in Indonesia but they haven't published any details yet 47:18.140 --> 47:23.340 it's okay for questions maybe underneath you if you can give it to my question 47:26.220 --> 47:32.860 hi this is a question I asked at people working on NSBOM's at configuration management 47:32.940 --> 47:37.420 can't last year and they couldn't give me an answer at some point you mentioned 47:38.380 --> 47:43.020 that there is an SBOM for the software you give to the customer but there is an SBOM for the 47:43.020 --> 47:50.780 test environment there is an SBOM I guess also for the dev environment look how happy thanks 47:51.500 --> 48:00.060 so to talk with this last thing's moving on that front because since last year I couldn't find 48:00.860 --> 48:10.220 much about it yes so there's various types of SBOM's design source build 48:11.580 --> 48:16.700 deploy and run time as well as the analyze which the SAA tools pretty much produce 48:18.060 --> 48:23.980 we're starting to see tooling emerge for the types other than source and build okay 48:24.780 --> 48:28.860 certainly the deploy how things have been configured how things have been deployed we need to put 48:29.340 --> 48:36.060 hooks into the actual deployment tools to record this accurately I haven't seen a good 48:36.060 --> 48:44.780 example of that one yet but I do know that on the SBOM dev room tomorrow you will see one of the 48:44.780 --> 48:50.620 first tools that's actually creating a design SBOM which is looking the tests to the code to the 48:50.620 --> 48:58.060 requirements evidence so we're actually moving in that direction now there are runtime SBOMs out there 48:59.180 --> 49:03.900 again various levels of maturity but we've got to start somewhere 49:10.300 --> 49:19.420 we have half a minute left and he last minutes question otherwise I suggest that you just 49:19.420 --> 49:28.620 come to Oli I see's closing yeah I just want to thank you for all for listening 49:28.700 --> 49:36.220 and thank Kate and Anthony for helping me with questions as I said earlier these are really 49:36.220 --> 49:43.100 early days we're all convinced that this is a core tool moving forward with software transparency 49:43.100 --> 49:49.820 with risk assessments and many other things so please join us in this moment walk best 49:49.820 --> 49:59.980 on walk thank you