WEBVTT 00:00.000 --> 00:11.400 So I thought it was going to be very hard to actually give a talk after the talk that was 00:11.400 --> 00:13.440 just given which was amazing. 00:13.440 --> 00:17.040 But I didn't know what was going to do that without any slides for you to see. 00:17.040 --> 00:21.520 So that adds like an extra dimension to it. 00:21.520 --> 00:28.080 So we're going to talk about, you're going to be able to see the slides later on. 00:28.080 --> 00:32.560 We're going to talk about the attestations. 00:32.560 --> 00:39.000 To talk about the attestations we have to talk about is the requirements as a manufacturer, 00:39.000 --> 00:44.440 you have to integrate a component into your product. 00:44.440 --> 00:48.160 And there are essentially two key things that you have to do. 00:48.160 --> 00:51.520 The first thing is you have to do do diligence when you do this and then get into what 00:51.520 --> 00:52.520 that means. 00:52.520 --> 00:57.640 And the second thing is you have to handle your vulnerability obligations throughout the whole 00:57.640 --> 01:02.080 life cycle of your own product for all of your dependencies. 01:02.080 --> 01:08.080 And for open source, that includes not only your own good direct dependencies, but all 01:08.080 --> 01:11.040 of your transit of dependencies. 01:11.040 --> 01:20.520 So do diligence is essentially, this is really hard to do without. 01:20.520 --> 01:23.680 You have being able to watch the slides. 01:23.680 --> 01:32.000 So do diligence is what you have to do to avoid compromising the cybersecurity of your own 01:32.000 --> 01:33.640 product. 01:33.640 --> 01:39.440 And what's important is when you put in a component, you do not have that component. 01:39.440 --> 01:45.080 There's not itself have to meet all of the requirements of the CRA. 01:45.080 --> 01:49.840 And what's also very important is that the level of do diligence has to be proportionate 01:49.840 --> 01:56.400 to the risk of the component itself, but also how you're integrating that component 01:56.400 --> 02:03.320 into your own product and so your own product itself. 02:03.320 --> 02:11.600 And your vulnerability handling obligations, so that's the second point, they apply to your 02:11.600 --> 02:17.600 product and its entirety, including, of course, all of its components. 02:17.600 --> 02:29.760 So you're going to have to handle vulnerability issues throughout the whole life cycle. 02:29.760 --> 02:36.920 So there are essentially four ways that manufacturers can meet the obligations that they 02:36.920 --> 02:40.720 have when they include components. 02:40.720 --> 02:44.160 The first way is to do everything in-house. 02:44.160 --> 02:47.920 And that, obviously, as a lot of work, when you have to consider all options that have 02:47.920 --> 02:49.920 dependencies. 02:49.920 --> 02:56.280 The second is essentially to rely on a supplier that packages the open source components 02:56.280 --> 03:00.000 for you and handles all of those obligations themselves. 03:00.000 --> 03:04.920 That's not going to be available on every industry, but this is clearly a business model 03:04.920 --> 03:08.920 and some places, especially in IoT. 03:08.920 --> 03:13.760 The third option is to rely on stewards. 03:13.760 --> 03:19.880 The concern with this is stewards are only offering at highly bit of what's required 03:19.880 --> 03:22.640 in the integration process. 03:22.640 --> 03:29.920 They're not there to help with due diligence and the vulnerability handling obligations 03:29.920 --> 03:33.160 are much smaller than yours as a manufacturer. 03:33.160 --> 03:37.640 And so the manufacturer remains responsible also for the transitive dependencies, even for 03:37.640 --> 03:39.520 a stewarded project. 03:39.520 --> 03:44.640 And so it's also important to note that most projects are not stewarded. 03:44.640 --> 03:51.360 If you look at the data, the difference between open source projects that are used in a 03:51.360 --> 03:57.080 large-scale product and the ones that are stewarded are orders of magnitude. 03:57.080 --> 04:01.480 I would have the numbers up here for you, but you'll have to look at them on that 04:01.520 --> 04:05.520 like that. 04:05.520 --> 04:11.480 And so in this year, there's this notion of security attestations that's defined in Article 04:11.480 --> 04:21.160 25, whose purpose is precisely to help manufacturers deal with the due diligence requirements. 04:21.160 --> 04:27.480 And they emerged as the need to essentially move the security left, the shift security 04:27.520 --> 04:31.960 left, back to the components, back to the open source projects, if you will, where it 04:31.960 --> 04:39.120 makes some more sense to do in where it scales better, and to an exchange provide mechanisms 04:39.120 --> 04:47.400 to support financially the projects that would step up to issue attestations. 04:47.400 --> 04:56.280 It can be thought of as an open source equivalent to the C mark. 04:56.320 --> 05:00.320 Of course, those remain voluntary. 05:00.320 --> 05:04.920 And what's also important to note is that it can be issued not only by maintainers of stewards, 05:04.920 --> 05:10.960 but essentially by the integrators and manufacturers themselves, or by third parties. 05:10.960 --> 05:15.720 So there's ongoing work in discussions in the ORC working group on this topic that's 05:15.720 --> 05:16.720 led by Eva Black. 05:16.720 --> 05:19.280 And so if you're interested, they're really encouraged you to have to have a look at what's 05:19.280 --> 05:21.320 happening there. 05:21.320 --> 05:25.680 So now what I really want to talk about is how do we make those attestations viable? 05:25.680 --> 05:27.840 When do they make sense? 05:27.840 --> 05:29.920 And what decisions do they make sense? 05:29.920 --> 05:34.480 They have to provide meaningful value to manufacturers. 05:34.480 --> 05:39.600 Essentially, they have to be a cheaper alternative to doing everything yourself as a 05:39.600 --> 05:46.600 manufacturer to rely on a vendor to provide you with essentially a packaged open source 05:46.600 --> 05:48.240 component. 05:48.240 --> 05:55.360 And they have to help manufacturers tame the transitive dependency help. 05:55.360 --> 06:02.360 So if you think of the relationship between a manufacturer, it's due to the obligations, 06:02.360 --> 06:07.520 you will see that there's essentially three layers which an attestation can help. 06:07.520 --> 06:16.480 The first layer is the first layer is essentially all of the public automatable signals. 06:16.480 --> 06:23.680 Everything that you can identify, if I'm looking at a GitHub project, or it's repository, 06:23.680 --> 06:28.680 and kind of understanding how the project is behaving, how long it's taking to fix issues, 06:28.680 --> 06:33.840 how active it is, and how essentially healthy it's community is. 06:33.840 --> 06:39.560 So this is probably, this is very low cost to create, and it's easy to automate. 06:39.560 --> 06:47.560 And so there's probably not a lot of value there that maintainers can capture, essentially 06:47.560 --> 06:49.800 to help sustain the projects. 06:50.800 --> 06:54.800 I'm expecting that you're going to see code hosting platforms, package managers, etc. 06:54.800 --> 06:57.800 Be focusing on that layer. 06:57.800 --> 07:02.800 The second layer is all of the private security information that a product manager is. 07:02.800 --> 07:09.800 So this is internal processes, CV, history, a time to fix, and all of that data that 07:09.800 --> 07:13.800 usually isn't public for security reasons. 07:13.800 --> 07:18.800 And this is actually no relevant to due diligence, and it really helps sort of better 07:18.800 --> 07:21.800 on the security poster of an open source project. 07:21.800 --> 07:27.800 It's probably not very easy for maintainers to monetize this, but it might be actually easier 07:27.800 --> 07:32.800 for stewards to offer this information, maybe to their membership. 07:32.800 --> 07:38.800 And the last layer is, you know, if you sort of think about what it takes on what is required 07:38.800 --> 07:43.800 of a manufacturer or the integrated component, it's looking at the long term picture. 07:43.800 --> 07:50.800 If a manufacturer has to fix vulnerabilities and its dependencies, then essentially having 07:50.800 --> 07:58.800 maintainers or some third party offering commitment or help to do this in the long term, 07:58.800 --> 08:03.800 that can be very helpful and it can be very valuable. 08:03.800 --> 08:08.800 And so of course, that is an area when the maintainers are the best position to offer this. 08:08.800 --> 08:16.800 And so I really believe that when it comes to manifestations, it is this layer that is probably the most valuable layer. 08:16.800 --> 08:24.800 Because it can really help with conservative dependencies, essentially maintainers can make sure that the dependencies 08:24.800 --> 08:29.800 of their own project are secure and well maintained. 08:29.800 --> 08:35.800 It addresses the total cost of a position of component and not just the due diligence. 08:35.800 --> 08:39.800 So essentially the total cost of the whole period of using it. 08:39.800 --> 08:43.800 And again, I think maintainers are uniquely positioned to help with this. 08:43.800 --> 08:45.800 So there are a few concerns. 08:45.800 --> 08:52.800 The first is whether this makes maintainer take on liability and contractual obligations. 08:52.800 --> 08:55.800 So that's a thing that's important to discuss. 08:55.800 --> 09:02.800 And, you know, the real question is, can manifestations sustain maintainers without implicating them? 09:02.800 --> 09:12.800 And so I think here that one of the possible models towards which we could move is a model where there are professionalized maintainers for certain projects. 09:12.800 --> 09:29.800 That operate maybe in something like maintainer pods that would focus on probably multiple projects, probably possibly tied to verticals or specific risk profiles. 09:30.800 --> 09:35.800 And this is a model that is closer to some of the commercial offerings in that space. 09:35.800 --> 09:38.800 So I think tied left or here it does. 09:38.800 --> 09:49.800 And that is less tightly coupled with a specific project than the steroid bottle is. 09:49.800 --> 09:53.800 And you can imagine lots of different sort of structures for this. 09:53.800 --> 09:57.800 If we're profits, it could be nonprofits, something a bit like OSTF. 09:57.800 --> 10:03.800 But more focused on maintenance, kind of maintainer cops, et cetera. 10:03.800 --> 10:07.800 And I think that's mostly it. 10:07.800 --> 10:11.800 Yes, lastly, I think this might not be a good fit for every kind of ecosystem. 10:11.800 --> 10:21.800 But I think it's a model that would work quite well for ecosystems that are full of like very small projects like, for example, the JavaScript ecosystem. 10:21.800 --> 10:25.800 And so in summary, yes. 10:25.800 --> 10:32.800 So the CRA requires new diligence and vulnerability handling for all components including transit of dependencies. 10:32.800 --> 10:35.800 Security attestations can help facilitate this. 10:35.800 --> 10:39.800 There are three layers to security attestations if you think about it. 10:39.800 --> 10:44.800 Public signals, private security information and sort of long term commitment to maintenance. 10:44.800 --> 10:50.800 In my opinion, the greatest value ad for maintainers is in providing the long term maintenance. 10:50.800 --> 10:56.800 So shielding maintainers away from personal liability requires professionalizing maintenance. 10:56.800 --> 11:01.800 And then lastly, if you really want to create sustainability, you have to create value. 11:01.800 --> 11:05.800 And to create value, you have to focus on manufacturing need. 11:05.800 --> 11:11.800 And so the key really is starting from what manufacturers need and essentially providing maintenance for that. 11:11.800 --> 11:15.800 Thank you very much, and you can see the slides. 11:15.800 --> 11:18.800 Thanks, Debbie.