WEBVTT 00:00.000 --> 00:08.000 All right, welcome. 00:08.000 --> 00:15.000 Finally enough, I think it was exactly here in 2018 that it was standing in this exact 00:15.000 --> 00:16.000 samurai checked it. 00:16.000 --> 00:21.000 Talking about some single package URL of parallel, actually introducing it a bit to the 00:21.000 --> 00:22.000 world. 00:22.000 --> 00:25.000 So the dev room schedule is a bit behind. 00:25.000 --> 00:29.000 So with a show of hand, who has not heard about package URL or 00:29.000 --> 00:32.000 parallel. 00:32.000 --> 00:35.000 Okay, so we still go through the presentation. 00:35.000 --> 00:37.000 We still go through the presentation. 00:37.000 --> 00:42.000 Otherwise, I would have just passed and yield it to the next speaker. 00:42.000 --> 00:46.000 So I'm the lead designer of a project called About Code and 00:46.000 --> 00:47.000 Scan Code. 00:47.000 --> 00:53.000 I'm also your lead commenter of a few S-bomb-related standards like 00:53.000 --> 00:58.000 SPDX or I'm also co-contributed to secure the X because standards, you know, 00:58.000 --> 01:00.000 we'll like them, we want more of them. 01:00.000 --> 01:02.000 So we can pick and choose. 01:02.000 --> 01:07.000 And everything I do is free an open source software, 01:07.000 --> 01:10.000 and that's an open standards. 01:10.000 --> 01:17.000 So if we go back in 2017, the problem I had was simple. 01:17.000 --> 01:23.000 We're building this tool called Scan Code, which scans for package origin, 01:23.000 --> 01:26.000 license, and a bit of dependencies. 01:26.000 --> 01:29.000 Actually, the maintenance somewhere in the room. 01:29.000 --> 01:31.000 Raise your hand. 01:31.000 --> 01:35.000 And we had this problem, which is users were saying, 01:35.000 --> 01:37.000 what do you do about security? 01:37.000 --> 01:39.000 And we said, we do nothing. 01:39.000 --> 01:40.000 What do you do about security? 01:40.000 --> 01:41.000 We do nothing. 01:41.000 --> 01:44.000 And a certain time it says, okay, let's try to do something. 01:44.000 --> 01:51.000 And we were trying to look up in something which was called the OSVDB. 01:51.000 --> 01:57.000 Other known also as the open source vulnerability database, 01:57.000 --> 01:59.000 which was absolutely not open source, by the way. 01:59.000 --> 02:00.000 It's fiercely proprietary. 02:00.000 --> 02:02.000 It became something called risk-based security. 02:02.000 --> 02:04.000 It was a really open washing. 02:04.000 --> 02:07.000 And another one called the National Volunteer Database in the US. 02:07.000 --> 02:09.000 And this was a very painful process. 02:09.000 --> 02:14.000 We were just cracking our head, trying to find if this package we had scan 02:14.000 --> 02:18.000 was actually the bare of non-secret issue. 02:18.000 --> 02:20.000 It was really painful. 02:20.000 --> 02:22.000 We did craft this small standard. 02:22.000 --> 02:24.000 Well, it wasn't standard at the beginning. 02:24.000 --> 02:28.000 It was just a way for us to literally have an identity failure. 02:28.000 --> 02:32.000 So we could look up in the room to the database. 02:32.000 --> 02:35.000 And since existing volume to the database is the new, 02:35.000 --> 02:37.000 how to look up that I don't failure, we created one. 02:37.000 --> 02:38.000 Because why not? 02:38.000 --> 02:40.000 You know, more power. 02:40.000 --> 02:41.000 It's not really a volume to the database. 02:41.000 --> 02:46.000 It's more an aggregated database of existing non-secret issues. 02:46.000 --> 02:48.000 Keep by-pro. 02:48.000 --> 02:53.000 And the problem here, simple, is you think about OpenSSL, 02:53.000 --> 02:56.000 or something like five utils. 02:56.000 --> 03:01.000 You have one in Ruby gems, one in NPM, one in PIPI, 03:01.000 --> 03:04.000 OpenSSL is speculated by multiple distrusts, 03:04.000 --> 03:09.000 sometimes it's vendor, in crates, in Python wheels. 03:09.000 --> 03:13.000 So each of these are subtly similar and subtly different. 03:13.000 --> 03:17.000 And you need to be able to talk about then if shunty to figure out 03:17.000 --> 03:19.000 is this package used? 03:19.000 --> 03:21.000 Is this package vulnerable? 03:21.000 --> 03:23.000 It's going to fix. 03:23.000 --> 03:27.000 So that was the title slides back then. 03:27.000 --> 03:31.000 We ended up setting up more of a Braille, 03:31.000 --> 03:35.000 like Logo for now, rather than a cat's, 03:35.000 --> 03:37.000 but it was a very tiny cat. 03:37.000 --> 03:41.000 On the side, it was a challenge, if I recall, 03:41.000 --> 03:44.000 to find who actually had taken this picture. 03:44.000 --> 03:47.000 And what was the license? 03:47.000 --> 03:50.000 So we have this problem. 03:50.000 --> 03:53.000 You know, looking up from scan to package. 03:53.000 --> 03:57.000 And we needed a way to do that. 03:57.000 --> 04:00.000 And others were having the same problem. 04:00.000 --> 04:02.000 Folks, for instance, at Sonataip, 04:02.000 --> 04:04.000 with the OSS index, had the problem. 04:04.000 --> 04:08.000 Initially, it was an ID that came from a company called JetFrog, 04:08.000 --> 04:12.000 which does something called the Artifactory. 04:12.000 --> 04:16.000 They had a project with Google Graphias. 04:16.000 --> 04:20.000 And they had something which looked very much like a package URL, 04:20.000 --> 04:24.000 that wasn't fast forward today. 04:24.000 --> 04:26.000 We extracted the spec. 04:26.000 --> 04:31.000 It's hard work to make sure you modularize any bit of your project to reuse. 04:31.000 --> 04:32.000 But it's useful. 04:32.000 --> 04:33.000 Sometimes it is. 04:34.000 --> 04:40.000 We also went through the excruciating process of making it eventually real standard. 04:40.000 --> 04:44.000 Because the seat of the pen spec written by somebody that knows nothing about it, 04:44.000 --> 04:48.000 is a pain for everyone to implement. 04:48.000 --> 04:50.000 And should out to the folks who make more, 04:50.000 --> 04:52.000 I can hear you in the room. 04:52.000 --> 05:00.000 Hey, that's been really awesome as part of a technical committee called TCC54. 05:00.000 --> 05:03.000 You may not know about ECMA, but you know about JavaScript. 05:03.000 --> 05:05.000 Sorry for you. 05:05.000 --> 05:08.000 But there's something called TCC39 at ECMA, 05:08.000 --> 05:11.000 which has been standardizing the JavaScript language. 05:11.000 --> 05:15.000 And TCC54 is about the same, 05:15.000 --> 05:17.000 but for cyclone DX, 05:17.000 --> 05:20.000 and software supply chain transparency, 05:20.000 --> 05:23.000 and really to the PR, including PR. 05:26.000 --> 05:29.000 So, it's a standard. 05:29.000 --> 05:31.000 Now, and that was painful. 05:31.000 --> 05:34.000 But it became a standard on, 05:34.000 --> 05:37.000 I think, you know better. 05:37.000 --> 05:38.000 December fix. 05:38.000 --> 05:39.000 Okay. 05:39.000 --> 05:42.000 Interestingly enough, it was already back then, 05:42.000 --> 05:44.000 already part of an ISO standard, 05:44.000 --> 05:47.000 which is the OECCSCF20. 05:47.000 --> 05:50.000 It was already part of SPDX and cyclone DX. 05:50.000 --> 05:56.000 And it became merge into the CV schema. 05:57.000 --> 06:00.000 As an alternative to what's called CPI, 06:00.000 --> 06:04.000 back in on the 29th of October 2025. 06:04.000 --> 06:07.000 And it's interesting because I had a bit of back and forth 06:07.000 --> 06:10.000 with the MITRE people from CV says, 06:10.000 --> 06:12.000 when is it becoming a standard? 06:12.000 --> 06:15.000 Because it's a bit annoying for us if we merge it into CV, 06:15.000 --> 06:17.000 but it's not yet a standard. 06:17.000 --> 06:20.000 So, there's another standard coming up, 06:20.000 --> 06:23.000 which is very relevant to package management, 06:23.000 --> 06:25.000 not only for vulnerability, but also for dependency resolution, 06:26.000 --> 06:30.000 which is how to have the command syntax to say, 06:30.000 --> 06:34.000 this is a functional dependency set of version that I depend on, 06:34.000 --> 06:37.000 or this is the set of vulnerable versions. 06:37.000 --> 06:38.000 And that's it. 06:38.000 --> 06:40.000 It's everywhere. 06:40.000 --> 06:43.000 I think it helps makes, 06:43.000 --> 06:47.000 as bomb and software conversion that is actionable. 06:47.000 --> 06:51.000 I like to say that if you throw away all the as bombs, 06:51.000 --> 06:53.000 all the alphabet soup, 06:53.000 --> 06:58.000 and you just provide the list of pearls of what's in your product software app, 06:58.000 --> 06:59.000 and share that with others. 06:59.000 --> 07:03.000 That will be a massive step forward in transparency, 07:03.000 --> 07:06.000 and actually making what we call the software supply chain, 07:06.000 --> 07:09.000 eventually something that resembles a chain. 07:09.000 --> 07:10.000 That's what I have to say. 07:10.000 --> 07:12.000 It's used everywhere. 07:12.000 --> 07:14.000 Again, ways of cycling the X's off. 07:14.000 --> 07:17.000 We have a lot of initiative to work on better pearls. 07:17.000 --> 07:22.000 I'll make sure I attack the slides to the first damage 07:22.000 --> 07:28.000 and the cloud. 07:28.000 --> 07:30.000 We need your help. 07:30.000 --> 07:34.000 One duck spot that I want to talk about, 07:34.000 --> 07:38.000 and actually this guy in blue there that I'd pointing my finger to, 07:38.000 --> 07:42.000 may exactly block post on that topic, a couple days ago, 07:42.000 --> 07:43.000 which is the small set of cc plus plus packages. 07:43.000 --> 07:45.000 And that's going to be my last word. 07:45.000 --> 07:47.000 That poor internet today. 07:47.000 --> 07:49.000 Small things like openness, 07:49.000 --> 07:51.000 a cell, 07:51.000 --> 07:56.360 There's a dark spot, because they're unincorporated. 07:56.360 --> 08:03.920 There's no proof of them, and they want to be able to report actionable vulnerabilities. 08:03.920 --> 08:06.880 We have the vessel, which is the CV schema. 08:06.880 --> 08:08.280 We have enough shelf standard. 08:08.280 --> 08:13.240 We now are trying to think whether we can do kind of community days, mini registry to provide 08:13.240 --> 08:19.080 just the name, people can rely on to reference to the kernel of an SSL unlike. 08:19.160 --> 08:25.680 I had a long discussion yesterday, with a guy that's meant to have Linux stable. 08:25.680 --> 08:30.960 That's some of you may know called Greg Koratman, who's kind of the top dog in the space. 08:30.960 --> 08:31.960 Anyone else? 08:31.960 --> 08:37.720 He wants a girl so he can, he's the number two producers of CV in the world today. 08:37.720 --> 08:39.040 Just behind word fans. 08:39.040 --> 08:43.200 He wants a girl so he can attach that to every of his CV. 08:43.200 --> 08:46.760 So please join help us make that a better place. 08:46.760 --> 08:48.760 That's it. 08:48.760 --> 08:59.960 I'm behind on time, so if you want to take questions, I'll be outside. 08:59.960 --> 09:03.560 Okay, so go for questions. 09:03.560 --> 09:05.280 Who hates Pearl? 09:05.280 --> 09:08.080 I'm making the questions. 09:08.080 --> 09:09.720 I need more haters. 09:09.720 --> 09:11.080 I don't have enough. 09:11.080 --> 09:13.080 Good, one, two, three. 09:13.080 --> 09:14.080 Perfect. 09:14.080 --> 09:15.080 Okay. 09:15.080 --> 09:16.080 Good. 09:17.040 --> 09:22.760 So we work a lot with the pearls in their spots and in my opinion, it's the right approach to do it. 09:22.760 --> 09:27.760 But the problem really is that many of the officers' tools, even if there is a Pearl in the 09:27.760 --> 09:33.120 Espoam, they don't care and they just evaluate some other things like the name or the version. 09:33.120 --> 09:36.400 But that you get completely different results across the tools. 09:36.400 --> 09:37.400 Yes. 09:37.400 --> 09:39.040 So it's a big question. 09:39.040 --> 09:44.280 Yeah, so the repeating the question, different tools return different package 09:44.280 --> 09:47.280 URL for the same input. 09:47.280 --> 09:52.840 No, no, if you have an Espoam with a package URL, ask them the tools, the sketch, not 09:52.840 --> 09:53.840 there. 09:53.840 --> 09:57.840 The generators, but the CV is going to ask them whatever which evaluates the Espoam, 09:57.840 --> 10:02.800 they don't look at the Pearl, but they use other fields from the Espoam and evaluates 10:02.800 --> 10:03.800 that. 10:03.800 --> 10:04.800 The symbolites. 10:04.800 --> 10:10.520 Yeah, so the problem is simple is that there are only a few volunteer database today, 10:10.520 --> 10:12.480 which are fully available to the by Pearl. 10:12.480 --> 10:13.840 The OSV is doing a great job. 10:13.840 --> 10:16.720 You have OSS index from Sonataip. 10:16.720 --> 10:19.280 We have one called Van Gogh Code. 10:19.280 --> 10:26.000 There was a meeting earlier this week for an initiative among many folks that do volunteer database 10:26.000 --> 10:28.320 and deal with volunteer management to try to find a way. 10:28.320 --> 10:31.280 How can we better exchange that out? 10:31.280 --> 10:36.880 If we have somebody in the kernel that manage CVs, that stops putting Pearls in all their 10:36.880 --> 10:41.600 CVs, eventually we'll get information upstream at the root. 10:41.600 --> 10:43.000 That will make it more efficient. 10:43.000 --> 10:48.600 But there's another related problem which is tools in Van Gogh's package URL. 10:48.600 --> 10:54.560 Because I was not making the spec strict enough and clear enough, it's in point. 10:54.560 --> 10:55.560 So there's suicide. 10:55.560 --> 11:00.640 The in Van package URL or the maker package URL. 11:00.640 --> 11:08.600 I was with last year or year, maybe a year or a half ago, working with large company, 11:08.600 --> 11:12.840 which had basically about every single tool in the market in different teams. 11:12.840 --> 11:14.720 More important to them is this, it's nice. 11:14.720 --> 11:19.240 We should use up and source and the project we did was to scan, 11:19.240 --> 11:24.520 have each of the product team in this commercial company, scan a bunch of very standard 11:24.520 --> 11:27.520 based container image. 11:27.520 --> 11:32.160 With their own commercial tool, share the SBOM, so we would compare the stuff. 11:32.160 --> 11:37.920 We saw it would be a two weeks job that was easy PC, get a cyclone DX, literally almost 11:37.920 --> 11:41.680 did them, and it was a total freaking mess. 11:41.680 --> 11:48.120 I mean, we really had our eyes crying in valid schema, don't even talk about just even 11:48.120 --> 11:52.640 very jazzy on in some case, which didn't even pass. 11:52.640 --> 11:58.120 In one case, which I always use as an interesting, really problematic case, 11:58.120 --> 12:05.720 base universal image from Red Hat, which is all our pins. 12:05.720 --> 12:11.160 It is one of the commercial tools that detected a debutant package. 12:11.160 --> 12:16.160 It was not fundamentally entirely wrong because it was the correct base version for that 12:16.160 --> 12:23.160 package, but it was not the correct patch, and last I looked, Red Hat doesn't package 12:23.160 --> 12:27.080 the debutant package, yes, maybe they should. 12:27.080 --> 12:33.040 You could, many of us could do this kind of Frankenstein image, but Red Hat doesn't do 12:33.040 --> 12:34.040 it. 12:34.040 --> 12:40.680 One, you're trying to fix the vulnerable package that's a debutant package in Red Hat. 12:40.680 --> 12:45.800 You're going to scratch your head and waste a lot of energy trying to find the right solution. 12:45.800 --> 12:49.160 You could install a PTGET on the Red Hat image too. 12:49.400 --> 12:57.600 The mask, RPM, is not really vulnerable in another issue. 12:57.600 --> 12:58.600 Thank you.