WEBVTT 00:00.000 --> 00:20.080 So, the interesting thing as an introduction is I happen to be one of the co-founder of SPDX. 00:20.080 --> 00:27.080 Steve is the creator of Cyclone DX, which are two of the most permanent S-bomb standard. 00:27.080 --> 00:36.080 So, it's great that we can go on stage together. 00:36.080 --> 00:41.360 But basically, you don't need a S-bomb, that's what we want to talk about today. 00:41.360 --> 00:44.760 So, that's our agenda. 00:44.760 --> 00:50.520 I'm Philippe O'Modern, I'm the maintainer of a series of open source projects called 00:50.520 --> 00:51.520 about code. 00:51.520 --> 00:55.960 I'm also a co-founder of clearly defined co-founder of SPDX. 00:55.960 --> 01:00.760 I've got a co- contributor to Cyclone DX, and also behind a small thing we're going to 01:00.760 --> 01:03.960 talk about today called Burl. 01:03.960 --> 01:08.240 That's much easier than switching back and forth. 01:08.240 --> 01:10.240 Is it working now? 01:10.240 --> 01:11.240 Okay. 01:11.240 --> 01:12.240 I'm Steve Springet, hello. 01:12.240 --> 01:13.240 Good afternoon. 01:13.240 --> 01:16.160 I'm on the O'Wass Board of Directors. 01:16.160 --> 01:21.320 I am the leader of, as Philippe mentioned, Cyclone DX, as well as dependency track, and 01:21.320 --> 01:27.000 I'm also chair of ECMA TC54, which, among other things, is stand-alizing packed package 01:27.000 --> 01:32.560 you are on? 01:32.560 --> 01:33.560 It's yours. 01:33.560 --> 01:46.080 I see, we're in the beginning, in the beginning, we had SPDX 1.0. 01:46.080 --> 01:51.600 It was great, because first of all, we had licensed compliance as a thing. 01:51.600 --> 01:57.080 A couple of years later, I actually had the need to track software and hardware inventories, 01:57.080 --> 02:01.920 and be able to do that in a system, it was called dependency track, version 1. 02:01.920 --> 02:07.080 I had an intern actually, right at four, and it was horrible piece of software, but not 02:07.080 --> 02:11.640 because of the intern's fault, because of my fault, for sure, but it was a horrible piece 02:11.640 --> 02:12.640 of software. 02:12.880 --> 02:18.760 For the first time, it allowed me to track the hardware and the software inventories, 02:18.760 --> 02:25.400 and using CPE's, it allowed me to identify vulnerabilities in that inventory. 02:25.400 --> 02:27.760 And I have a red line here. 02:27.760 --> 02:35.120 And that red line is reminiscent of the CPE health that we were all kind of living in, right? 02:35.120 --> 02:36.840 Fuzzy matching health. 02:36.840 --> 02:38.240 It was not good. 02:38.280 --> 02:45.800 It wasn't until, let's see, OSS index came out the next year, and OSS index was a small 02:45.800 --> 02:49.000 little project from a company called Vorescurity at the time. 02:49.000 --> 02:51.160 They were later acquired by some of the type. 02:51.160 --> 02:58.800 But OSS index had the ability to at least query by MD5-HASH or SHA1-HASH. 02:58.800 --> 03:04.000 That was certainly an improvement, but it required at least that you actually produced 03:04.000 --> 03:07.560 your inventory in some kind of a build process. 03:07.560 --> 03:14.880 It really wasn't until package URL really started to become a thing in 2017, that finally 03:14.880 --> 03:22.760 we actually had a much more precise mechanism of identifying a specific library and that 03:22.760 --> 03:25.480 version of that library. 03:25.480 --> 03:31.600 Around the same time, CycloneDex1.0 was coming out, same time the package URL was, and 03:31.640 --> 03:38.200 we quickly realized the value of using package URL for basic vulnerability management. 03:38.200 --> 03:44.280 So version 1.0 of Cyclone absolutely had support for Pearl, and for the first time with 03:44.280 --> 03:50.880 dependency track version 3, which wasn't the crappy piece of software, we were actually able 03:50.880 --> 03:56.160 to use an S-bomb and do basic vulnerability management for the very first time. 03:56.160 --> 04:02.280 S-pdx2.2 was released a couple of years later, and also included support for CPE as 04:02.280 --> 04:06.360 well as Pearls. 04:06.360 --> 04:14.080 So the basic use case for Pearls and S-bomb's in general was vulnerability management. 04:14.080 --> 04:22.360 For the first time, it was a human readable, but machine-processable software identifier, right? 04:22.360 --> 04:25.200 And those are the key important ingredients. 04:25.200 --> 04:30.640 If you think about a hash or a checksum, that's essentially the coordinates, like GPS, 04:30.640 --> 04:36.000 the exact location of where your barbecue grill is in your backyard. 04:36.000 --> 04:38.840 A Pearl is much like your address, right? 04:38.840 --> 04:46.600 You give your street address out, you give some snail mailbox, and that's essentially 04:46.600 --> 04:48.360 what Pearl is, right? 04:48.360 --> 04:51.200 A little bit more granular. 04:51.200 --> 04:57.480 The portability of the components, the inventory of components, is kind of essential 04:57.480 --> 05:02.560 for the vulnerability management use case, as well as prominence of those components. 05:02.560 --> 05:06.920 But those are really the only key ingredients. 05:06.920 --> 05:15.480 The interesting part about S-bomb as a thing is it wasn't until 2020 when we started really 05:15.520 --> 05:21.480 talking about regulation, that the graph really starts to show an upwards trend. 05:21.480 --> 05:25.600 Now, we're just looking at the cyclone DX tool center, because that's what I have data 05:25.600 --> 05:26.600 on. 05:26.600 --> 05:30.040 But the same trend exists for S-PDX. 05:30.040 --> 05:31.640 It's no different. 05:31.640 --> 05:37.320 What we see is that with regulation, this dotted line represents the executive order 05:37.320 --> 05:45.040 14028 in the United States, but CRA, everything else is on the right side of this chart. 05:45.040 --> 05:51.360 With regulation, we see an explosion of available tools that support S-bombs. 05:51.360 --> 05:55.080 But really, Pearl is what it made it all happen. 05:55.080 --> 06:01.760 Pearl is what allowed us to go from CPE's, which allowed some degree of automation, to 06:01.760 --> 06:06.480 Pearl, which allowed us to do hyper-automation. 06:06.480 --> 06:11.280 S-bombs describe the software composition, but Pearls make those descriptions machine 06:11.280 --> 06:12.680 readable and actionable. 06:15.040 --> 06:27.200 And actually, that's not only Steve saying there was a study published, I think, around the 06:27.200 --> 06:34.960 soft S-bomb for healthcare, where the effort, I couldn't find the URL anymore, but 06:34.960 --> 06:40.280 said essentially an S-bomb with a Pearl is not something that's actionable. 06:40.280 --> 06:44.160 So, Pearl, who has not heard about Pearl? 06:45.040 --> 06:46.320 Raise your hand. 06:46.320 --> 06:47.320 Okay, that's okay. 06:47.320 --> 06:48.320 You can exist. 06:48.320 --> 06:51.160 This presentation is not for you. 06:51.160 --> 06:59.920 But so, it's a very stupid dumb dumb, small string that you can use to point to a package. 06:59.920 --> 07:07.400 And you just look at the package manifest, you can find what the Pearl is. 07:07.400 --> 07:14.560 The great thing about it is that unique naming is something that's delegated to package 07:14.560 --> 07:15.560 a system. 07:15.560 --> 07:17.960 And PM may learn and likes. 07:17.960 --> 07:24.200 So, zero friction from what you see as a software developer to what's the name that 07:24.200 --> 07:28.280 you can use across a system. 07:28.280 --> 07:34.160 It's not an McMaster standard since December 6, anybody from McMahe here? 07:34.160 --> 07:36.160 Oh, Steve, at least. 07:37.160 --> 07:42.640 Many of you have been participating in this standardization effort, so thank you very much. 07:42.640 --> 07:47.480 It's on the way to become an ISO standard, which is very humbling for a very tiny string like 07:47.480 --> 07:48.480 that. 07:48.480 --> 07:59.520 It's already actually included in S-bomb Vex, up and Vex, sorry, but also in ISO standard, 07:59.520 --> 08:05.240 which is kind of weird where the standard was not completed and it was already part of ISO 08:05.240 --> 08:06.240 standard. 08:06.240 --> 08:12.400 Yeah, no, that's cool, which is a good thing I've seen from the standard perspective is 08:12.400 --> 08:17.160 making sure you the standard is adopted before it becomes a real standard. 08:17.160 --> 08:25.800 So, Pearl, enable actionable S-bomb and S-C-A, wizard it for vulnerabilities. 08:25.800 --> 08:29.480 The point is you can look up and enrich information. 08:29.480 --> 08:33.920 You can share Vex, I see there's a guide that creates a standard call up and Vex, which is 08:33.960 --> 08:40.600 all based on package URLs, so it's also the case for S-C-A and S-C-A video. 08:40.600 --> 08:50.640 The whole point is that you scan code, you get a Pearl, you can look up in your wrongs database. 08:50.640 --> 08:55.640 There's a lot of information available in different tools here. 08:55.640 --> 09:03.560 The point is that you can use it across the board and if you were to drop anything about 09:03.560 --> 09:09.680 S-bombs and just focus on Pearl and this Pearls would be correct, that would be a massive 09:09.680 --> 09:14.840 set forward towards a better supply chain. 09:14.840 --> 09:26.840 So, the goal besides to get everyone to adopt Pearls is allowing us to share better inventories. 09:26.840 --> 09:33.520 Obviously cyclone and S-P-D-D-F supported, but quick note, we've supported 09:33.560 --> 09:40.240 I work for a company called ServiceNow, we've actually had support for Pearl in our inventory 09:40.240 --> 09:46.480 of all the things that we have, both internally and externally, since about 2019. 09:46.480 --> 09:58.560 So we're tracking upwards of 100,000 components internally and Pearl is our identifier for everything. 09:58.560 --> 10:05.640 So hopefully we can disclose better vulnerabilities, which don't require us to search 10:05.640 --> 10:16.320 with, like we used to do in the past with S-P-E-S, S-V-E since October 29th, as merged support 10:16.320 --> 10:18.520 for package URL in the S-B-S-Q-M-O. 10:18.520 --> 10:26.720 Open V-X-C-S-F, OS-V, all support package URL and we mention also OS-S-N-X, which has been 10:26.760 --> 10:30.960 kicked by Pearl for a long period of time. 10:30.960 --> 10:34.400 It's adopted industry-wise, I won't go into the details. 10:34.400 --> 10:40.160 The slides will be available, upload it on the talk afterwards. 10:40.160 --> 10:47.120 The thing is that committee adoption is great, but we need better and standardized Pearl. 10:48.080 --> 10:49.600 OK. 10:49.600 --> 10:55.600 Unfortunately, S-B-M quality and clarity is a problem. 10:55.600 --> 11:03.040 We probably, many of you may know about it, but it's going to be a growing issue where 11:03.040 --> 11:08.320 different tools produce different outcomes on the exact same input. 11:08.320 --> 11:15.440 It's going to create a lot of friction because people just discuss about, oh, your S-B-M is not 11:16.080 --> 11:18.800 right, my tool produce better S-B-M than yours. 11:18.800 --> 11:24.480 We will need to find a way to lower the temperature on all these discussions. 11:24.480 --> 11:29.440 There's a project led by Marcel over there, raise your hand, 11:29.440 --> 11:34.080 go digital the means that producing S-B-M, benchmarks, another one from 11:34.080 --> 11:38.720 Gagolix, Atari, from Nokia, called S-B-Q-E.org. 11:38.720 --> 11:43.760 The point is working on ensuring that our tools produce 11:43.760 --> 11:47.920 correctness, but I'm essentially correct, Pearl is going to be super important. 11:47.920 --> 11:51.680 We need to validate Pearl's, but your initiative is going on there. 11:51.680 --> 11:54.720 We've built tools to help you do that. 11:54.720 --> 11:59.600 And Bell benchmark, I just talk about it, you have all the links. 11:59.600 --> 12:04.960 Eventually, with these tools, there's no excuse, not to produce correct 12:04.960 --> 12:10.800 Pearls in your tools, or in the tools of your vendors, or in the tools of your 12:10.800 --> 12:15.760 supply chain partners, which ideally should never produce drunk pearls. 12:15.760 --> 12:19.520 You should give them access to these open tools and reject 12:19.520 --> 12:22.640 invalidase bomb with invalid pearls as drunk. 12:22.640 --> 12:29.600 As Philippe was mentioning, Pearl is now a T-C-54 standard. 12:29.600 --> 12:34.240 It's on its way to becoming an ISO standard. 12:34.240 --> 12:39.520 T-C-54 is a group focusing specifically on software and system transparency. 12:39.600 --> 12:44.400 If there are any specifications that are community-based, 12:44.400 --> 12:49.520 that you believe would be worthy of an international standard, 12:49.520 --> 12:53.920 that might fit this realm of software and system transparency. 12:53.920 --> 12:55.760 Please reach out to me. 12:55.760 --> 12:59.600 Actors have been a really great organization to work with. 12:59.600 --> 13:04.720 They really, what we did real briefly is I dissected, essentially, 13:04.720 --> 13:09.280 I decompose T-C-39, which is JavaScript, or JavaScript, right? 13:09.280 --> 13:13.520 And how in the world can an entire programming language 13:13.520 --> 13:17.120 produce an international standard every single year? 13:17.120 --> 13:21.440 And I decompose exactly what they did, and we reproduced it. 13:21.440 --> 13:26.400 It's now the model for all future T-Cs that are community-based with an ECMA. 13:26.400 --> 13:31.120 So, if we, as a community, if we want to start developing standards, 13:31.120 --> 13:35.360 that have a path to ISO and elsewhere, 13:35.360 --> 13:37.680 ECMA might be a really good place for you. 13:37.680 --> 13:40.880 So reach out to me if that's, that's an interest. 13:45.760 --> 13:48.960 Yeah, so we're trying to bring better pearls. 13:48.960 --> 13:51.360 Lots of initiatives in the ecosystem. 13:54.000 --> 13:59.360 One, I'd like to point out is a series of beach cleaning operations, 13:59.360 --> 14:05.200 boring, a term that was coined by MunaWar from a benrefactory last year. 14:05.200 --> 14:09.280 And basically, it's rather than to fix things, the downstream is work with a 14:09.280 --> 14:14.080 ecosystem, to bring clarity, clarity, specific cleaning skills, 14:14.080 --> 14:17.680 for next packages, rust, and mevan. 14:22.400 --> 14:23.760 Let me move forward. 14:23.760 --> 14:28.320 Another thing is clear defined, which is a project at the OSI, 14:29.920 --> 14:36.080 which has 55 millions of packages can, not always really available, 14:36.080 --> 14:38.480 because there's a tiny APIs that we're working on two things. 14:38.480 --> 14:42.880 First, ensuring there's a pearl API for that, 14:42.880 --> 14:46.400 because every service user is a pretty defined as build pearl adapters, 14:47.360 --> 14:50.880 but they're in fact an ensure it can define pretty, 14:50.880 --> 14:53.840 predates the existence of pearl, by the way. 14:53.840 --> 14:55.760 And we want to make sure that this data, 14:55.760 --> 14:58.080 kit by pearl, is way deavailable to everyone. 14:59.520 --> 15:02.800 In the end, pearls and verse need you. 15:02.800 --> 15:06.000 There's really something that I want to highlight, 15:06.000 --> 15:07.760 especially in relation to the producer, 15:07.760 --> 15:09.520 when I was not allowed to speak more. 15:10.480 --> 15:18.320 Bineries and CC++ is a place where pearl is as a dark spot. 15:19.440 --> 15:24.240 We rely on the fact that you have any ecosystem. 15:24.240 --> 15:26.880 If you're not incorporated in the ecosystem, 15:26.880 --> 15:30.000 for small projects like, say, the Linux kernel, 15:30.000 --> 15:32.480 open SSL, things that's really power, 15:32.480 --> 15:37.760 most of the way today, there's no pearl, or they can be an ugly generic pearl. 15:40.000 --> 15:43.200 We are working with these communities, 15:43.200 --> 15:47.840 especially there's a project in the ISO C++ community, 15:47.840 --> 15:50.240 called CPS, that Ariane, you know about. 15:52.640 --> 15:54.240 OK, we can discuss about it. 15:54.240 --> 15:58.240 But there's efforts there for C-Make to find ways 15:58.240 --> 16:04.240 to get better informations in Bineries and basically how you collect 16:04.240 --> 16:07.040 information from C-Make builds in terms of configuration. 16:07.360 --> 16:11.840 There's also NAMASAN in the back. 16:11.840 --> 16:14.880 NAMASAN, please raise your hand, higher. 16:14.880 --> 16:20.320 NAMASAN is a project called S3, E-S-S-T-R-A. 16:20.320 --> 16:26.880 And S3 is a set of plugins for GCC and L-V-M 16:26.880 --> 16:31.120 that can collect all the dependencies in your build, 16:31.120 --> 16:33.360 and eventually inject that in your L. 16:33.440 --> 16:36.240 So you have literally an S-Bomb in your health 16:36.240 --> 16:40.160 that you can keep a drop. 16:40.160 --> 16:41.280 And that's pretty much it. 16:41.280 --> 16:42.800 We've received lots of support. 16:42.800 --> 16:46.240 Some of you are busy in the European Union here. 16:46.240 --> 16:48.000 Raise your hand. 16:48.000 --> 16:49.040 Do you pay taxes? 16:49.040 --> 16:51.120 Raise your hand? 16:51.120 --> 16:52.560 Thank you for your help. 16:52.560 --> 16:54.880 And for your support to make this happen. 16:54.880 --> 16:56.320 So you pay for that. 16:56.320 --> 16:57.360 You can use it now. 17:03.760 --> 17:05.760 Thank you for your help. 17:10.480 --> 17:12.160 Do we have time for a question? 17:12.160 --> 17:13.120 Please. 17:13.120 --> 17:13.920 One. 17:13.920 --> 17:15.680 No, no, no. 17:15.680 --> 17:18.880 Okay, no questions.