From Compliance to Community: Meeting CRA Requirements Together  ## Metadata - Author: [[What's in the SOSS? An OpenSSF Podcast]] - Full Title: From Compliance to Community: Meeting CRA Requirements Together - Category: #podcasts - URL: https://share.snipd.com/episode/f7c61c7b-83b0-4e4f-9782-eab05edca0c2 ## Document Notes ## Highlights - **Serendipitous Community Connections** - Michael and Jonatan connected through talks and public meetings like FOSDEM and SBOM Fringe events. - Their chance meeting sparked ongoing collaboration in the Erlang and Alpha Omega communities. Transcript: Christopher Robinson AO is nurturing. Michael Winser I think it starts with you, Jonathan. I don't know how you came to the meeting. Jonatan Männchen Was it FOSDEM? I gave a talk. Yes. We haven't really talked at FOSDEM, but I got to know you just from speaking at FOSDEM. But yeah, let's start there. Michael Winser So I'll go. At FOSDEM, I had a couple of talks, one of which was in a room that was partly organized by the folks from the STA and talking about funding and open source. And as you might imagine, it was a crowded room. A lot of people, a lot of questions, a lot. And, you know, Mirko and I, Mirko's from the STA, tried to put together a presentation just even to sort of explain what we are and how we do things or whatever. And in 15, 20 minutes, we obviously compressed a lot of thoughts and time into that. But it worked as intended, right? We got lots of good questions and people who didn't even know what we did or why or whatever sort of started coming out of the woodwork. And it's been really great. And John, over to you. Jonatan Männchen Yeah, it was actually the day before. It was the Fostam Fringe event. Oh, that's right. I was not present at your talk. I knew that it happened. Okay. But it was the SBOM fringe event where you were also speaking. I also didn't, I mean, I read through a lot of the OpenSSF stuff on a high level of what the OpenSSF is doing. And I saw Alpha and Omega, but I didn't really go into details there. I just knew that it existed. And yeah, you talking actually brought it up in my mind. And we, as the foundation, we are in this spot where we now have some financing, ([Time 0:05:26](https://share.snipd.com/snip/2ee41070-a358-49ae-9e1d-02a00d8b2915)) - **Trust Through Independent Foundations** - Foundations like Erlang Ecosystem Foundation build trust by supporting ecosystem security rather than in-house or outsourced efforts. - Outsourcing security can reduce trust with customers, so funding independent foundations benefits everyone. Transcript: Michael Winser Babbled some stuff. And here we are. So it's always the sort of serendipity things that really drive outcomes. Christopher Robinson This is a really interesting topic. And let me pull Olfen for a moment. As a product manager, kind of selecting components that are going to go into a product that your organization sells, how important is it to know that these upstream projects you're Relying on have support and do take security seriously? Ulf Riehm Well, I'm here as an antidote to a poison, which is vendor lock-in. So the bigger part of my life, I've been part of industrial automation and we were running factories for automotive supplies or plastics or whatsoever. And as part of this company, we were building machines and we were using open source, but we were using it in a, I wouldn't call it un-moral, but in a weird way that we were just using it, You know, and we didn't take care about what you say, whether it is maintained or safe. It's just there and you download it and you make a dependency and that's it. And the antidote is number one, that one day we stumbled over Alistair as well. That was actually... What was that? It was in Berlin. Yeah, Elixir event in Berlin. And we realized that there's a huge foundation behind it. And that was the cornerstone. And later when the CRA requirements came down to us, and we started to wrap our minds, how we would fulfill these requirements and make safe software for our customers, then only we realized How important these foundations may become to us. And we were lucky in a way that for other reasons, for reasons of resilience and reasons of resource management and reasons of development speed and whatever, you know, we have chosen For Erlang slash Alexia Stack. And so we were kind of enthusiastic about it, but we never choose it in the first place for security reasons. Then later, we realized that we are in front of a huge challenge of complying with these requirements, which are from EU. But basically, the United States are doing very similar stuff under different naming. And many of them requirements, they overlap. And then we realized, lucky we are that we have chosen a pond rather than an ocean. And that pond is so concise and kind of personal and kind of aligned, streamlined, I would say, that that gave us the confidence that if we use it to address these challenges, we would Possibly have a very concise and community to which we can reach out and meet real people, talking real talks and tackling real problems. So that is kind of how we ended up here. And this is also what made us finally, which convinced also my owner, we have a company owner, and my CEO and ([Time 0:07:15](https://share.snipd.com/snip/883f1f10-1272-4331-812f-aca635ee0411)) - **Normalize Security Practices** - Developers and organizations should bring in security experts to reduce risk and improve community security. - Normalizing security awareness and practices across projects raises ecosystem-wide safety and reduces vulnerabilities. Transcript: Christopher Robinson Security practices? And how does funding help that? Michael Winser Oh, I love this question. So somewhat what we've talked about starts with competency. You know, not everybody is a, you know, well, let's start with the problem of software supply chain security, right? As I love to say, it's like the Y2K problem without the same clarity of problem, solution, or timeline, right? Everyone is still learning a lot about this. And we have decades of technical debt. So expecting, you know, Mary and Joe, software developers working on a cool open source project to have competency in all the risks that they are essentially carrying forward is unreasonable. It's just not practical. And any solutions we do are not going to be magically by teaching everybody to become security engineers at the same time. Any more than everybody knows how to do front end, back end or use airline as a language or Rust or whatever. Right. There are competencies that take real time and energy to acquire. And that's a big deal. The other aspect is it actually goes back to the same competitive pressures that corporations are feeling at the sort of deepest end of the supply chain or the furthest out to the right End of the supply chain. Open source projects have different reward mechanisms. At the end of the day, being used, being valuable is something people care about. And a lot of the signal that they receive from their downstream dependencies, right, is somewhat abstract, but it's about usage. How many people are using me? How many, you know, GitHub stars, which please do not use GitHub stars as an indicator of popularity, but, you know, and so they'll do things that people are asking them to do. And invariably, what do people want to do? Like I'm building some software and somebody has built a module that does something for me. If I can shift the work onto them so that could you add a feature that does X, right? Says every enterprise customer ever and says every open source project. Software developers want somebody else to do the things that they're not good at, right? So I'm using some HTTP client library. It does some really cool. There's now an edge case on dealing with streaming over HTTP 3, blah, blah, blah, blah, blah. Could someone do that for me rather than me having to add that to my application code, which is trying to plug tabbing into slot B and make an MCP talk to Zapier, for example. And so that's a big part, right? There's a lot of pressure and signal towards adding new features. There's a competency they already have, which creates a fluency and ease of work around the feature set they've developed. So you have this hard hill to climb of security and things I don't really know about, an easy and rewarding hill to climb, which is things I do know about and people are asking for, right? Those choices are too easy, right? It's too easy to go down the path of doing more of that. And unfortunately, that problem is bigger than that because the people who are downstream who would benefit from the security and might benefit from the feature sets, they don't know More about the security. They don't know more about the code. So who is going to do that work? How's it going to happen? And, you know, this is where I think what's awesome about what Ulf and company have done, right, is saying, look, we need to bring some experts here. And what I love about it, too, is the point of leverage. Right. So you could go and look at all the supply chain things and fix all the individual pieces, or you can make it someone's job in an entire ecosystem to reason and think about that ecosystem And to make changes that are going to benefit all of them. And that's the alpha of alpha omega is all about that scale. Ulf Riehm And we would not have done it if we would not have faith in the fact that it can be done in that ecosystem. And we have faith it can be done in that specific ecosystem. Yeah. Michael Winser Because it's so streamlined and so concise and so complete in it. So feature complete that it helps us a lot. ([Time 0:15:55](https://share.snipd.com/snip/1af108a2-9ccb-4f24-8185-dca322491df9)) - **Erlang Foundation Becoming CNA** - Erlang Ecosystem Foundation is becoming a CNA to centralize vulnerability reporting for all packages. - This provides more accurate and ecosystem-specific handling of security issues. Transcript: Jonatan Männchen By the way, also a gap we're very specifically addressing. We're in the process of becoming a CNA. We're currently in the onboarding workflow, not done yet, but we're actually becoming a CNA for every package that is in the package manager if they're not covered somewhere else. Nice. Just because we think that we have more tools available to do the correct decisions in the whole thing and also reach the correct people than Mitra could, just because they're not part Of that ecosystem specifically. And yeah, so we really want to cover this as a CNA and also build in all the vulnerability reporting into the default tooling so everybody gets the benefits of that. That's awesome. Michael Winser This is, I mean, this is a pattern we're seeing more and more, right? And there's now documentation well-written by other parts of the Alpha Omega family on how to be a CNA. This is what we ([Time 0:20:17](https://share.snipd.com/snip/6fe0e0a1-b1cd-4936-8fa6-42e688fd8713)) - **Engage Upstream Communities Early** - Engage with upstream maintainers by introducing yourself and showing interest in their work. - Building relationships early helps prepare for handling audits, vulnerabilities, or bugs smoothly. Transcript: Christopher Robinson Would you give these communities and how they can enter in and become these good stewards and good participants in these types of situations? Michael Winser Whether you are an expert in coding, an expert in the problem space, an expert in the language or the package that you're using in your business, right? The first and simplest thing to do is to engage, to contact the organization's upstream of yours and say, hello, my name is Michael and I am benefiting from your work. I would like to make hello and say, how's it going? Introduce myself so that when you have a problem later on, whether it is an audit finding out that your CRA compliance is at risk because of some practice, or whether it's a silly little Bug, or whether it's a vulnerability has surfaced and you're not sure whose fault it is or what to do or how to do something or what the importance of it is. If you already have a working relationship, even if it's just purely social, if it's just literally love in the human sense of like, love is a verb. Hello, how are you today? I care about your work, right? You're already so much better off than you would be otherwise. And so the first thing to do is to engage and to listen, and then you will have a very clear path of opportunities forward, or at least the connection when you need them. Jonatan Männchen What I could add, a lot of people in an ecosystem don't really look outside of that ecosystem. Right, yeah. So it's really important that you're not trying to do everything by yourself. There's lots of smart ([Time 0:27:30](https://share.snipd.com/snip/3c72d780-ee9d-43ed-9dd6-86c5610e18c9)) - **Look Beyond Your Ecosystem** - Look beyond your own ecosystem to learn from others' security solutions and processes. - Collaborate across communities to avoid reinventing the wheel and utilize existing expertise. Transcript: Jonatan Männchen When you need them. What I could add, a lot of people in an ecosystem don't really look outside of that ecosystem. Right, yeah. So it's really important that you're not trying to do everything by yourself. There's lots of smart people from lots of different places that already thought about these things, but they haven't thought about it in your specific programming language, probably. But yeah, looking around what others are doing and actually connecting beyond the borders of your own ecosystem is probably one of the most important things to do. Ulf Riehm And from a user perspective, ([Time 0:28:40](https://share.snipd.com/snip/c3d30bad-45e8-4fcb-8414-250dfc2cbaee)) - **Be Honest About Open Source Usage** - Be transparent about which parts of your product come from open source and which are your own added value. - Honest disclosure encourages more contributions and resilience in open source foundations. Transcript: Jonatan Männchen Is probably one of the most important things to do. Ulf Riehm And from a user perspective, kind of the other end of the food chain, whatever, I wish that more people would be honest about their usage of open source and their contribution and distinguish Clearly what is their added value with what they have developed and they are willing to sell to their customers and what they have just grabbed as a base for what they want to offer as a Customer value. And if that would be a more honest and a more transparent way of doing business, then automatically more people would join an initiative like we have been doing. And that base would become a lot more resilient and even a lot. And it would be worth a living, you know, for the people who are doing it. I mean, currently most of, or many of them projects are maintained by enthusiasts and not for living. And sounds wrong, kind of wrong. Yeah, I would like I can't see why we should not distinguish between ([Time 0:29:10](https://share.snipd.com/snip/5932769c-69c6-427b-8abe-eefd38ebff81))