About this talk
This talk focuses on the recent work with the Eclipse Foundation to explore Article 25 of the Cyber Resilience Act (CRA), which aims to enhance open-source security and sustainability. The speaker outlines the historical context of open source and discusses significant inflection points that have shaped its current state, particularly the implications of funding and legal obligations. They emphasize the CRA's introduction of legal stewards responsible for managing open-source software, highlighting how the law changes the relationship between companies and the open-source projects they utilize. The presentation further addresses potential challenges and opportunities for stewards in upholding security obligations while ensuring their nonprofits remain viable. Ultimately, the speaker advocates for a collaborative ecosystem that elevates open-source stewardship into a sustainable practice, appealing to the community's participation in shaping this future.
Full transcript
[music] So I want to talk about the work I've been doing for the past sixish months with the Eclipse Foundation and contributions from a lot of uh other foundations as well um to try and understand this section of the CRA that doesn't get much airtime article 25 that I think could really make uh open source become secure by design and sustainable in the long term But to
explain this possibility, I think I need to set a lot of context. I'd love to ask the rooms. I see some familiar faces. How many of you are already familiar with the CRA obligations stewards uh and all of that? And how many of you are new to the topic space? Okay. Um I also want to tell a few stories. So I hope that uh you enjoy them
and also start telling your own stories because we many of us in the room open source maintainers, community leaders, uh founders of of companies, manufacturers, I know some too. We've changed the world in the past 30 years. And the generations that are following us need to understand the history to know how we got here to understand how to also get out of the mess that we're in
right now. And stories are how we as people contextualize that narrative. Have you ever had something happen in the world so important, so impactful that you were actually really far away from when it happened that you remember it as though it was where you were? Uh for me, one of those moments was a motorcycle ride across New Mexico when I got a call on the emergency phone
that should never never ring uh because the this is back when I worked for the US government. XZutil's exploit had just been discovered and they really wanted uh to check in with me about it. Um, this was a yearslong effort that had led up to this to do a social engineering attack on a low-level maintainer sort of XKCD Nebraska situation um that nearly compromised computer systems around
the world. And it changed how everyone talks about and thinks about open source security. But it wasn't a surprise to maintainers that this was possible. Many of us had modeled this kind of risk for decade or two before that. Many of the analysis of that situation and that postmortem highlighted that the cause was not the code itself or the maintainer, but the systemic lack of funding that
kept that maintainer able to handle the workload and wanting to continue doing that work. So I want to talk a little bit about inflection points that led us here. Way back when I was in college, the free software foundation was founded, GPL license, Debian was founded, also Burning Man and Defcon, which have become kind of community stalwarts. But people often don't realize though is the overlap between
these organizations. They all had similar ideals and in fact many of the same people uh were organizing the website behind the Debian project or sorry uh behind the Apache projects and Burning Man. Some of the same people going to one were going to the other trying to create these ideals in the world that led to the '9s. Uh were any of you around to see the old
This T-shirt is a weapon? I see only one or two nods in the room. Um, so something happened in the late 90s in the US that actually enabled all of this. Does anyone remember the Bernstein case series of cases? critical case law in the US enabled and led directly to the creation of OpenSSL. Prior to this case, developers like me when I was in college were really
afraid of publishing our code because the act of publishing a mathematical algorithm that was encryption or could be encryption could also be treated as uh exporting a weapon. And there were some pretty serious risks if you were a weapons exporter. None of us wanted to be. Uh that case and its settlement led directly to the freedom to publish open-source software including encryption libraries on the internet and
openSSL. The same people who wrote briefs to the court on that also helped found the OSI and Apache project. And the birth of the open- source community that followed led to the birth of e-commerce and the disruption of existing businesses that depended on uh charging fees for all the software everyone used. Modern internet grew out of that. Google, Facebook, and Amazon There was a quiet period after
the dotcom bubble burst and then in 2008 a ton of money poured in because MySQL got acquired for a billion dollars. That was a watershed moment for open source. Suddenly Silicon Valley took note and every tech company, every startup had to have an open- source strategy because every investor wanted to make another billion dollars. The same year Android and Bitcoin also got released. This year changed open
source because money poured and then the cloud happened and every company was pressured to pivot away from operational away from capital expenditures to operating expenditures as a business model. There was a lot of economic pressure around the world. quietly and then really quickly everything got cloudy and social media. Microsoft buying GitHub was a strategic choice to integrate open source into business because every company had to keep
their costs low. Had to use open and then unfortunately some bad things began to happen because today open source is everywhere. About 75% of all code is open source. About 94% of products include open source. And in some cases, basically the entire product is open source. Judging by stats like these, open source hippie is like me. We made it. Open source one. We're everywhere. We're on Mars.
We run in every product. Why then does it feel like every open source developer I know is completely burned out or out of work right now? Because these things began to happen. Vulnerabilities in open source didn't stay in open source. They began to affect the entire world. Hardle didn't result in a long-term policy change. Left pad was 11 lines of JavaScript that one developer got angry and
deleted one day and it took down the internet. Log for Shell resulted in congressional hearings for Apache. open source developers and maintainers going to talk to world governments to explain how a little bit of open source could cause this. And then during the Russian invasion of Ukraine, some developers began to take matters into their own hands and turn their projects into protestware. And again, governments had to
notice the uh international red cross has even had to issue updated guidance around uh uh wartime law for open source because of this. So, oh yeah, and then exit utils happened and and that thing that we were all really worried about uh nation states using open source to attack each other started to become a thing that people have to talk about. So, it's not that CBES didn't
used to happen in open source. They always did. It's that the problems when bad things happened in open source don't stay in open source anymore. They affect everything as a result of decades of externalized risk where companies just keep saying it's not my code, it's not my problem, it's not my fault. Well, the move fast and break things culture of Silicon Valley combined with investor-driven hype cycles
led to regulatory impunity and the regulators had to respond, right? Governments had to do something about this and we tried to make progress when I was in the US. Um, this is one of the proudest sentences I've ever said. Got turned into national strategy and then they called me up to work on it. Um, and we we tried to make progress in the US and Europe passed
a regulation. The CRA, it's why a lot of us are here today. Uh, because this now imposes real consequences for businesses. Serious fines. Companies cannot ignore it. Even though, as we heard in the last panel, if you were here, a lot of companies don't seem to be engaging yet when they really, really should be because the fines are up to 2 and a half% of their global
revenue and there's potential legal consequences personally for the executives. Um the CRA does what we also wanted to do to place the burden of compliance not on those who cannot shoulder it but on the companies on the manufacturers who are profiting from this and to a much much lesser extent it also imposes some lightweight obligations on open-source stewards uh which I'll talk about in the rest of
this talk because what changes with the CRA is that products with digital elements that's the term it uses throughout the whole legal text. PWDE product with now have to comply with the digital safety regulation. The automotive sector has been regulated for a long time. Food has been regulated. It it seems so strange that there's more safety regulations on going to a restaurant uh than computers that run
our lives. uh they can't just grab trash and put it on my plate. But a company can grab open source, grab someone else's code, not even just open source, can grab someone else's code, not pay any attention to it, put it in a product, and then claim that they're not responsible when it breaks. That's ridiculous. Uh but the CRA also creates a new class of legal actor
called a steward that stewards the digital commons. Um, and this is only relevant to legal entities who provide ongoing sustaining support for open source that is intended for commercial purposes. It has no effect if you're just a maintainer of your own hobby projects. If you're a college student publishing code, zero effect on you. And if you're a developer who's writing the code, but you're not a legal
entity, then again, no effect on you. This is a historic change. Truly landmark. It changes uh the way companies use open source. It will when they learn about it. Um and it creates this legal obligation for every manufacturer to contribute to the security of our digital commons. If they use open source and they find a vulnerability in the open source, they have to report it. That's a
legal requirement. It's not about a standard. It's in the text of the law. if they fix it downstream, they have to offer the fix back to the maintainer. I suspect a lot of them won't like this, but it's the law in Europe now. Um, [snorts] and that is a fundamental shift in the relationship between upstream and downstream. Now, good companies in open source have always done this,
but most haven't. I used to maintain some projects and it was always funny when I'd run into companies that had quietly forked and waited two years to try and do an upgrade and couldn't and then they're like, "Will you take our two years of downstream changes?" I'm like, "Of course not. We've been developing for two years. Just come work with us." This is now going to become
legally incentivized, but companies are a little slow to realize that. So, they need to talk more about stewards. Um, can I get a quick show of hands? Who is who does not feel like they know exactly what an open-source steward is? Great. How many of you think you might be a steward? Okay, I will disabuse you of that notion pretty soon. Um, how many of you are
confident that you work for an organization that is a steward right now? You might actually be. [laughter] [snorts] Um, so this is my little summary. It's not an exact copy of the legal text cuz that's huge. But basically an open source steward is a legal entity. So natural persons all of you are humans. I can you're not AI agents. Natural persons cannot be stewards. A legal entity
is that has to uh that that is responsible for and provides sustained support for an open source project that is intended for commercial activity. That's key. If the product is not intended for commercial use, not doesn't matter from the CRA perspective. Of course, it might be the coolest hobby thing in the world, but the CRA does not uh include it in scope and is a nonfor-profit entity,
sorry, is not a for-profit entity putting that on the market. So, if it sounds complicated, it is. Uh, this relies on duct typing like Some programming languages use duct typing to know what uh what class of variable is or sorry what's what what uh data type a variable is. The law kind of duct types here. So the commission took a lot of our feedback uh that this
is complicated and we'd like some help understanding their intent and they published this guidance about two months ago with a helpful flowchart. Um it's just barely readable. Um if you're interested go read the document. There's tons of examples where they're not naming any names, but they describe a lot of well-known open- source archetypes uh and give examples of which ones are stewards in which cases. Essentially, follow
the flowchart and if your activity falls in this pattern, then you might be representing a steward and otherwise you're not. Um, but I also want to highlight that over the past couple years, the European Commission has really been listening to the open source community and this is a perfect example of that. The guidance document that this is copied out of um and the the title is referenced
down there is the result of a lot of ongoing dialogue from people in the Eclipse Foundation, Apache Foundation, these communities and all over the world engaging with the European government. That process is open to all of you to also continue contributing to because there are parts of this that are not finished yet. But the goal that is articulated fairly directly in the CRA and very directly in
the guidance document is to enable sustainability by creating an ecosystem where manufacturers that use open source and open-source stewards can support each other. We know that collaboration in open source is the most efficient way to create software and the relevant standards. is more efficient than standards essential patents. It's more efficient than any other system we've seen for digital goods. The CRA seems to recognize this and encode
it in law and systematize the effectiveness by making it more cost effective to work upstream and support open source than to fork everything or ignore it and just pay liability costs. The mechanism for this is that manufacturers have an obligation to perform due diligence on their entire product and all of its dependencies. And most of them probably will struggle massively because open source dependencies and really product
dependencies are very deep. And as we heard on the last panel, the first step is for the executives to look at their dependency tree and then shock, gasp, horror, realize how complex it is and they have to tackle that and then hopefully turn to stewards and say please help. this mutual responsibility is articulated in the legal text that stewards have a very lightweight obligation. Document cyber security
and vulnerability handling and policies of the open source project. Cooperate with a reasonable request of the market surveillance authority. [snorts] Notify the users of the project, i.e. post on their website if there's a known vulnerability and a fix for it. uh and if their infrastructure is breached notify a relevant seert who can help them coordinate the the response. Manufacturers have a bunch of responsibilities for how they
consume particularly exercising due diligence in how they integrate it, reporting vulnerabilities back, as I mentioned a moment ago, including open source in the product risk assessment. Leftpad should never have been able to have the effect it did because manufacturers and service operators were allowing Leftpad to be continually retrieved from the internet in their products. Taking it off of npm caused products to break. That's their fault, not
the developers fault. This kind of thing should be surfaced in a risk assessment of a product that uses open source. That's what that obligation does. And it bears repeating that the regulations as applied to open source stewards are super duper lightweight. It is just what we in the industry and open source community think of as best practices. Most foundations already do this for some of their projects
if not all. And there's no product liability on a steward. how does it actually work is also not quite defined. Article 25 lays out the possibility. It states the intention to facilitate due diligence obligations of manufacturers. Big body of text. The commission is empowered to adopt a delegated act. That means it isn't written yet. The commission says they're going to do a thing. They have the power
to do a thing. They don't need to go back to parliament to ask for this. so long as it stays in that scope to create a voluntary security attestation program that allows developers or users to assess the conformity of open source and thereby help manufacturers. So based on this and based on the guidance document, I think stewards, open source stewards should be able to earn revenue from
doing this. And open source stewards should be able to generate enough income to support the obligations on the previous slide, notifying CERS, doing vulnerability checks, all those things, and anything else that helps the due diligence. they should be able to earn enough from the manufacturers's interdependence to keep the nonprofit lights on instead of just begging for donations every year. So I think this represents an opportunity for
sustainability for open source that we've never had. So last year, last September, I started studying this, working with Eclipse Foundation, some funding, and we set out to really dig in, build a community, analyze the impact, figure out how it could work. Our goals initially were uh just sort of recognizing the obligations would need to reflect capacity. Some projects are tiny and some stewards are small and some
just have a fiscal sponsor. There's a huge variety in the ecosystem and some foundations are really big and already have compliance uh and and certification processes in the nonprofit. We have to be able to account for that diversity in the ecosystem. Whatever scheme exists has to maintain the market efficiency that open source has realized over 30 years. We can't lose that in the attempt to improve security
at least not all of it. We have to avoid altering the aortionment of liability. The CRA text clearly says stewards are not liable for products because they're not placing products on the market. If they were, they'd be a manufacturer. Well, a voluntary security attestation must not change that. Otherwise, it just turns stewards into manufacturers and defeats the whole purpose of this. And it also needs to recognize
that the way security um secure development uh product safety risk assessments all those things are performed in a manufacturer is a different environment. Downstream is not equal to upstream. The same process may not work upstream. For example, because most projects don't know the use case. When a manufacturer builds a product, they know the use case they're building it for. They say it clearly on the marketing. But
most upstream projects don't know this and can't know this. And therefore, because the CRA is fundamentally a riskbased approach to cyber security. If you don't know your use case, you can't do a threat assessment. You can't do risk analysis in the CRA way most of the time. So as we worked through this, we came up with some a bunch of ideas. The ones that have stuck so
far are the ones I'm going to talk about in the next couple slides. Our theory, and this is all our theory at this point, I'm not talking about the CRA anymore. I'm now I'm going to just talk about what our working group has come up with that two tiers are necessary. A lightweight tier to handle componentlike projects. These are things that really don't know what their use
case would be. It's the screw in the analogy of building an airplane. The same screw might be used in a child's toy, in a blender, and in an airplane from the same manufacturer, but the first screw costs a few cents, and the last screw costs a few hundred euros. And the difference is the certification and testing and compliance and liability insurance around it because the each sort
of further down the supply chain you go, the more you know about the use case. So projects that don't know their use case can't do that. There still needs to be something they can do to indicate that they're developed well. They have a vulnerability handling policy uh and and good open source practices. On the other hand, you have much larger projects that are basically productike. Think an
operating system or a web browser or an entire office suite. And in fact, you can just look at the CRA in uh NX3 and NX4 for a list of product categories that they've already defined as needing to meet a higher bar. So if your open source project is in those categories, you it's not a component, it's uh and it might benefit from something like heavyweight. Now what
does that difference mean? I'll talk about that. In theory, the lightweight attestation is mostly what projects already do. The BSI also published a requirement for their procurement. It's a standard for open source project uh safety. Anyone can look at it and check it. It's not that different from like open SSF's um scorecard or the baseline checks. It's not much more than this short list. That short list
um and it covers part of the CRA obligations. NX1 part two, a little bit of NX2, a little bit of NX7, and it signals good practices. This will help a manufacturer compile their due diligence and say, "We're only using open source that has somebody out there who can help us if we find a vulnerability. We know where to send the report. We've compiled it in the ESBOM."
That's about all it does. But it does something and that is more than uh just grabbing you know open source of no prominence and taking full responsibility. So it helps shift that a bit. On the other hand this is much more theoretical. Right now the actual product safety standards in the CRA are not generally public documents. Some folks may have access through a national standards body uh
or their employer. But the theoretical the theory here is that for a product like open-source project to meaningfully reduce the due diligence obligation of an integrator manufacturer, it would need to be able to show that it can meet a CRA style use casebased risk assessment. perhaps even to do that and publish it or not publish it. You're probably thinking, "Isn't that expensive? Doesn't that take a lot
of time and skill that opensource projects don't have?" Yeah, it would. This is where I hope manufacturers are willing to step up and fund specifically for this because if they have an obligation to do this downstream anyway, it'll be a lot more efficient if 10 manufacturers pay for one risk assessment than if each manufacturer tries to do this themselves for every open source dependency they have. But
many questions remain in the working group. How can these support due diligence without shifting liability? It seems clear that that's the intention of the European regulators. But for example, what happens if a US registered nonprofit who has users in Europe publishes a voluntary security attestation and gives them to Europe or European manufacturers? Would that create liability for the open- source uh community or for the the 501c5
C6 in the US? I don't know. I'm not a lawyer and that's a question for US lawyers. It seems like it shouldn't in Europe. But what what would happen in different countries is out of scope of European law except the mutual recognition treaties that c countries often sign again out of my scope. Should steward should stewards charge fees for these? And what are different economic models? How
do you price it? Do you publish it publicly if you get enough money for the year? Do you only sell it uh under certain conditions? These are all good questions that the community should get together and talk about some more. The regulation stipulates that third party attestations need to exist, need to be possible. There are implications of this that are complicated and challenging. We've been talking through
some of those. Um, but it's pretty clear that first party attestations i.e. those made by the steward are more valuable. They're a stronger signal of trustworthiness in most cases. uh but there needs to be a way for an auditor or a European market surveillance authority to repudiate to disagree with such a first party audit if there's a good reason to think that the person or the entity
making the uh attestation was not trustworthy. Um do variations in national law between different countries in the Europe affect this? Also an interesting question right now. Um there have been some good discussions even just today on this topic. Um and again ultimately this is our working theory right now. We won't have answers to this until at least when the commission does publish a delegated act and quite
possibly not until it gets tested uh in courts. So 5 to 10 years I don't know not tomorrow. Um I want to close this talk with a little bit more food for thought because as we've been working on this uh over the past six months a couple things have changed around the open source landscape around AI and gener generative tools um in the world while it is
built and runs on open source right now we are free to publish our ideas as functions functional speech because creat Creative expression is copyrightable. Throughout human history, every time there's been a phase change in how information is propagated, it has led to societal change. Open source has done that. AI seems to be about to do that as well. In ancient history, it took years to memorize a
book by oral transmission. The cultures that we know the most about were the ones that developed writing a until a few hundred years ago. It took months to copy a book by hand. Knowledge was restricted to the wealthy and then the printing press led to revolution and social change directly fueled the Protestant Reformation. And the growth of science and public institutions of knowledge and libraries as we
know them today. Ideas spread faster and faster the more information could propagate. Then radio and television changed this landscape again. Propaganda over airwaves could cross borders and walls. Social media created another asymmetry, an algorithmic influence that enabled new forms of organizing revolution and oppression. That's just the past 10 years. This practice of cocreating knowledge and sharing it that's as old as humanity. I want you to see
that this is not unique to open source. And as such, it's not restricted who can participate in this. Even if you're new to open source, you are part of this. You can help change culture right now. But there has been another phase change in the medium of information propagation. A lot changed since my adviser introduced me to neural networks in 1998. [snorts] We've had AI hype cycles
before. This is different. Um, I want to ask a quick show of hands. Where were you when you thought this AI stuff might actually do something? Good or bad, just something big was happening? 2010, 2015, 2020? 2025. for me it was 2019 at an OpenStack conference. Uh, every participant was asked to envision a future for sovereign cloud. Once again, also a hot topic in Europe. I pitched
that I wanted a sovereign AI that ran on my hardware, on my cloud with my data and could replicate my voice. So I could travel around the world to conferences and speak in the local language and hear words back without giving my data to some other company that could also copy it or abuse it or whatever. This sounded really far-fetched. Sounded like Star Trek and a little
communicator. Um, and today we basically have this I have agents running at home on my own hardware that can do translation in dozens of languages that can build off of my body of work and replicate my speech pattern and I'm not using a public cloud for this. We have come so far so fast and there's a lot of concern right now that all this work around open
source security and the CRA doesn't matter because these tools can just rewrite code remove the copyright uh or find vulnerabilities in everything. And I don't know if LLM's large language models will ever be good enough to fully replace even the most junior developer, but they but companies seem to be hoping for that. And our task as developers, I was one for most of my career, seems to
now be quite different than it was just two Our interface to knowledge has changed yet again, whether we like it or not. After the invention of the printing press, there was less need for scribes. But I can still buy handmade paper with other binding. Our need to sit at a computer and type is changing. But the need for stewardship for humans to take responsibility for the quality
of code in a digital commons that is not I don't believe open source is going away any time as a result of all of this LLM stuff, but we have an opportunity right now around this regulation. The European Commission could make stewardship of the open-source digital commons into a sustainably funded professional sector whose role is to ensure that this continues that the digital world continues to be
trustworthy, not just controlled by corporations profiting off our private data. And even if governments don't do this, we as a community can keep working on it and we should because the alter alternative is much worse. Thank you. [applause] >> Thank you Eva for the presentation. We have time for one question. >> Yeah. Yeah. >> Good. Any question? >> Either bored you or stumped you. any [snorts] sure
>> okay if I'm an open source maintainer and I have a known vulnerability >> what do I have to do what is my legal >> if you're an open source maintainer and you find a vulnerability in your own >> in my own project just my project that I that I'm maintaining Is the project supported by an open source steward in Europe? >> Then you don't have a
legal responsibility under right just under that premise. Nothing. >> Last opportunity. >> Any questions about anything in the talk? So under the current uh understanding of based on the guidance of what an open source steward is, can that be reconciled with the product liability directive? Uh does the open- source steward potentially have a risk of no liability under the CRA but liability under the PLLD, liability under
private rights of action under the PL? >> Great question. Um my understanding I'm not a lawyer and I'm not the government uh but my understanding is the PLLD only affects um economic actors only covers as its scope economic actors placing a product on the market. A steward by definition in its role as a steward is not an economic actor not placing a product on the market. Now
[snorts] the tricky bit comes in the duct typing. It is conceivable that the same legal entity could be a steward for the same code in this condition and a manufacturer for that code under this condition. That ambiguity I really hope the commission will clarify because it could lead to this kind of scenario if you think you're a steward and you're also a manufacturer and then the court
says well you were one when you thought you were the other. So having a clear line between the two seems like the easiest way to do it. If you are a public benefit organization or a nonprofit that is being a steward, stay a steward. Stay in that lane. If you're a company selling products, stay in that lane. If you want to do both uh talk to your
lawyers. >> Thanks Eva. >> So thank you very much. I think we are closing now. Thank you Eva for the presentation. All of you for participating today. >> [music]
