The EU Cyber Resilience Act (CRA) reporting obligations activate in September 2026, yet 72% of North American organizations surveyed by OpenSSF still know little or nothing about their legal exposure. Liability under the CRA does not require writing code. It attaches to whoever holds the commercial relationship with a European entity, meaning distributors, importers, and manufacturers who bundle open source components are all on the hook. CTOs who have not yet inventoried their software components or evaluated them against a security baseline are already behind.
In this interview on TFiR, Christopher “CRob” Robinson, Chief Security Architect at OpenSSF, covers the full scope of CRA liability across the supply chain, the documented cost of private forks, what OpenSSF and the Linux Foundation provide to help manufacturers and developers meet their obligations, and the two concrete steps every CTO needs to take immediately.
Guest: Christopher “CRob” Robinson, Chief Security Architect at OpenSSF
Show: TFiR
Here is what every platform engineer, security architect, and CTO shipping software into or through the EU needs to know.
Technical Deep Dive
Q: How much has CRA awareness actually improved since last year?
Christopher “CRob” Robinson, Chief Security Architect at OpenSSF, reports that awareness has not measurably improved despite a full year of community education across podcasts, articles, seminars, and foundation-led programs. Last year 62% of survey respondents knew little or nothing about the CRA. This year, with nearly double the respondents, that number rose to 66%, a result Robinson describes as statistically flat. North America is the weakest region, with 72% of respondents reporting little to no awareness, even though many of those organizations sell products into the European Union.
“After all of our work, whether it’s OpenSSF, the Linux Foundation, other foundations like Eclipse or Apache, all the work we’ve collectively done as a community, at least according to our survey, has not measurably moved the needle.” — Christopher “CRob” Robinson, Chief Security Architect, OpenSSF
Q: Why is CRA awareness so low in North America compared to Europe and APAC?
Robinson identifies several compounding factors. Many smaller enterprises believe they have no European customers and therefore no exposure, even when they supply components that get embedded into products sold there. Geopolitical distance leads North American organizations to treat EU regulation as someone else’s problem. Open source maintainers, meanwhile, are focused on building software and have no natural reason to track regulatory developments in a foreign jurisdiction. APAC scores notably higher on awareness because so much of its manufactured output, including cars and consumer electronics, is exported to European markets, creating direct commercial incentive to understand the rules.
“There’s this impression by a lot of smaller enterprises like, I don’t have anything to do with things in Europe. I don’t have customers there. Unless you are a hyperscaler or a high tech company making servers or routers and you absolutely are selling products into this space.” — Christopher “CRob” Robinson, Chief Security Architect, OpenSSF
Q: Who is legally liable under the CRA when a product contains open source components?
Liability under the CRA attaches to whoever holds the commercial relationship with the European citizen, company, or government that acquires the product. Robinson is explicit: writing the code is irrelevant to determining responsibility. If a company distributes or imports a product containing open source software and sells it into the EU, that company bears the regulatory obligation. Open source maintainers whose code gets consumed downstream carry no legal or regulatory risk under the CRA, though they do face reputational and demand pressure from manufacturers scrambling to comply.
“You’re responsible. And Red Hat has their own responsibilities. You cannot just say I did not write the open source code, I’m just packaging it, so I’m not.” — Christopher “CRob” Robinson, Chief Security Architect, OpenSSF
Q: How does CRA liability flow through a multi-tier supply chain involving distributors and component suppliers?
Robinson explains that liability follows the money and the EU-facing relationship. The distributor or importer who places the product into the European market is the primary responsible party. Component suppliers who have no direct EU relationship are not immediately exposed to regulatory fines, but Robinson predicts they will face increasingly strict contractual requirements and SLAs from the vendors above them in the chain, because those vendors carry the regulatory risk. In litigation scenarios, Robinson considers it probable that companies dragged into EU courts would bring their suppliers along to help transfer liability if those suppliers failed to meet agreed obligations.
“It’s not going to be like a legal risk where you’re going to get a fine, but you’re going to get incredibly strict contracts and SLAs that you’re bound to, because the person you sold the thing to is selling it to Europe.” — Christopher “CRob” Robinson, Chief Security Architect, OpenSSF
Q: What does the CRA require from distributors and importers doing due diligence on their suppliers?
Robinson describes a procurement-and-contracts model for due diligence. Distributors and importers who do not manufacture the underlying product must validate through contracts and procurement language that their suppliers have met CRA requirements. Specific contractual asks include: adherence to cybersecurity requirements in Annex 1 of the CRA, a CE mark on the product, and an attestation confirming the product’s compliance level. Robinson frames these not as optional best practices but as the mechanism through which the responsible party secures itself: the condition of sale becomes proof of due diligence.
“We will not sell this unless you do these things and provide us this evidence.” — Christopher “CRob” Robinson, Chief Security Architect, OpenSSF
Q: What risk do open source maintainers actually face under the CRA?
Robinson is clear that maintainers face no legal or regulatory risk under the CRA. Their exposure is reputational and operational. If a European user downloads their software directly and encounters a vulnerability, there is no contract and no regulatory hook. The more practical risk is demand pressure: manufacturers who are being fined or audited will turn to upstream maintainers with urgent fix requests, adding to the burnout already present in the open source community. Robinson expects a wave of this kind of pressure to hit when CRA reporting obligations go live in September 2026.
“Every manufacturer that copied your software, now they are being fined and yelled at by the union, they’re going to start harassing you. Gimme, gimme, gimme, gimme, gimme.” — Christopher “CRob” Robinson, Chief Security Architect, OpenSSF
Q: What resources has OpenSSF built specifically to help developers and manufacturers meet CRA obligations?
Robinson describes a layered set of resources. There is a role-specific training class covering every persona in the supply chain: manufacturers, developers, consumers, and regulators. For open source developers, OpenSSF has published a guide explaining which project-level practices, such as publishing a security policy or generating a software bill of materials, reduce the volume of downstream compliance questions. For manufacturers, working groups are building tooling to help execute on specific CRA requirements. For enterprise consumers and government regulators, OpenSSF has produced a checklist of project behaviors that signal CRA compatibility, allowing consumers to assess whether a given upstream project lowers their compliance burden.
“If you publish a security policy or you provide a software bill of materials, the theory is you’re going to get less questions from downstream.” — Christopher “CRob” Robinson, Chief Security Architect, OpenSSF
Q: How can manufacturers use the OpenSSF checklist to support upstream open source projects?
Robinson describes the checklist as a two-directional tool. Manufacturers can use it to evaluate whether a project they depend on meets a minimum security hygiene standard. They can then contribute directly to closing any gaps in that project, for example, by helping configure a locked-down GitHub repository, or by donating engineering time to integrate SBOM generation into the project’s CI pipeline. Robinson frames this as responsible upstream participation that simultaneously reduces the manufacturer’s compliance burden, reduces the regulator’s scrutiny, and builds a long-term collaboration with the maintainer community.
“If those manufacturers want to do right by their upstream creators, they could take that checklist and go upstream and donate those things.” — Christopher “CRob” Robinson, Chief Security Architect, OpenSSF
Q: What is the business case for joining or contributing to an open source foundation rather than going it alone?
Robinson argues that foundation membership gives both projects and their commercial users access to infrastructure and protections they cannot easily self-provision: CI/CD infrastructure, vulnerability reporting pipelines, legal protections, and marketing support. For manufacturers and enterprise consumers, getting involved in the foundation community is a form of responsible consumption. It creates direct lines of communication with upstream maintainers, enables co-investment in security improvements, and reduces the risk of depending on unaffiliated, potentially abandoned projects. Robinson notes that GitHub reported over 630 million projects in its ecosystem, and only a fraction of those are built to commercial-use standards, making informed selection and active participation essential.
“Consume software responsibly. Just because some software exists, it might be a student project, it might be abandoned. If the maintainer explicitly said I’m never going to update this, don’t ever put that into something you’re selling.” — Christopher “CRob” Robinson, Chief Security Architect, OpenSSF
Q: What should CTOs do right now to prepare for CRA compliance?
Robinson prescribes two immediate actions. First, generate or acquire software bills of materials for every component in every product being shipped. This means a complete inventory with no unknowns. Second, apply a structured evaluation methodology to every component in that inventory. Robinson points to the OpenSSF Open Source Project Security Baseline as one such framework. The goal is to verify that each component meets requirements and will satisfy customer expectations as well as legal and regulatory obligations. Robinson is direct that this work should already be underway, because it is not a small job.
“They need to either generate or acquire software bills of material for every component they have. Take an inventory of what exists and absolutely know without a shadow of a doubt what you are selling.” — Christopher “CRob” Robinson, Chief Security Architect, OpenSSF
Q: What does LF research show about how manufacturers currently handle upstream open source dependencies?
Linux Foundation research found that approximately 51% of manufacturers and vendors passively rely on upstream projects to fix problems without actively participating in or contributing to those projects. Robinson flags this as a critical vulnerability in their CRA posture, because upstream maintainers have no obligation to prioritize a downstream commercial user’s needs, and in many cases are unaware of how their software is being used. The same research quantified the cost of an alternative strategy, private forking: the LF chief economist estimated that managing a private fork costs approximately $250,000 per release. Organizations running multiple forks face costs that multiply accordingly.
“If you’re waiting for someone to do your work for you, you’re going to have a really bad day when the CRA comes online.” — Christopher “CRob” Robinson, Chief Security Architect, OpenSSF
Q: Why are private forks a poor long-term strategy for managing open source dependencies?
Robinson and Bhartiya both identify the compounding technical debt problem with private forks. Once a fork diverges significantly from the upstream codebase, integrating new upstream releases becomes technically complex and increasingly expensive. The LF estimated cost of $250,000 per release does not decrease over time; it grows as the delta between the fork and upstream widens. Robinson’s recommended alternative is active upstream participation: contributing fixes, submitting test cases that reflect real-world use cases, and engaging the maintainer community so that the upstream project evolves in ways that serve the commercial user’s needs without requiring a separate branch.
“Become an active participant in the process. If you’re a CTO and you need to justify budget or headcount, think about those figures to help justify this.” — Christopher “CRob” Robinson, Chief Security Architect, OpenSSF
Q: Why do upstream maintainers often fail to anticipate how their software is being used in commercial products?
Robinson notes that maintainers build software to solve specific, often narrowly defined problems and document advised use cases accordingly. They are frequently unaware of the novel deployment contexts their software ends up in, citing examples like the Linux kernel being embedded in talking toys, satellites, and submarines. Robinson references conversations with Linux kernel maintainer Greg Kroah-Hartman as illustrative of this dynamic: even deeply experienced maintainers are routinely surprised by where their code ends up. The implication for commercial users is that getting involved in the upstream community, submitting relevant test cases and use case documentation, is the only reliable mechanism for ensuring the upstream project’s evolution accounts for their needs.
“Upstream does not understand how you’re using their software. If you have different use cases, getting involved in that community means you can help submit test cases to the project.” — Christopher “CRob” Robinson, Chief Security Architect, OpenSSF
Q: What is the role of the open source software steward under the CRA framework?
Robinson explains that the open source software steward role under the CRA is filled by nonprofits and foundations such as the Linux Foundation, Apache, and Eclipse. These entities provide unaffiliated projects with infrastructure, vulnerability reporting support, legal protections, and marketing resources that individual maintainers cannot access on their own. For manufacturers and commercial consumers, Robinson strongly advocates using this steward layer as a routing mechanism: if a critical dependency is unaffiliated, the responsible action is to help move it into a foundation, or to find ways to directly support the unaffiliated maintainer rather than simply consuming their work.
“The benefit of coming into a foundation is you get access to more resources: CI/CD infrastructure, help with vulnerability reporting, assets that an unaffiliated project might not have access to.” — Christopher “CRob” Robinson, Chief Security Architect, OpenSSF
Q: What CRA-related questions are commercial organizations actually asking OpenSSF right now?
Robinson reports that the majority of inbound questions from the community are not expressions of total ignorance but rather requests for nuanced role-specific guidance. The common pattern is a scenario-based question: given this specific supply chain structure, am I acting as a steward, a manufacturer, or something else, and what exactly am I obligated to do? Robinson notes he is actively working with automotive industry participants through the OpenChain supply chain standard project to map out complex multi-party liability matrices involving multiple tiers of manufacturers, repackagers, and distributors.
“It’s a lot of this: if company A makes product A and company B repackages that and company C buys it, we’re trying to map out this matrix.” — Christopher “CRob” Robinson, Chief Security Architect, OpenSSF
Resources and Documentation
- OpenSSF, open source security foundation providing CRA compliance training, checklists, tooling, and the Open Source Project Security Baseline
- OpenSSF Training and Education, role-specific CRA compliance courses for manufacturers, developers, consumers, and regulators
- OpenSSF Open Source Project Security Baseline, framework for evaluating whether open source components meet minimum security requirements
- OpenChain Project, ISO standard for open source software supply chain compliance, with active CRA working groups
- Linux Foundation, steward organization providing legal protections, CI/CD infrastructure, vulnerability reporting support, and CRA-related research
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: Hi, this is Swapnil Bhartiya and we are here at Open Source Summit in Minneapolis and we have with us once again Crob, the chief security architect and CTO at the OpenSSF. If you look at the EU Cyber Resilience act, it is here. The 2027 enforcement deadline is almost here. It’s not about are you ready or not, it’s more about how ready are you? Are you? I would love to know. We have talked a lot about it, but how much awareness is there right now about it? Or you are still like, oh, we are still struggling to tell people, or you’re like, no, now everybody’s aware. Now they are rushing to ensure.
Christopher “CRob” Robinson: I wish that was the case we had. So last year we did a study and it ended up based off of the data. We called it unaware and uncertain. So at the time, about a year ago, the ecosystem didn’t know a lot about what was going on with the CRA or what the obligations were. And so we decided to repeat the study so that we can kind of recognize, are there any trends? We reran the study, made some adjustments, added a couple questions, and so we now have a new set of data kind of based off of the experiences of the people that contributed to the survey. And let’s focus on the positive. We were able to get almost double the number of survey respondents, so the data has better precision. We were again getting a much broader swath of opinions, which was great. The bad news is, unfortunately, after all of our work, whether it’s the Open ssf, the Linux foundation, other foundations like Eclipse or Apache, all the work we’ve collectively done as a community, at least according to our survey, has not measurably moved the needle. So last year, the respondents were 62% of the people that took the survey either didn’t know anything about the CRA or knew very little. This year, again, we doubled the number of people responding and we were up to 66% of the people that took the survey don’t know anything or are uncertain. So that was kind of generally, statistically kind of flat. And I recognize all the work we’ve done, you know, going talking on podcasts like this and articles and blogs and seminars and classes, and it’s just a little disheartening. And then when you kind of chop up the data and look at it by geography, Europe is doing very well, unsurprisingly because it’s a European law. APAC actually had a Pretty decent level of awareness. But when we think about my friends and neighbors here in North America, we were at, I believe 72% of the respondents didn’t know anything or knew very little. Which is sad because these, these companies sell into the European Union and there’s some real consequences for manufacturers if you aren’t able to meet these obligations.
Swapnil Bhartiya: What is the reason behind this gap in awareness? Because some of these companies who are catering to global, you would expect them to be aware of the market they are selling into, especially in this geopolitical, you know, you have to be even more aware of what. So what is the reason why you feel because you talk to a lot of folks that the gap is the gap? Because of course, I think in Europe the culture is also different when it comes to security, privacy and all those things. Here the culture, I mean everybody is on Facebook, you will log into everything or Facebook. So the culture of safety, security is not there. Or is it about. They don’t look at the European market as one of the primary market that my market is North American market. So I don’t really care. But if the fine is there, you will be fined. It doesn’t matter how much you’re selling. So I would like you to emphasize a bit on the importance, it doesn’t really matter how much you sell into Europe because this may become a global phenomenon and if you’re not ready, you won’t be ready.
Christopher “CRob” Robinson: Yeah, we won’t get into fudge, but broadly speaking, the US and China are the two largest markets to sell into. Europe’s a close third. So if you have an organization that sells internationally, they’re going to try to sell it in as many places as possible. So that’s why, kind of looking at the data, my impression is APAC takes this very seriously because so much of the products, whether it’s cars or electronics, gets exported out to Europe and America and South America and Africa gets sent everywhere. So they are very aware and conscious of this. And actually I’m in talks right now with elements of the Japanese government where they are considering how do they implement their own version of the CRA because they take these requirements incredibly seriously. Thinking about it here, I get the opportunity to go to open source conferences like this. I go to cybersecurity conferences and I, I just, I do a lot of talking with people that are in kind of regular Jobs, I work at a bank, I work at a retailer or a hospital. And a lot of these folks, like when I try to educate them, hey, there’s this new law coming around and it’s kind of instituting these cybersecurity practices you have to do. And if you sell in Europe, you’ve got to follow it. And there’s this impression by a lot of smaller enterprises like, I don’t have anything to do with things in Europe. I don’t, I don’t have customers there. Unless you are a hyperscaler or a high tech company where you’re making servers or routers and you absolutely are selling products into this space and it’s just this kind of disconnect and then, you know, geopolitics definitely plays into it. That’s something that happens over there. And then when you think about like open source maintainers, their, their passion and their interest and focus is on generating solutions, adding features, adding value to their community. They don’t care. They don’t know. They don’t want to know about global regulation because broadly they’re not specifically beholden to it. And that’s where, like this, this disconnect where we’re going to have this large body of the world that is not prepared for the cra, they’re going to realize that there’s some fines and the union is going to take this very seriously and the reporting obligations Turn online this September 2026. And what I’m afraid of is that’s going to create this panic and they’re going to rush and start to bother maintainers who rightfully so, are kind of disconnected from the regulation. But they’re going to start to make demands and add to the burnout and just kind of overwhelmed nature of what’s going on with Upstream right now.
Swapnil Bhartiya: You talked about a lot of smaller companies. Now we can look at automotive. You know, they sell cars into that and almost today every car, it could be Zephyr, it could be Android, it could be a lot of open, I mean, when you open the dashboard, you’ll see the source code no matter which car you’re driving. So they are not software companies, but they are hardware. But they are, of course, medical equipments are there. Those are the tricky ones. And even if you look at smaller players now, this is a tricky solution. They themselves may not sell, but maybe they are distributors, maybe they are resellers, maybe they are other companies who, let’s say XYZ company, they sell into Europe and then they sell someone else’s product. But Then who would be responsible? You would be responsible for it or the distributor has nothing to do with that. So what I’m trying to also understand is that when you talk to them, big companies like automotive do talk to them as well.
Christopher “CRob” Robinson: Yes.
Swapnil Bhartiya: And what I want to hear their perspective. Sometimes they may not even know. They’re like, we don’t use any open source. We just use this, you know, technology, which we, we have nothing to do with open source. So awareness is less. Is awareness more about their own stack or is awareness less about the law?
Christopher “CRob” Robinson: It’s a little of both. And when you think about a modern automobile, it is a mobile data center. There is so much technology in there and so many things going on that it is just like the days of yore when I used to build physical data centers. So, and I will say that my experiences with the automotive makers is they do because you bring in the additional aspect of safety in human life. They are generally really well aware of kind of what the rules are and they have much more insight into like their stack than somebody that makes a home router or a talking toy or even a phone, because you don’t have that safety and health kind of aspect of it. And what the challenge is, and what you noted is that yes, I might not sell a product in Europe, but I make a hard drive or I make a network card that gets embedded into a firewall or a server that gets sold. And what those organizations are going to see is as the actual vendor or distributor realizes, you know, you have to follow the cra, you’re going to see stricter contractual requirements. So it’s not going to be like a legal risk like where you’re going to get a fine, but you’re going to get incredibly strict contracts and SLAs that you’re bound to, because that the person you gave, you sold the thing to is selling it to Europe. And they have that regulatory and legal risk.
Swapnil Bhartiya: And who would be at the receiving end? The distributor who was putting all the hard drives together or the company whose label is on the hard drive?
Christopher “CRob” Robinson: It’s whoever has the relationship with the European entity, whether it’s a citizen or a company or a government, who you bought it from, who you bought it from. And it’s their responsibility. Yeah, it’s their responsibility to make sure their supply chain is secure.
Swapnil Bhartiya: We have talked about it in past, but what does this legal responsibility mean for software manufacturers who may not write code, but use open source code? Basically?
Christopher “CRob” Robinson: So in the lens of the cra, it’s about that Product with digital elements, which is, it could be hardware, hardware and software. Hardware, software, firmware, or any kind of combination of the three. So again, whoever has that relationship with that European citizen or entity, they’re on the hook. And if your distributors or importers are in the mix here, they have obligations to be, go through and do due diligence. But at the end of the day, it’s whoever. Where that money changes hands is where that responsibility is. And you’re going to see. I, I can’t predict how things are going to go into the European courts, but I find it extremely improbable that if somebody, a big company gets drug into court, that they might not. They will also bring in their suppliers potentially if they feel their suppliers aren’t meeting their obligations to try to help mitigate and transfer some of that risk, that liability.
Swapnil Bhartiya: Or the company may say, hey, you know, I have not written this piece of code. I am just, you know, it’s the Red hat who is responsible. No, you are responsible, not Red Hat.
Christopher “CRob” Robinson: You’re responsible. And Red hat has their own responsibilities.
Swapnil Bhartiya: But they are not on the hook. You are, you cannot just say, hey, I did not write the open source code. I just, I’m packaging it, so I’m not. Because these things are, I think. And do you. What kind of. When you talk to companies, you know, some companies, you said automobiles, they are very, very mature because they are dealing with life at stake. But when you do talk to a lot of companies, what kind of questions you get where you’re like, oh, they don’t even know about that. There’s nothing wrong about that. But what kind of queries you get where you’re like, surprised that they don’t know about these basics.
Christopher “CRob” Robinson: So it’s, it’s interest. Then the law is very dense and nuanced and there’s a lot of nuance to it. And I don’t expect a layperson that doesn’t do public policy work or government affairs to kind of understand all the details. But just the fact that this is a, there was a lot of pomp and circumstance when the law came out. There’s been a ton of people like myself and others that have been talking about it and just to not have heard that there is a new cybersecurity law in Europe and even kind of have that inclination of do I need to do anything just to kind of do some research. So that’s where a lot of the people, the majority of the questions we get are that I get with my community is more the nuanced questions in this scenario, am I acting as a steward or a manufacturer or what are my obligations giving this context. And actually I’m working with some automotive people on a product project, a sister project called Open Chain. It’s a supply chain standard. And that community’s put forth a lot of questions and it’s a lot of this. If company A makes product A and pro and company B repackages that and then company C buys it kind of and we’re trying to making out this matrix. So it’s a lot, I don’t get a lot of amazement like I’ve never heard of this but it’s a lot of like what does this mean? How do I in this situation, this scenario, what am I on the hook to do now?
Swapnil Bhartiya: Let’s just expand. Company A is using solution for company B. Now they’re only using it like now whether the company B is own software. So what can company A do? Because they are just the distributor but they are the one on the hook.
Christopher “CRob” Robinson: Yeah. And again the roles of the cra. Well and from that standpoint they need to. This is generally done through procurement and due diligence. So if you are the responsible party and you didn’t make it, you’re a distributor, you’re an importer, you need to be doing due diligence that the product that you are going to be representing has done the right things, that they are meeting that standard. And you do that through contracts and procurement language saying you must follow the cybersecurity requirements in Annex 1, you must have a CE mark, you must have a kind of attestation level that what your product qualifies that. But again the onus there is, if there’s a distributor importer, they’re the ones, they’re the primary ones that are responsible. And then again it would get passed to the manufacturer eventually if they’re, if they like if a company has no relationship to the European Union that the distributor and importer kind of take that role. But it’s again that they would secure that through contracts. So we will not sell this unless you do these things and provide us this evidence.
Swapnil Bhartiya: As you earlier said that open source developers, it’s not that they don’t want to do that, but this is not what they wanted to do. Otherwise they would have gone to security. They just want to most of the time they started a project to scratch their own itch. The project grew, suddenly a lot of people are using it and now you’re telling them to, you know, do that as well. So this is not what they enjoy. They would rather quit the project than to deal with that. What kind of resources is Linux Foundation OpenSSF providing to those developers? So it kind of shares some burden from them and also create some kind of garrison blueprint or you can just support system so that they don’t have to worry too much about, oh, I may get sued.
Christopher “CRob” Robinson: We have a couple different things that are relevant in this case. And you’re absolutely right. Software engineers didn’t get into writing software because they wanted to do security or follow laws. They do it because they are creative, they’re trying to solve a problem. And where we’ve targeted our work is we kind of think about the different Personas. So for manufacturers we have a class for all Personas, everybody in the supply chain, we have a class that you should take that teaches you, kind of based on your role, what you need to think about and prepare for. Then we have, for developers, we have a guide on for an open source developer. These are the things you can do to make your project more CRA compatible. So if for example, you publish a security policy or you provide a software bill of materials, the theory is you’re going to get less questions from downstream. So the developers, we have a lot of kind of education, training things to help help them understand what they’re going to get asked from the manufacturer level. We have a ton of work. Again, that class is a great go to thing where we lay out, these are all your obligations, these are the things you need to do, the programs and evidence you have to have in place. And then we have a couple working groups where we’re working on tools. All right, so you need to fulfill this requirement. Well, we have software or guidance to help you as a manufacturer execute on that. And then as a consumer, whether you are like an enterprise, like a bank or a hospital, or you’re a government regulator, we have a checklist that basically state if a project follows these behaviors and provides this evidence, this is something that is more compatible for you to use, you have less work to do in securing it. They have a policy, they have a contribution process, they have their software repository locked down. They are doing things that you would expect as part of an enterprise. And if this, if those manufacturers want to do right by their upstream creators, those sources that they’re leveraging, they could take that checklist and go upstream and donate those things. Hey, I see you need some help securing your GitHub repository. I can help you do that. I have an engineer. We’ll be glad to help configure it. Oh, you don’t, you don’t provide a software bill of materials. Can I donate the time and effort and help you get that set up in your CI system so that you know, you could provide that? And that makes my job easier. It makes the regulator’s job easier. So there’s a list of behaviors that the manufacturers can go do and provide upstream and as they do that, hopefully they’re, they’re building a relationship so it becomes a long term collaboration between they and the upstream creators.
Swapnil Bhartiya: Now but a lot of open source developers will say hey, probe is saying that I am not on the hook. The company who distributed is on the hook. So I have nothing to, I will deal with the company. But what if somebody in Europe downloaded your software using your software? There is no contract, but you know it’s open source. They went to the GitHub, they downloaded software to their vulnerability.
Christopher “CRob” Robinson: Now who is on the hook for the maintainer? There is no legal or regulatory risk for them. It becomes a reputation risk like oh, somebody goes on the Internet and disparages your product, I had a bad experience with this. Or every manufacturer that copied your software that now they are being fined and yelled at by the union, they’re going to start harassing you, hey, when’s the fix coming? Gimme, gimme, gimme, gimme, gimme.
Swapnil Bhartiya: So the basic idea is that you talked about last time also just do the right thing. Follow some of the best practices resources are there through Linux Foundation. Now is it easier for those organizations, those companies who are part of Linux foundation because they know how the process work, they get a lot of sources versus those who are not part of Linux foundation, they are not members, they are not in some cases aware of it. So is it better to get involved even if you’re not contributing code, but at least get involved because not every membership is paid. You can become a member. So if you are touching any source of you should work with a foundation.
Christopher “CRob” Robinson: I agree. And that’s where the role of the open source software steward comes into play. And broadly that is nonprofits and foundations like the lf, like Apache, Eclipse, there’s a bunch of us. And the benefit of coming into a foundation is you get access to more resources. CICD infrastructure, you get help with vulnerability reporting, you get a lot of assets that an unaffiliated project might not have access to. And that’s where as a manufacturer and consumer I strongly advocate for responsible consumption. If you’re using something, get involved, understand how that project works, understand how you might be able to contribute and help them. And maybe a good move is to encourage them to move into a foundation that they have marketing and legal protections or figure out a way to help support that unaffiliated maintainer. But that’s last year GitHub stated that there were over 630 million projects within their ecosystem, which is the majority of open source software. Not every One of the 630 million projects is intended for commercial use. Some of them are, some of them have been drug in by accident. But a small portion of those are actually used in a commercial situation. And that’s where, you know, consume software responsibly. And just because some software exists, it might be a student project, it might be abandoned. The maintainer might explicitly said I’m never going to update this. Well, if they said that, don’t ever put that into something you’re selling, write it yourself or find an alternative.
Swapnil Bhartiya: And there are a lot of code which is written, it’s solid purpose, there’s no bug, nothing. And the Last update was 2018. You know, it is working. I use a lot of code base sometime I of freak but you know, you don’t find any alternative. But I mean a lot of companies, they started doing the Open Source Program Office which kind of become. But then we also saw a lot more. They’re shutting down those, they are laying off those program offices. What is your advice to CTOs? Because I think it’s. It’s virtually impossible to say that you’re not using any open source code, but you are using it. So that there is some kind of bridge, even if you cannot afford to have a dedicated open source Program Office. But you should have some kind of bridge, some relationship with some of these foundations. So what would be your advice to a cto?
Christopher “CRob” Robinson: There’s two things the CTO needs to do immediately. They need to either generate or acquire software bills of material for every component they have. Take an inventory of what exists and absolutely know without a shadow of a doubt what you are selling. Then secondarily, you need to start making choices and due diligence. Not every project was built to the same standards and specifications. Pick some type of framework like we have the Open Source project security baseline. There are many other ways to evaluate software. Pick a methodology and start to go through and validate what’s in the SBoM and does it meet your requirements and will it fulfill your customer expectations and your legal and regulatory obligations? Those are the first two steps a CTO should take right now. It should have started a while ago because that’s not a small job.
Swapnil Bhartiya: I think now I got everything that I wanted to ask and thank you for taking some additional question because I did feel that a lot of developers, maintainer, either they are worried or they are not worried. So I wanted to, because this is something, every time we talk about something new comes up and I want to make sure that we try to cover atmosphere. So do you think we have covered everything? Are you happy?
Christopher “CRob” Robinson: I don’t think so.
Swapnil Bhartiya: Anything else?
Christopher “CRob” Robinson: I have one more thing I can mention. One of the capabilities we have at the LF is we have a dedicated research team and we actually have a chief economist of all things. It’s crazy. And they did a report last year and what they found out is that broadly the manufacturers and vendors, about 51% of them passively rely and expect that upstream is just going to fix things. So that’s the one scary stat. Because upstream doesn’t work for you. They’re not thinking about you and your problems. They’ve got their own set of challenges to work through. So if you’re waiting for someone to do your work for you, you’re going to have a really bad day when the CRA comes online. And then secondarily. Another tactic we’ve seen proposed is using private forks. And our economist did some data analysis and I can’t recall what the number of hours was, but I absolutely remember the estimated cost. So if you’re running a private fork, the estimate is you are spending about $250,000 per release to manage that private fork. And you probably don’t have one fork, you probably have dozens. So again that all exponentially grows. So don’t wait for someone else to fix your problem. Become an active participant in the process and think about. And if you need, if you’re a CTO and you need to justify budget or headcount, think about those figures to help justify this. We’re avoiding this business cost by participating upstream or donating time or sponsoring or joining a foundation. These are types of things that help you reduce your risk.
Swapnil Bhartiya: Yeah, I talked to Frank and of course Hillary. So we talked about that. And one thing more I would like to add. When you said that those upstreams are not working for you, I think it’s not. In addition to that upstream they do want to help. They’re not even aware of your use case.
Christopher “CRob” Robinson: Right.
Swapnil Bhartiya: You know, so if Linux doesn’t even know what your use case is, though he does try to make sure that you know your, you know, that never breaks. But if he’s not aware of it how he’s going to ensure that he’s not fixed. Because they do want to help. I mean these are open source community. They are doing a lot of things, you know, for selfless reason, you know, so they are willing to help as many people but if they don’t even know what you how would they know when you get involved?
Christopher “CRob” Robinson: And that’s really. I get to talk with Greg KH a lot these days and he’s always astounded by the novel ways someone has taken the kernel and they, you know, shoved it in a talking teddy bear or a satellite or a submarine and it’s like you’re absolutely right, Upstream does not understand how you’re using their software and you know, they will document we’re trying to solve this problem or here are advised use cases. But so if you have different use cases that’s again getting involved in that community. You can help submit test cases to the project. Hey, can you think about and test these things or have you considered this perspective or this usage and get involved. You’re going to get better results and outcomes because you’re absolutely right, these developers do care. It’s a lot about pride and reputation. They want to the software is their resume and their body of work and they want it to be seeing how
Swapnil Bhartiya: you’re using that, you know, so they actually sometimes they’ll talk about and look at that, how there is and they would like to support that. And second thing, you also mentioned about private forks. Why would you do that? You know why you’re taking open source which is given to you for free and you’re adding a lot of what you call it debt, technical debt for no reason because when the next version will come out, you will not be able to downstream it because your own fork has gone so far.
Christopher “CRob” Robinson: It becomes very technically complex.
Swapnil Bhartiya: Spending more money globe. Once again, thank you so much for joining me and it’s always pleasure to talk to you. You make security topics so entertaining and so enjoyable and I am just surprised that why companies don’t do that. But also at the same time they are doing a lot of good. So so the things are getting better. We’ll see next year. But you know, once again I appreciate Andrew, thank you.
Christopher “CRob” Robinson: You’re very welcome. Thank you for.





