WEBVTT 00:00.000 --> 00:12.960 I'd like to introduce a black who is working on security attestation ideas within the scope 00:12.960 --> 00:18.080 of the CRA and he's going to tell us about the work, thank you very much. 00:18.080 --> 00:19.080 Thank you. 00:19.080 --> 00:25.400 I've been a little less present at Boston, it's great to be back, so for those who don't 00:25.400 --> 00:32.120 know me in the last couple of years, I was doing open-source security policy at Microsoft 00:32.120 --> 00:38.960 and then kind of got pulled into more public policy, joined CISA for a while, moved over 00:38.960 --> 00:42.800 here last year and now working on this with both of the clips and the commission trying 00:42.800 --> 00:46.200 to figure out how to make this all work. 00:46.200 --> 00:50.360 So quick overview of the talk and for those who are coming in and back those tons of seats 00:51.360 --> 00:54.760 I'll give a quick background overview of the regulation, I think the previous talk, if 00:54.760 --> 00:59.360 you were here for it, also covered a bunch of that, but also touching other regulations. 00:59.360 --> 01:05.560 And I'll give you a little bit of info on the progress of our working group. 01:05.560 --> 01:10.960 It's been running for a few months, some of the challenges we've identified and some of them 01:10.960 --> 01:13.560 are pretty interesting, so we'd love your help. 01:13.560 --> 01:18.160 Definitely, the end of this hopefully more folks will come get involved in solving these problems 01:18.160 --> 01:24.160 together and then my talk will be only about 20 minutes, we will go maybe have time for 01:24.160 --> 01:28.360 one or two questions, then shift into a panel, a couple more folks will join me up here 01:28.360 --> 01:32.960 and we'll go through some questions for that and then take questions from all of you. 01:32.960 --> 01:42.160 So a couple of years ago at a phos and adjacent event, I got teased a little bit by some 01:42.160 --> 01:47.760 of European colleagues that you know, America innovates, but you're a regulates and that's not a bad thing. 01:47.760 --> 01:53.760 I think they were absolutely right, but maybe America's innovation didn't go far enough with this one. 01:53.760 --> 01:59.560 Back in 2023, I had the chance to consult with White House as they were drafting their 01:59.560 --> 02:05.760 national cybersecurity strategy and then found out months later they actually quoted me on it. 02:05.760 --> 02:10.760 This is like maybe some of the proudest sentences I've ever said. 02:10.760 --> 02:16.160 The burden has to be on the users of the software, not on the freedom of software developers. 02:16.160 --> 02:24.960 That was written into the strategy, but not really into law on the U.S., I'm so delighted it is encoded in the CRA, 02:24.960 --> 02:31.360 which introduces the concept of the open source steward as a new type of legal actor. 02:31.360 --> 02:37.560 Manufacturer, contributor, developer maintainer, foundation, and a steward, and it defines this a bit. 02:37.560 --> 02:42.760 This is sort of what we're all grappling with as the CRA implementation moves along. 02:42.760 --> 02:48.760 This is a new concept, legally, the lawyers don't know what to do with it quite yet. 02:48.760 --> 02:51.760 We're still waiting for some guidance from the definition of it, though it's much better 02:51.760 --> 03:00.160 interested now than two years ago, and this is a uniquely European framework at the moment. 03:00.160 --> 03:05.560 There are a couple definitions I want to emphasize for folks, manufacturer, has a specific 03:05.560 --> 03:09.760 definition that is distinct from an open source steward. 03:09.760 --> 03:15.760 There is no effect from this on personal expression, hobby projects, just writing code, making contributions. 03:15.760 --> 03:22.160 There's no obligation there, but there are some obligations for those two classes of actors. 03:22.160 --> 03:27.360 Manufacturers have specific obligations with respect to open source. 03:27.360 --> 03:33.160 They have to exercise due diligence into legal term if they're using open source in their products. 03:33.160 --> 03:37.160 I suspect most manufacturers aren't doing that today. 03:37.160 --> 03:43.160 If they find a vulnerability in the open source, they're using, they have to share the awareness 03:43.160 --> 03:46.160 of that, report the vulnerability to the open source projects. 03:46.160 --> 03:49.160 And if they fix it, they have to offer the fix back to the project. 03:49.160 --> 03:52.160 The project doesn't need to take it. 03:52.160 --> 03:58.160 There's no requirement on the project, but there is a requirement on manufacturers to do these things, 03:58.160 --> 04:05.160 including to include open source in their S-bomb, and in their assessments for product risk and product safety. 04:05.160 --> 04:09.160 And to handle the open source, the vulnerability is a product life cycle. 04:09.160 --> 04:13.160 So if they chose to use open source, and five years from now or two years from now, 04:13.160 --> 04:17.160 the project fixes the vulnerability of the manufacturer still has a responsibility 04:17.160 --> 04:20.160 because they chose to rely on it. 04:20.160 --> 04:24.160 On the steward side, it's a very lightweight. 04:24.160 --> 04:28.160 You have to publish documentation about your cybersecurity policy, 04:28.160 --> 04:32.160 your vulnerability handling policy, how to receive the report, about a vulnerability, 04:32.160 --> 04:36.160 or how to notify people who've used your project that they should do if it's something 04:36.160 --> 04:39.160 or pull down if it's back or something from you. 04:39.160 --> 04:47.160 And notably, steward's under this new framework must have of the willingness and a capacity 04:48.160 --> 04:56.160 to cooperate with market surveillance authorities and with cybersecurity coordination authorities like Anisa. 04:56.160 --> 05:04.160 And this has been pretty common among the larger projects, Linux kernel, Apache Python, open stack, et cetera. 05:04.160 --> 05:10.160 It's less common in the small projects, but it isn't required in every project. 05:10.160 --> 05:15.160 Again, none of this is required for hobby projects or your non-commercial open source 05:15.160 --> 05:17.160 that you're just writing with some friends. 05:17.160 --> 05:21.160 This only applies to organizations that want to function as a steward. 05:21.160 --> 05:26.160 This is relevant to the question of sustainability that I'm going to get to. 05:26.160 --> 05:35.160 This pattern seems to emerge from careful reading of the real tech to the CRA and the context around it. 05:35.160 --> 05:40.160 The goal of these regulations is that stewards in particular, 05:40.160 --> 05:44.160 but also maintainers or other participants in the open source ecosystem, 05:44.160 --> 05:48.160 can help the market benefit from open source efficiencies. 05:48.160 --> 05:49.160 We already do that. 05:49.160 --> 06:00.160 Open source has proven over the past 30 years to be perhaps the most economically efficient innovation engine we've ever seen as humans. 06:00.160 --> 06:03.160 And it is global, it is across borders. 06:03.160 --> 06:09.160 These are fantastic emergent properties of what we do in open source. 06:09.160 --> 06:14.160 But because there's so much lack of digital safety right now, 06:14.160 --> 06:18.160 devices failing or being vulnerable or being hacked, 06:18.160 --> 06:27.160 the regulation is coming down that says many factors of products with digital goods have a responsibility burden to keep their products safe. 06:27.160 --> 06:33.160 Well, if the manufacturers are going to be benefiting from the efficiencies of open source, 06:33.160 --> 06:35.160 they need to help support that. 06:35.160 --> 06:40.160 The regulations pretty clear on that, but doesn't specify the mechanism yet. 06:40.160 --> 06:44.160 It does set aside the power for the commission to specify it in the future. 06:44.160 --> 06:49.160 And throughout the CRA, there are these couple different delegated acts. 06:49.160 --> 06:52.160 Basically, the commission says we're not sure how to solve this yet, 06:52.160 --> 06:56.160 as a couple years ago, but we might solve it soon. 06:56.160 --> 06:58.160 We're probably going to solve it soon. 06:58.160 --> 07:02.160 And in this case, they've asked for all of us to sort of discuss it at input 07:02.160 --> 07:06.160 and help them figure out what's going to work for open source. 07:06.160 --> 07:10.160 If you've watched the keynote yesterday or some of the toxin jansson today, 07:10.160 --> 07:16.160 or the one right before this, you will have noticed a theme this year, all over Phasem, 07:16.160 --> 07:21.160 commission and other European government folks are here. 07:21.160 --> 07:22.160 They're asking for input. 07:22.160 --> 07:24.160 They've been building this engagement with open source, 07:24.160 --> 07:29.160 because open source communities are now part of civil society and global digital infrastructure. 07:30.160 --> 07:35.160 And this article is expressing that need to figure out 07:35.160 --> 07:40.160 how to get the two to work together in a sustainable way. 07:40.160 --> 07:44.160 So we started a project act in October if to explore this, 07:44.160 --> 07:46.160 and hit a model how it might work. 07:46.160 --> 07:48.160 We came up with a lot of questions. 07:48.160 --> 07:51.160 Right now, we have some theories about this, 07:51.160 --> 07:54.160 but the deeper we dig, the more questions we end up with. 07:54.160 --> 07:58.160 The Eclipse, ORC, open regulatory compliance, working group, 07:59.160 --> 08:03.160 the speaker before me was also talking a lot about what the ORC working group does. 08:03.160 --> 08:09.160 They also have come across them at the same questions and posted them and posed them to the commission 08:09.160 --> 08:12.160 and they're waiting for some responses. 08:12.160 --> 08:18.160 Some of them in particular, relevant here is the legal text says, 08:18.160 --> 08:22.160 manufacturer could be a natural person or a legal person, 08:22.160 --> 08:25.160 that's like a human or a company foundation, 08:25.160 --> 08:30.160 but the legal text says only a legal person can be a steward, 08:30.160 --> 08:32.160 which I don't know if it doesn't, 08:32.160 --> 08:36.160 like lots of individual people maintain open source projects 08:36.160 --> 08:38.160 that are super important. 08:38.160 --> 08:39.160 The legal text is a bit vague on that. 08:39.160 --> 08:42.160 There's a whole bunch of other things with a legal text. 08:42.160 --> 08:44.160 These are other questions. 08:44.160 --> 08:47.160 But as a group, we have this goal. 08:47.160 --> 08:53.160 Find a way to reduce the market burden of reassessing every open source component in every product. 08:53.160 --> 08:57.160 If every manufacturer had to do that, it would be terribly inefficient, 08:57.160 --> 09:01.160 and most manufacturers don't have the technical capacity or the budget 09:01.160 --> 09:04.160 to do a full audit of all the open source they use. 09:04.160 --> 09:11.160 If you've seen any of the black duck or other sort of analyses and audits of the supply chain, 09:11.160 --> 09:16.160 you may have seen stats like 95% of companies use open source, 09:16.160 --> 09:21.160 and 90% of their stats is open source or numbers like that. 09:21.160 --> 09:26.160 Your average small company that makes a product in Europe doesn't have this or America or anywhere, 09:26.160 --> 09:31.160 doesn't have the in-house knowledge to do an audit of the Linux kernel 09:31.160 --> 09:33.160 and everything else they're using. 09:33.160 --> 09:36.160 So again, there's an efficiency here. 09:36.160 --> 09:43.160 If somehow that open source code can be deemed under the CRA as safe enough, 09:43.160 --> 09:46.160 but because it isn't manufactured, it doesn't get a CE mark. 09:46.160 --> 09:47.160 There's not a company there. 09:47.160 --> 09:49.160 There's some other mechanism needed. 09:50.160 --> 09:54.160 It can also support the shared responsibility of doing the maintenance, 09:54.160 --> 10:00.160 and can this account for projects of all sizes from the really big ones to the single maintainers, 10:00.160 --> 10:05.160 or just the loose collection of people who maintain a project that's 20 years old 10:05.160 --> 10:10.160 and works fine still, and the world still runs on it like a DNS server. 10:10.160 --> 10:13.160 We've made some progress in the past couple of months. 10:13.160 --> 10:18.160 We've developed a tiered model to try and account for these, 10:18.160 --> 10:22.160 you know, the very small and the very large, the microscopic and the cosmologic of open source. 10:22.160 --> 10:28.160 We've clarified a couple of questions around financial mechanisms and transitive dependencies, 10:28.160 --> 10:35.160 because of course projects like Debian, build out of 10,000 other components. 10:35.160 --> 10:40.160 And the tax to make clear that a third party attestation is possible is in scope, 10:40.160 --> 10:48.160 but what does it mean for open source if an unaffiliated entity makes one of these attestations 10:48.160 --> 10:52.160 about a project that they aren't equipped to actually handle the vulnerability, 10:52.160 --> 10:54.160 but it's not participating in writing it. 10:54.160 --> 10:57.160 What does that even mean and is it valuable? 10:57.160 --> 11:01.160 If it's the nature of a delegated act, it doesn't have to specify that yet, 11:01.160 --> 11:03.160 but it might in the future. 11:03.160 --> 11:05.160 So we've been exploring all that. 11:05.160 --> 11:09.160 I'll talk from a moment about the tiers we've come up with. 11:09.160 --> 11:15.160 The light tier and the heavy tier based on a reasonably foreseeable capability of projects 11:15.160 --> 11:20.160 that don't have a ton of commercial support or that do have significant commercial support. 11:20.160 --> 11:24.160 The light tier might be applicable for a component or a library. 11:24.160 --> 11:28.160 It doesn't even have a clear product like use case yet. 11:28.160 --> 11:31.160 Maybe it's just compression utility. 11:31.160 --> 11:36.160 On the heavy tier side, it might be functionally equivalent to a commercial product. 11:36.160 --> 11:41.160 It might be only modified at tiny bit when being incorporated into an actual commercial product. 11:41.160 --> 11:50.160 This might be a browser or a word processor or cloud orchestration engine. 11:50.160 --> 11:55.160 And if you go into the deep nerdy of the CRA and conformity assessments, 11:55.160 --> 12:00.160 there are these things called module A or module B and C or module H assessments. 12:01.160 --> 12:08.160 The heavy attestation seems more appropriate for things that would require a module B and C 12:08.160 --> 12:13.160 or a module H assessment if they were products because the products will need those. 12:13.160 --> 12:18.160 So it's sort of about aligning that. 12:18.160 --> 12:25.160 The light attestation, I'll show you a template we've got in the moment, the draft right now. 12:25.160 --> 12:28.160 It really doesn't require a lot of time investment. 12:28.160 --> 12:33.160 I've been a maintainer for about half of my career of some big projects, a couple small projects. 12:33.160 --> 12:37.160 And I think I could fill out this sort of a lightweight form in the matter of minutes. 12:37.160 --> 12:42.160 For any product I've ever worked on, most of it's automatable. 12:42.160 --> 12:47.160 Based on the BSI's guidance, they published a feedback in November. 12:47.160 --> 12:50.160 And it's pretty similar to the salsa already. 12:50.160 --> 12:55.160 It should be well understood, we just sort of drafted that based on the European standard. 12:55.160 --> 12:59.160 On the heavy side, this gets a bit tricky and more into the unknowns right now, 12:59.160 --> 13:04.160 because most of the CRA vertical standards aren't publicly available, 13:04.160 --> 13:09.160 even if they are available through a national standards body for review. 13:09.160 --> 13:11.160 They're not widely available yet. 13:11.160 --> 13:17.160 So to say, we think the heavy attestation might need to be similar to those. 13:17.160 --> 13:24.160 It doesn't help open source communities because those are locked up in a national standardization process, 13:24.160 --> 13:28.160 since I'd said an ISO, even when they're finalized, 13:28.160 --> 13:31.160 they might still need to spend money to get access. 13:31.160 --> 13:35.160 And they might still be IPR restrictions on them that are incompatible to open source. 13:35.160 --> 13:38.160 I don't know yet. We'll see how all that shakes out. 13:38.160 --> 13:42.160 That's a much bigger topic I'm not going to go into. 13:42.160 --> 13:44.160 Here's the template. 13:44.160 --> 13:47.160 Again, it's really simple. This is just a draft. 13:47.160 --> 13:51.160 We think would work, would love feedback on this. 13:51.160 --> 13:54.160 It's basically, do you have a contributor guideline? 13:54.160 --> 13:58.160 Do you have licenses? Do you check them? Do you have functional tests? 13:58.160 --> 14:02.160 Is there a vulnerability reporting point to contact? 14:02.160 --> 14:06.160 And are you going to be there if someone actually does report a vulnerability? 14:06.160 --> 14:08.160 Do you have an end of life? 14:08.160 --> 14:11.160 Are you promising that if you ever stop maintaining the project? 14:11.160 --> 14:15.160 You're just going to make a post that says, dead now. 14:15.160 --> 14:19.160 It's a basic hygiene of being an open source project. 14:19.160 --> 14:21.160 Very low bar. 14:21.160 --> 14:26.160 Unfortunately, it's a higher bar than a lot of manufacturers are incorporating today. 14:26.160 --> 14:28.160 And that's the key. 14:28.160 --> 14:32.160 Having this low bar harmonized sets a standard for industry. 14:32.160 --> 14:34.160 It's a rely on it. 14:34.160 --> 14:37.160 And there's a lot of similar things that the OpenSF has been doing, 14:37.160 --> 14:40.160 but other goods have been doing to try and take the best practices 14:40.160 --> 14:44.160 that have emerged from 30 years of open source in Apache and Debbie and 14:44.160 --> 14:46.160 an open stack and so on. 14:46.160 --> 14:49.160 And just harmonize as a cross. 14:49.160 --> 14:52.160 As much open source as has commercial utility, 14:52.160 --> 14:55.160 as developers are intending it for commercial use. 14:55.160 --> 15:00.160 So that the industry that relies on all this can have a consistent thing 15:00.160 --> 15:04.160 to rely on and thus reduce errors, reduce risk. 15:05.160 --> 15:09.160 But, like I said, a lot of questions really remain unanswered. 15:09.160 --> 15:14.160 The cost structure or the cost and the structures for stewards as legal entities 15:14.160 --> 15:16.160 today would vary by country. 15:16.160 --> 15:18.160 If they are established in Europe, 15:18.160 --> 15:20.160 not the laws are different in each country. 15:20.160 --> 15:25.160 A stiff tone in Germany and a stiff teen in Italy, 15:25.160 --> 15:27.160 and an AISBL here in Belgium, 15:27.160 --> 15:30.160 have very different nuances. 15:31.160 --> 15:35.160 And maybe your project has developers from multiple countries 15:35.160 --> 15:39.160 and maybe the type of entity you would use 15:39.160 --> 15:43.160 if you were to create a new legal entity to become a steward, 15:43.160 --> 15:47.160 has residents requirements in a country or language requirements in a country 15:47.160 --> 15:50.160 that are incompatible with some members of your community. 15:50.160 --> 15:51.160 That's not ideal. 15:51.160 --> 15:55.160 So these are the kinds of questions that keep coming up as I dig into this. 15:55.160 --> 15:59.160 The other one is that tax incentives seem kind of misaligned. 15:59.160 --> 16:05.160 A steward's activities, maintenance, participation in vulnerability handling, 16:05.160 --> 16:10.160 bug fixing are usually exempted from tax incentives. 16:10.160 --> 16:16.160 Companies and the countries provide research funding over research-based tax incentives. 16:16.160 --> 16:21.160 But those are often exclusionary to maintenance and fixing the bugs. 16:21.160 --> 16:25.160 So this is another area where contacting your officials, 16:25.160 --> 16:28.160 your members of parliament or your local governments, 16:28.160 --> 16:31.160 to try and figure this out might be helpful. 16:31.160 --> 16:35.160 As open source, as an open source maintainer myself for a long time, 16:35.160 --> 16:38.160 I've always struggled in the companies with this, 16:38.160 --> 16:41.160 watching the dev teams that don't do open source, 16:41.160 --> 16:45.160 they're staff grow because they get financial incentives. 16:45.160 --> 16:49.160 So do that while the teams that do open source maintenance 16:49.160 --> 16:53.160 get defunded because there aren't tax incentives for them. 16:53.160 --> 16:56.160 There isn't just a problem unique to the CRN stewards, 16:56.160 --> 16:59.160 but it's been around for a while. 16:59.160 --> 17:02.160 Where we are as a product right now, 17:02.160 --> 17:04.160 we have bi-weekly meetings every Tuesday, 17:04.160 --> 17:07.160 we have a room on matrix, mailing list, 17:07.160 --> 17:10.160 GitHub, please, you know, 17:10.160 --> 17:14.160 contribute to it, open review or comment on reviews. 17:14.160 --> 17:18.160 If you are working in somebody's spaces and have ideas of how to fix this, 17:18.160 --> 17:20.160 please do come to us. 17:20.160 --> 17:24.160 More ideas and ideas from corners of the open source communities 17:24.160 --> 17:28.160 that we don't yet have would be super helpful. 17:28.160 --> 17:31.160 We just launched a small survey. 17:31.160 --> 17:34.160 So whether you are a maintainer, a developer, 17:34.160 --> 17:38.160 a manufacturer, a manager at a tech company, 17:38.160 --> 17:41.160 more input on this survey would be really helpful for us to understand 17:41.160 --> 17:45.160 how ready people are, how interested people are, 17:45.160 --> 17:48.160 how do people think any of this might work. 17:48.160 --> 17:53.160 I'll leave it up as decent cameras or leave it a little longer. 17:53.160 --> 17:58.160 And lastly, I think I've heard four other talks this week say, 17:58.160 --> 18:02.160 hey, the commission right now has an open call for feedback 18:02.160 --> 18:06.160 for input on open source, 18:06.160 --> 18:08.160 an European open digital ecosystem, 18:08.160 --> 18:12.160 and considering the CRA is the first regulations 18:12.160 --> 18:17.160 specifically to train on open source and changing some of the structures around open source 18:17.160 --> 18:22.160 to great opportunity to go have your say as well for how you think these kinds of things 18:22.160 --> 18:26.160 should be implemented over the next couple of years. 18:26.160 --> 18:28.160 What sort of things should be funded, 18:28.160 --> 18:32.160 should the commission do certain studies or investigations 18:32.160 --> 18:35.160 or just what's your opinion on all on how great open source is? 18:35.160 --> 18:38.160 This is a great opportunity to go have your say. 18:38.160 --> 18:42.160 And with that, I want to say thank you and invite my panelists down. 18:42.160 --> 18:49.160 Thank you.