Datenspuren 2025 - CRA: Cybersicherheit in der Gesellschaft

[Music] K. [Music] Welcome. I am Michael, I work full-time at the BSI, I have been working on the Cyber ​​Resilience Act for almost 3 years now and have a project with Alex as part of this. I'm Alex, I'm from the Free Software Foundation Europe and I also work full-time on the CRA as well as other topics related to free software. Exactly . And through the dialogue for cybersecurity, we have a project about the role that the CAA plays, and may play, for open source. What is the dialogue for cybersecurity? This is a project by the BSI itself, to engage with various stakeholders, mainly civil society, and to discuss several topics related to cybersecurity . There is also a so-called think tank once a year, where workstreams, i.e. projects, are selected and then supported for a year . Alex and I met at Frostcon just over a year ago. Eventually someone came and said, "We still have a barrel of beer here." What should we do with it? Mhm. We weren't the first, but our hands were up relatively quickly with " let's tap this," then it had to be drunk because beer goes flat quickly. And while we drank a beer or two, we thought about what could be done with the CA and what the CA might have to do with Open Source, and we thought, let's submit a Wirkstream project for the dialogue on cybersecurity, and this was accepted last November at the think tank for the Wirkstream, which has now been running for almost a year. We had several meetings, always on the first Tuesday of the month. There were working meetings because we also published questionnaires that were intended to clarify certain questions regarding Open Source and CA. We have started a lecture series with three participants who have given presentations so far, and we already gave a presentation at this year's Frostkon in August, and this is now the second presentation where we want to present the final results or excerpts from the final results of our questionnaires . What is the Cyber ​​Resilience Act? The Commission has put forward a proposal for regulation on 22 issues concerning products entering the European market that are not secure enough in terms of cybersecurity. Something had to be done, and then a proposal was submitted, which was then negotiated for a relatively long time. And the principle is the same as we already have for safety, so someone who touches a device or a product does n't die immediately after an electric shock. This is safety under the CE mark. Is cybersecurity now being included under the CE marking? This means that products with digital elements, as they are called, must now meet cybersecurity requirements . There are a few exceptions such as motor vehicles, aerospace, and medical devices. It 's really almost everything. IoT devices, televisions, operating systems, mobile phones, including operating systems. So, the range is relatively large and the price is good. So, there are two main goals in the CA. Firstly, that products become more secure in terms of cybersecurity, and not only when they are launched and sold, but that cybersecurity is already considered during the development process. There you'll find fancy terms like Security by Design, Security by Default. That means you have to think about how to keep your product secure from the very beginning, that relatively little data is recorded, that I am a little bit and it starts with access restrictions . Sometimes, for certain products, you might also consider two-factor or multi-factor authentication. The second issue is that users of these products should be enabled to select products that have a certain level of cybersecurity. This means that manufacturers must also adapt their documentation so that users have the opportunity to assess the cybersecurity of these products . What do manufacturers need to do to achieve this? The regulations include so-called general product requirements that manufacturers must implement before they bring their product to market. And these characteristics must be adhered to once they are on the market. You must be able to address weaknesses . In other words, if a vulnerability arises somewhere, the manufacturer must have a process in place for how to mitigate this vulnerability and how to react to it. Manufacturers must provide technical and user documentation. You must report vulnerabilities. This means that starting next September, actively exploitable vulnerabilities must be reported. There is a platform at EU level where they can be submitted or entered . And each member state has a so-called CAS, where vulnerabilities are also reported. The Cyber ​​Resilience Act does not stand alone. The EU introduced the so-called New Legislative Framework in 2008 . In principle, you can think of it as a huge law for product regulation. where there are several regulations that are integrated into this huge law . That's where the Cyber ​​Resilience Actu comes in for the products. This also includes the AI ​​directive, which has now, um, come into force. This also includes the Machinery Directive, which already incorporates these safety aspects for products. This means that the act of cyber resilience itself brings new aspects to cybersecurity. What he's doing, seen in context, is nothing new. The New Legislative Framework itself is a market access requirement, and the idea was that products could be brought onto the European market without all products having to be tested beforehand. In other words, there are conformity assessment procedures, either self-assessment, testing laboratories, or certifications. It depends on the product categories. The products come onto the market, and then there is a subsequent market surveillance system that can check the products. If the requirements are not met, then they are taken off the market again via market surveillance, and then the manufacturers can also be subject to substantial penalties. This is a point that is somewhat interesting for open source . Open Source Software is excluded from the Cyber ​​Resilience Act. They do not have to meet the requirements of the Cyber ​​Resilience Act. The point is, um, Open Source only has to meet these requirements if there's a commercial purpose. That means when someone, as a manufacturer, sells the open source project or open source product and makes money from it . And that's another point that comes up again via the New Legis Lady Framework. There's the so-called Blue Guide, which contains specific explanations on the whole topic. And it is also stated there that bringing a product to market means that someone, even if they provide it for free, has a commercial intention behind it. He wants to make money with it, and that eliminates a huge number of opensur projects that exist so that someone can continue to use it for themselves, in the way they want to use it. And the point about provision really refers to each individual product, and it 's really the product itself, not the product series. When a product, e.g. a washing machine, comes fully into force under the Cyber ​​Resilience Act, which was implemented in December 2027. The washing machine from the series on December 10th. If sold, it does not necessarily have to meet all requirements. On December 12th. If it is sold, it must meet all the requirements of the Cyber Resilience Act. This means it always involves individual products that must meet all the requirements. Exactly . So, we've now learned that there is product regulation and we've learned that there is market entry regulation. Um, we've also just learned that, um, free software projects aren't necessarily products . Um, well, there are free software products, and that's why the CA decided, beyond the exception for free software projects , that the area of ​​open source software, free software, needs to be specifically regulated . So, the fact that special regulations and specific articles need to be introduced here means that the legislator decided to introduce several roles. So, we've already heard that there are manufacturers, that much is clear. So, I'm building an open source product, um, then I'm a manufacturer, I have a product and am therefore regulated under the CAA. But the question is, what if I have a project that ultimately ends up in a product in some way? And for this, uh, for this case, the legislator has introduced the Stuart role, i.e., the Rei software administrator . These are people who have a project and whose project ultimately results in a product, but they themselves do not have a product. And then, of course, there's the aforementioned exception. So, I have something that has absolutely no commercial background. Um, I'm not a product, I just create some code, make it available, and then I'm completely removed from it. So, we basically have three roles, right? I'm a freelance software project, I'm exempt, I'm Stuart, so I help someone, uh, my project to get into a product, or at the end of the day I'm a manufacturer and I have a product. And now, of course, the question is how these, um, people interact and what kind of guidelines they have. So, I am now, um, um, a manufacturer, and as a manufacturer, I am also responsible for the free software in my product. That means I take code from somewhere, um, and then put it into my refrigerator , so I am responsible for this code, regardless of whether I wrote it myself or whether I gathered it from somewhere and put it in there. This also means I must be able to, um, treat and address these weaknesses. And uh, if I am, um, yes, collaborating with the project, i.e., a student, then in that case it must also be possible to report these vulnerabilities accordingly and, um, provide a patch . And here it is interesting that the legislator also stated that the patch must always be shared with everything. So regardless of where the patch comes from, whether it comes from the manufacturer or from the launch, it basically has to be shared with everyone. So, in the spirit of free software , that's still relatively interesting, but we can already see here that all the responsibilities lie with the manufacturer. Yes, so neither in a project nor in a Stuart, these are the obligations that the manufacturer has. And the question then becomes, well, um, how does he actually end up getting the project at the end of the day? And, um, we see that currently, the first companies are already trying to approach potential manufacturers under the CAA with such projects. It's quite hard to read now, um, um, because it's a bit grey. I do n't know how it is with the light. Anyway, this is from the Körl project. Um, the guy got an email from, I think it was an Indian company, who wrote, "Yes, we now have to become CA compliant." Um, give us this and this and this and this and this. And that's obviously not how manufacturers should approach projects , how a potential Duarts should approach them, in order to get this information in order to then fulfill their obligations accordingly, as we have seen . There simply have to be other ways. Um, and these have already been provided for by the legislature . So, we have the option of using guidance, which is like guidelines, if you will, to approach the market and say, if you are a manufacturer, you have to do this and that, if you are a contractor, you have to do this and that, and it also explains where the thresholds are. Um, the question is of course also, for example, with a free software project, are there often donations in the project, or are there sponsorships or similar? Even that doesn't make a project a product. Yes, so you can, so to speak, make money with your project up to a certain limit, without actually becoming a product. But that needs to be precisely defined. Yes, so it can now depend on something like a charity status, i.e., a non-profit status. However, it is also perfectly possible to be a type of company if, at the end of the day, you don't have a product. And to define that, that's what happens in such a legislative document, so what the legislator does is say that there are these three roles, right? Manufacturer Stuart, you're out. And what happened in the guidance needs to be spelled out again, yes, when exactly are you Stuart? So, how much money can be in circulation and, um, what exactly does that look like? What legal, er, framework conditions exist ? Furthermore, there is another relatively large, um, um component, which is standardization. Well, in the standardization process, it is precisely defined how these processes are to take place. Um, there are horizontal and vertical standards, which is a bit too far-fetched now, but basically the whole thing is also underpinned by standards, and then there's also something like att, where certain parts are simply certified and then can be incorporated into such products. In addition, there are also Implementing and Delegated Acts. Um, it's also stated in the law itself. A Delegated Act is something the Commission has to do. So, it says there is still a need for regulation, and this need for regulation will then be addressed by the Commission in a Delegated Corner . Um, that will happen, that's the case with the S-Bom, for example, so the law says, no, there is an S-Bom, but what this S-Bom should look like, what needs to be done inside it, and so on and so forth. This will be clarified in a Delegated Act. All of this is still happening now. Um, by the way. So, implementation or something like that. Yes, that's right. Exactly . And an Implementing Act is basically where the Commission leaves itself the option to tighten things up again if it realizes that the market is not finding any real answers to the relevant questions. So, if, for example, they can't find a good food bomb, then the commission can come along and say, well, we do n't like it, the food bomb now looks like this and that. And the question we asked ourselves during our little beer party is how we can meaningfully influence all these processes in such a way that we can protect the free and open-source software ecosystem, that we can ensure that you can continue with your projects without being bothered with any funny emails . Or, if you are immersed in products, so to speak, that it happens in such a way that you do n't have to fear any consequences or anything like that. Um, and then we thought, um, that we've had many contacts with various projects and manufacturers, and we've always had a sense of where the problems might lie , like the thresholds, for example? At what point does one become a manufacturer, or how much money can one have in their project without being a manufacturer? We thought it best to create a questionnaire and try to shake people up a bit and ask them how they view the Cyber ​​Resilience Act. Then, from the answers we received, we would try to extract how we can then approach the Commission, or rather the implementing market regulators, and how best to address the entire aspect of the Cyber ​​Resilience Act's implementation that is still unclear and open, so that we can adequately protect free software. What we did was, um, we created six questionnaires, three in German and three in English. So, we also tried to address the topic beyond the German-speaking context. Um, we contacted the Stuarts, projects, and manufacturers in the respective two question variants of the languages, and we also discussed this beforehand with other players active in the CAA, got feedback, gave it to free software projects, spoke with the Open Business Alliance, the Linux Foundation, the Clips Foundation, and others, and then made this questionnaire available to the public for two months . About a month ago at Frostcon, we presented the first results from this questionnaire and also called on people to participate . Overall, that worked out quite well, and we reached the point at the end of August where the two months were up, the questionnaire was finished, and we received 345 responses, of which 83 were complete. Um, it was never important to us that the questionnaires were filled out completely. For us, it was never important that thousands of people fill out these questionnaires, but above all, that these questionnaires be filled out by people who have already dealt with the Cyber ​​Resilience Act to some extent, who have already acquired some knowledge, who may have already considered whether they want to become a Stuart, for example, and may have already taken the first, um, well, um exam . And, uh, I think that worked out quite well. um, so, that um, that uh, that we at the end of the day, um, um, yes, got answers that we can work with. So for us it was important, um, yes, that we, um, of course, contact those affected and that, based on the answers we received, um, so to speak, we could further examine the problem areas that we had sensed to some extent, I would say, uh, in the market to find out if we are on the right um track here. That went pretty well so far, and now we want to take a look at what we notice. So what is quite clear is that this role definition will definitely be made even clearer. Only about half of the people know who they actually are under the Cyber ​​Resilience Act at the end of the day. Um, and another question is about these thresholds, right? How much in donations, how much income can I have to still be a Stuart, or perhaps not even fall under the CAA? Um, there is always a fear that a pressure situation arises, that is, that manufacturers, um, as we just saw in this email , approach the projects that are under pressure, saying: "Hey, this is CA Complient, you have to do this now." Uh, so that they can get out of there a little bit. A nice quote we found is certainly: "I like to do Software Engineering, not management." And I think that's what drives us a little bit, right? So, we want to make sure that people can continue tinkering with their code and are n't confronted with forms or legal problems. Overall, the topic keeps coming up that all of this will be very expensive, and the question is, where will the money come from ? um and um, that might also lead to a loss of quality in the projects. Um, and other questions that we have n't dealt with so much yet, but which of course are still ahead of us, things like the S-Bom question, supply chain attacks, licensing problems and the like, but uh, so to speak, the points that are before the parentheses, those are always the ones that we have dealt with in particular. Now, let me give you a more detailed evaluation of the project questionnaire. What we have written down here are parts of it. These are also answers that have become somewhat more frequent , where certain trends are already visible. As I said, it wasn't about quantity, so it wasn't a quantitative survey and there were also some answer fields where people could simply write whatever they wanted in free text. Um, that means it's only partially representative, but it still reflects certain things. And one point that has always been relevant, especially for projects, is: what does the CAA mean for me? So, in many places it is still unclear how projects are affected. And this goes so far as to say, um, there are no real requirements that projects have to meet, but there is also the possibility that projects already meet the requirements on their own, and there the question is, what do they have to do? So what requirements must the obscurity projects meet if they want to do this voluntarily ? A big question, as I said, is about donation background; what does " commercial background" mean? And this is also frequently reflected. Manufacturers are subject to reporting requirements. If you find a vulnerability in the open source component that you are integrating into your system, you must report this information back to the project. If you were to develop a fix for the vulnerability , you would have to make it available. This doesn't mean the project has to integrate it, but they do need access to this patch . And in many discussions there is a fear that manufacturers will never do that anyway. They have to do it, it's in the law . In other words, what can you do as a project if you find out that someone isn't passing it on? So there is also a need for guidance on who to contact and what the processes look like. And this is another point that always comes up: when we do something, we want to be appreciated for it, including by the manufacturers. And that also enters the discussion to some extent. That's also partly where Alex and I want to go with the project . Open projects want to be compensated in some way for what they do when it is integrated into manufacturers' products, which then also partially reflects this desired return on investment . We had a number of yes/no questions in our question bank, and this is now a part of it where there are trends where we say, this is interesting for us, and this is where it comes to the point, this is a discussion that has been initiated to a considerable extent at the Eclipse Foundation, should there be a point for open source projects where they can declare for themselves that they do not fall under the CHA and can tell manufacturers that they do not have to meet any requirements. And quite a few projects said, yes, it would be nice for us if we had some kind of opportunity like that. A second point, because we also considered this role with the Stewarts, was for projects: can you imagine someone taking on this tax role for you ? The vast majority said no. Well, we might not have quite expected that. And the second question: could you imagine taking on this role yourself ? And that's kind of a fifty-fifty thing. That's also interesting, and something you'd like to share with others . um, and also where we want to approach projects again, why they don't want to outsource the tax role and secondly what they need if they want to take it on themselves or where the decision is made as to why they don't want to take it on themselves. Exactly . Then we would look to the Stuarts . Perhaps one more quick question about time. I thought we had until 45, because you... Ah, okay, all right. Yes, that works. Understood. Good. Um, exactly. Then, as I said, we discussed it again with the students . And there, too, the question is about money, right? Um, where does the money come from, how, to whom, and why? And above all, how is the relationship with the manufacturer, which we have already heard a lot about from the Stuarts, that they also like to have tools. So they want a lot of automation in the process; they'd like to just click a few times and get through it . Um, and what they also need is, in clear and understandable language, um, what they now have to fulfill and um, um, what exactly the specific requirements are. And I also notice that a bit, you know, when you look at the discussion and the debate, that it obviously still needs to be reformulated in order to give people some guidance on what they have to do. And this ca n't be 200 pages of legal text; rather, it needs to be relatively simple and clear for the projects and for the Stuarts to understand what they have to do when they take on this role. And um, what we 've also seen, and this is quite interesting, is that basically, if the projects want to be Stuart for their own projects, if they realize that their project will end up in some commercial product at the end of the day and they would have this Stuart role, then they would rather take on that role themselves than outsource it. Well, that's also a very interesting finding. So, overall, the projects have shown an interest in wanting to be supported . Um, here are two more graphics. Um, that 's also quite interesting, uh, a question we asked, which projects or the Stuarts believe they can step back from their role as Stuart. Um, and so here too, the grey bar, the ignorance, is what we noticed here. So here too, it is obviously necessary to bring a certain clarity and to further refine and formulate how the processes can be accordingly. And um, the question then is, do you think that manufacturers should provide crash support ? um um relatively um clear year, so that here uh the manufacturers also have a certain obligation and these are all things that we then try to address accordingly in the guidance with uh . Then we have the manufacturers, I'll give you that information again. Exactly . The responses from manufacturers indicated that they fear open projects will no longer be continued in the same way as they are currently being continued or managed . Firstly, there's the point, and these are things we're already seeing, even though there's no reason for initial projects to say, "We're not doing anything anymore, cyber resilience is here, and we don't want to deal with it anymore." Even though discussions had been held with them about their lack of obligations, some were still a bit resistant. Um, that also means there are fears that open source projects will no longer be continued because of pressure coming from various places , because the projects themselves no longer want to continue . And somewhere the vulnerabilities that are found have to be fixed, and there is also the fear that the open source projects themselves might not be able to do this in the way that the manufacturers need, and um, that currently the support between manufacturers and projects is not yet seen as such that one can rely on an existing ecosystem . The moment that's not the case, and we also have a graphical representation, the question is: what does the manufacturer do? The manufacturer is always responsible. This means he can take care of it himself, he can follow projects and then simply develop them further on his own. Or what he can also do is find proprietary alternatives, because if these are sold as products on the European market , he can shift some of his responsibilities to these manufacturers. Exactly . And just like with the launchers, manufacturers also want tools that make it relatively easy to meet the requirements and then pass that information on . Here's the question regarding the point about the birds. Um, the majority of the manufacturers who responded to the questions said that they themselves did not have a plan to follow. However, there are manufacturers who are already starting to forge projects, or rather, who are following planned projects. What is somewhat interesting is that almost none of the manufacturers we surveyed plan to use proprietary software to replace the open source products or components in their products . What we see here is that manufacturers are generally willing to continue using open products in their products. Another question was whether it would be helpful to have some kind of certification that the open source components you are using meet the CA requirements in some way? According to the majority, this certification would help manufacturers, and as can be seen, there is a general willingness to pay for this certification . And that's another point that's very interesting for us. This means that manufacturers are willing or prepared to continue using open source products. In principle, there is a willingness to pay for this if you have proof that the products you use meet the requirements, and Stewarts above state that they want to be supported by the manufacturers . And that's what we want to achieve to some extent now: to bring the two together and enable one to meet this requirement or to demonstrate that the requirements are met, and the other then pays for it and supports the open source projects. Exactly . What happens next? Basically, stay calm for now. There are many people out there saying that open source is dying. Then there will be others who say that manufacturers can no longer work and that CA will destroy the entire ecosystem. After a beer or two, things usually do n't look quite so bad anymore. What happens next for us? We will compile a report based on the results from the questionnaires. The plan is to take the report to the commission and present the results there. Then also to look at the fact that the Commission has the mandate this year to publish guides, i.e., assistance for Opensource projects or on the topic of Opensource in general . And we think that the questionnaires also brought up a few things that are not yet addressed in the current drafts of Open Source Guidance . That means we then try to reflect back that certain explanations become even more specific, or that explanations are generally found for certain topics . We will continue to meet with projects, Stewarts and manufacturers, and with the speeches, and look at how to bring these three roles together more effectively . And anyone who wants to can feel free to approach us and talk to us. We are in contact with market surveillance authorities and the Commission because ultimately, or market surveillance, it is the market surveillance authority that enforces everything on the manufacturer's side and checks whether the manufacturers release their products as they have to and whether they support the open source components they incorporate, or whether they meet the requirements they have to meet. As I said, input, we are always open to input and whatever it takes, support, tools and money, to further advance the whole thing as an ecosystem. Exactly . Thanks. And now we can ask questions . [Music] Thank you for the overview. Um, we 've just heard a lot about, uh, well, something that's basically just paperwork . Do you expect this law to actually increase the cybersecurity of any products? Yes . Yes. Yes, well, I think you can actually look at it in the same way as at a data protection reform. Yes, so it's always about somehow getting the large amount of rubbish off the market, and I believe that will be achieved with this law . I also don't believe that market regulators are ultimately after any specific projects or Stuarts, but rather primarily after manufacturers who are known to not care much about IT security, but instead throw any old rubbish onto the market, and this will certainly be a way to address them. Are there any further questions? You mentioned earlier that medical devices and others are exempt. Is that correct? Yes, that's because they already have their own regulations that go beyond the Cyber ​​Resilient Act. So, in principle, the idea is that if a product category already has a regulation that is at least as strict as the Cyber Resilient Act, then they are exempt from it, and medical devices, for example, are sometimes even further exempt . [Music] I see no further questions. But. Otherwise, we're still hanging around here a bit with those beers, and you can always approach us about it. But since Lars Ja, Lars BCH transparency notice, I am also from the BSI, just like Michael. Um, a question about the foil, er, manufacturer survey. Um, there is a certain percentage of manufacturers who say, okay, we are willing to fork this and/or are willing to pay for it. Do you have any information about what their usual suspects are in terms of tools and open-source components, where one could perhaps determine, okay, that's where this willingness exists, or was it just a hypothetical answer from them? Well, I think if you look at the market, there are many manufacturers who are already doing this, who are, so to speak, planning projects, and they are all talking to each other and considering how to act in general. And um, well, I don't know any of the players who are currently running around in Brussels and who would parade this around like a monstrance, saying, "We're starting now, how will we fork?" So nobody really wants that , but it's seen as an option . So it is indeed a viable way to do it, and it is being addressed accordingly. But if you also consider that they basically want to work with the Stuarts, I think that's the first path manufacturers try to take. So, the goal is to actually engage with the projects, to build a relationship with them, and if that should fail for whatever reason—if the project simply says, "I find you as a company really unpleasant and don't want to be your Stuart," that's possible—then there still needs to be some way open for them. Therefore, it's important to engage with them, but it's not like this is being prepared on a broad scale, I would say. Where we see this, it's more the manufacturer saying, "I'll forge this," because then I have the responsibility anyway, so I don't have to deal with the project anymore. There aren't many specific projects that are being forged, although there weren't many that said so. But we see that there are projects or manufacturers who say, "We'll follow projects." I'd like to briefly address the issue of forks again: if there are already companies and businesses that say they're doing this, it's simply for their own compliance. For example, civilian airspace surveillance, defense, and similar organizations usually do this with any tools they have and then directly implement updates, simply to demonstrate that they are compliant with their respective infrastructure. Exactly . So the principle is that as the manufacturer, I am responsible for the entire product, regardless of what's inside it . If I include proprietary components, I can delegate some of the responsibility, and for open source projects, if I proceed in this way, I simply say that it is my component per se and I am responsible for it, so I no longer have to deal with the project . That's basically the same thing. Um, I have another question: could n't the open source people simply state in the license that they want the manufacturers to be able to do that themselves , and that they can decide that for themselves ? [Music] So, I would now try to avoid letting CAA free software licenses fall through the cracks. So, I think we have enough licenses. Um, and overall, um, well, I don't know exactly how you want to write that in, but you definitely mustn't change the US case, otherwise it wouldn't be a free software license anymore. So they can do whatever they want with the stuff. Um, so I'm not really sure what the license would bring. If you look at how Kirkell reacted to it, I think that's the way I would suggest to projects as well, namely to say, uh, nice that you want to become CA compliant. Um, here, um, would be the contract for the consultation. And once again, a heartfelt thank you to the speakers. [Applause] Good. [Applause]