About this talk
In this presentation, Roman from Red Hat discusses the complexities of the Cyber Resilience Act (CRA) and its implications for open source software stewardship. He explains how the CRA aims to address supply chain security by introducing roles for manufacturers and open source stewards. Roman outlines Red Hat's approach to stewardship, emphasizing the importance of collaboration with open source projects to navigate obligations and enhance security practices. The talk highlights the need for clear communication of stewardship principles, developing tailored plans for different projects, and establishing a framework to meet CRA requirements. Ultimately, the session showcases Red Hat's commitment to supporting the open source ecosystem and fostering trust among various stakeholders.
Full transcript
[music] >> Uh good afternoon. Um so happy to be here um and we have the cozy company which is even even better. My name is Roman. I work for Red Hat. Uh but also I'm engaged in this lovely effort that we all call the CRA. Um I'm engaged in the standardization efforts and also in the multiple open source communities that try to navigate uh those uh complexities.
Today, uh we're going to discuss the stewardship part and our journey, how Red Hat approaches it and maybe all of you can get some uh inspirations afterwards. And of course, the CRA is so complex and please don't take it as a legal advice by any means. Um and yes, some of the images are generated by AI, of course, during this presentation. Let's get straight into this. How
many of you have seen this picture and love it? >> [gasps] >> Okay, that's our favorite one, right? Uh so this is the intention of the CRA, right? To fix all these supply chain issues as a supply chain bugs. Uh now, how it's intended to work in the nutshell, manufacturers provides their PDDs, product digital elements to customers and consumers. But uh manufacturers are all dependent on the
third parties including open source projects. But uh the reality is that the uh open source projects is not the one thing. There are many open source projects out there. Uh and all of these open source projects needs to keep up with updates, with fixes, with vulnerability fixes and etc. And therefore, uh CRA recognized the special role of the open source software steward who is meant to be
helping or uh sitting to some extent in between of the manufacturers and open source projects. Uh now, the manufacturers are supposed to support uh stewards or open source projects directly. Um probably with the fixes, maybe with the engineering resources, maybe with the money, etc. etc. everybody's happy because everybody supports each other and we have fixes ready, we have secure products ultimately delivered to users, to customers, to
businesses, to EU citizens and worldwide. Uh now, the question would be, you know, yes, we are here for collaboration, which is good, which is uh you know, the the beauty of the humanity. We all work together. Um Now, let's take a closer closer look um from each of these actors' perspective to understand, you know, the gaps and then how we can potentially fulfill these gaps. This picture
is great, but um you know, the what for actually manufacturers should necessarily support open source projects? Right? What value they are getting back? Because manufacturers have their own thing in their mind. Right? And what's in mind for manufacturers? Obligations, right? They need to fulfill obligations because once the CRA is in full force after December 2027, you will not be able to uh place or continue to uh
produce your products on the on the market, right? You need to fulfill these obligations. And there are a lot. You can see the glass is full of obligations here in the picture. Right? And they're asking a lot of questions. Uh some of these questions are easy. Okay, disclaimer, none of them are really easy. But some of them are really tricky. Uh for example, if I make a
mistake or a security flaw is found in my project, will will I get in trouble? You know, who is responsible for actual fixes? Is it the open source project or steward or somebody else on the supply chain who I can chase? Am I considered as a manufacturer, for example, if I fund an open source project that is not under my responsibility? A very good question. If you
remember this picture with the relationships and question marks. Right? Even if we as a manufacturer want to support open source projects, what's in it for us, right? And then what are the the the the consequences? If I help a project, what guarantee do I get for my own conformity assessment? The perfect perfect question. We kind of approach this uh question the answer to this questions from multiple
angles uh with the attestation and due diligence work. What is due diligence anyway, right? What does it means? Um all of these questions and many more are actually asked and a lot of them are already answered at the beautiful uh cra.rc. um wg.org /faq website. You can follow the link. um scan the QR QR code and find the more uh questions and more important answers for you
as a manufacturer because you're not alone. Everybody actually asks this Questions. Now, um CRA obligations for maintainers. What's in mind for maintainers? How many obligations do maintainers have? Any guesses? 50? Okay. 150? Any other guesses? Five. Zero. Exactly. If they don't maintain uh maintain their projects, they have no obligations, but right? We wouldn't be here if it were like that's that that's that's bright. So, no obligations
for for maintainers, but they are also kind of uh scratching their head and asking the questions, am I subject to the CRA if I earn a living from the open source project I maintain? Um most likely no, but uh this is a good question. Uh and you know, it's largely debated uh on the on the new draft draft draft guidance and we don't still have the clear
100% crystal clear answer to what extent they can, you know, earn this money for their living. Can a solo maintainer be considered as an open source software steward? Again, the good question. Probably no, but um guidance is still in draft mode. Does the uh popularity of my open source project expose me to CRA regulations or to a steward? How can I clear communicate that I'm not subject
to the C CRA to downstream users if I wish so? Right? How to m- how I'm going to m- make them know that, you know, like like don't don't uh you know, don't treat me as as uh your supplier. What additional obligations would I have if I had a steward, right? Maybe it's a good idea for me as a maintainer to kind of seek for a steward
or to accept the stewardship offer from uh somebody, but uh what's in it for me and what are consequences? Again, all these questions are asked and some of them answered at the FAQ work, which is brilliant um resource. Finally, stewards. Coming to our main topic about stewards. Uh the stewards, they have just a few obligations and those so-called light touch regime, but um the word is still
in here. Uh what's about the ENISA S- SRP this thing, for example, for stewards, right? You know, they they they need to figure it out along with the manufacturers. So, that's why the kind of glass is not entirely full, but not entirely empty here. Uh some of other questions that they uh ask, who can be an open source software steward in general? Can you be a steward
for your own codebase or only someone else's? Will open source steward be expected to provide an SBOM? Like very direct and clear question. You know, the answer is tricky, right? Prob- probably no, but again, uh is it possible for project to have multiple stewards? Super debatable question. Uh can I opt in or opt out from being a steward? And a tons of other questions. Again, uh on
the F- on the FAQ. So, this is kind of the setting the stage to to highlight that this picture is good, but we have all of these question marks that you can see on the on the slides. This system is supposed to work, but all of the actors on this slide, they ask their questions and the most important point that they ask all different questions from their
different perspective and they have their own goals in minds, which is need to be tackled somehow. How? On the previous Eclipse event, we highlighted our Red Hat's approach to the CRA in general. I'm not going to repeat this. Just a uh quick recap uh in 1 minute, why Red Hat cares and why we're talking about this CRA at all. Uh for uh certain reasons. First of all,
we are a manufacturer because we are provider of enterprise open source software that we sell globally, but of course, on the EU market as well. Um probably you are familiar with some of our products. Um we are uh potential open source software steward and most likely we'll be a steward uh because we have a rel- special relationships with open source software and this is foundation all our
work. And we support countless the projects including some of the most important and quite famous one. And also Red Hatters are contributors and maintainers where everyday provide the contributions that's actually thousands of Red Hatters contribute to open source. So we're kind of embedded in this ecosystem and that's why we are affected kind of from the multiple angles. And therefore we decided we would like to actually navigate
it nicely and would like to continue providing our support to projects but also to ecosystem and to everybody else by jumping onto the and working together within the open source communities like Eclipse Foundation, Linux Foundation and others and also standardization bodies to make sure we can advise and help their overall ecosystem to crack this nut. going down to the stewardship. We decided that we are going to
take the stewardship very serious seriously for us and we outlined this five-step approach to trusted stewardship and that approach is kind of step-by-step because again remember the picture and all of the questions that everybody is asking is not quite clear you know what we are going to do right? That's why we decided okay first we're going to align on Ceria roles and definitions. Of course between within
the company but also together with the communities that we work with. Then forge and clearly communicate our stewardship principles so that we kind of sign sign off under them and they're clearly communicated. Identify the projects that's you know most likely we're going to be stewarding and communicate this to them. Then define the scope for each project. I will be talking about this. And finally tailor implementation guide.
Right? So those are five five steps. Let's try to dive in in each of them step-by-step and probably highlight some of the practices pitfalls and recommendations that we came up with following these processes. First of all um we are proud and of course you know we we we are very much providing sustained support to the open source projects and moreover we are committed to do so we
are committed to continue to do so. And therefore stewardship is not really a choice. Yes we have the definition we have the legal definition under Ceria what it means to be a steward for projects intended for commercial use but in the nutshell you know you you you can't like opt in overnight or opt out overnight because if you provide some sort of support and on the slides
kind of examples of this support that is listed in the Ceria text itself a little bit in the FAQ and in the draft all the links to these materials are on the bottom on the slide but you can easily Google them released by EU Commission. Technical support for example hosting code and platforms governing and steering development contributing engineering resources or it could be non-technical support for projects
that we also provide for some of them like managing brands helping organizing events laying down governance rules providing IT infrastructure. So sustained support means legal stewardship obligations. about it. And again that needs to be clear understood and clarified. Now to the principles those are um they call seven principles of our stewardship that we think are instrumental as we work with open source projects and I personally think
that all all stewards should kind of take the similar approach. First of all listen first act act second we recognize that all communities are such a diverse community and open source projects there is no there are no kind of equal open source projects so we need to learn how what are the community practices for each of them and what the governance structure is and you know then
come up with a plan and then come up with a help but not vice vice versa so we listen first and then act upon the information that we get and learnings that's that's we got. Security first we wanted to prioritize security hygiene over the box checking exercise. Yes we need to fulfill some certain obligations but the improving security should be the end goal and that is how
we approach our own Pragmatic and devcentric requirements might must make technical sense. I don't particularly like the word requirements when it comes to open because you know they have maintainers have no obligations right and we wanted to make sure that all of the best practices that we suggest or implement with the projects are kind of make sense and technical and you know aligns with the best practices
and more importantly with the practices that those projects um are following. Minimal disruption efforts must be workflow native ideally integrating seamlessly and iteration also the key right we don't want to to to disrupt the normal kind of operations of the of the projects. This is key for success otherwise we are going to be failing 100%. Gap filling support we provide resources only when necessary again if there
are good tools good processes already in communities and we witness that some of our communities are doing super fantastic and that just works right? Why we need to change anything no point. And diversity and tailored fit I mentioned this briefly no one size fits all they are all very diverse and opinionated and we and you know they unified kind of mandate is is not working. And lastly
the champion steward um for some of the projects some of the big and important and famous project we decided to go beyond the minimal legal because we wanted to promote quality and security practices because we recognized that the overall ecosystem kind of research and look to these big projects what's what's they do so that we want to those projects to be inspirational for others. how we decided
or you know not decided but identified projects for this stewardship. That's that's a good question I mentioned before like sustained support is a main identification but when you dive dive in you probably need to ask more precise questions and that's what we did. For example is the project a product digital element at all by the definition right because you know something like documentation for example or or
research projects or the conference something is you know not a PDE and there's no point to to this project is necessarily to do anything. Engineering resources do we contribute engineering resources to the projects to ensure viability. Like the the the good question and they one of the most important question. Do we provide the majority typically more than the half of the project governance to the project? If
not right it's like questionable. Commercial association is there any commercial products associated somehow with the project or do we know if this project is used with by the downstreams largely in commercial activity. Again the good question to assess. Do we host the project development or collaboration platforms? Are we managing branding for example? All all all of these questions we asked to hundreds and hundreds of projects that
we assessed then to you know to be identified for the potential scope of And the final question is actually very important. Is there a better potential stewards? During this exercise we realized that you know some projects would like they probably would have better potential stewards or they do have already the steward but Red Hat is not involved and then we decided to work with those stewards to
make sure you know they understand and what they think about it and etc. So and again this is this is our approach just because we involved in thousands of open source projects and their development we of course realistically can't and shouldn't be steward for everything but we just took an extra effort to to to make sure we scoping this right. And again this is all for the
help for the ecosystem and for the for the projects. Partnership is critical. I'm moving on to the next step how to communicate these things and how to start working with the project. This is the actual screenshot we do it publicly, so we communicated our kind of stewardship intention in this case to Fedora project and actually there were kind of conversation around it, right? We had a several
meeting, but we also had a public conversation on the on the on the forge about it, right? And this is just brilliant because we want to learn, we want to hear from ecosystem, from the project itself, from maintainers, from from contributors what they think, what they think would be the better approach, how to do it. Like the CRA is with us for quite some time. Probably for
forever, right? But it's kind of understood by the majority of people, but how we're going to approach this is is the thing that we can change and we can actually must shape and that's why we kicked off these open conversations instead of saying, "Hey, this is a mandate, you know, do this, this and that." The same thing we've done with Ansible, for example, also Red Hat supported
project, like, "Hey, you know, this is this is what we're going to do. This is the basics of the C CRA. This is our plan. What do you think about it? What's your feedback? How to best work and collaborate together to achieve the common goal?" So, I think this kind of approach and partnership is really critical in order to move forward because again, they're all diverse, they're
all communities in itself. We we want to make sure they're onboarded and we do all the things reasonably. so, given this framework and those kind of preparation steps and everything, we we came up with a certain list of projects that um we most likely will be steward for and we are proud to be a steward for. We would really love to continue support on their journey and
you can who knows Fedora? Right? And who knows Ansible as well? So, some of the we are proud to be steward for some of the well-known and widely used open source projects that's everything is running on, right? So, this is like um this is quite obviously the serious thing, but also this is um kind of responsibility for for the uh overall ecosystem and for society, if you
will. So, um our kind of road maps and whatever we come up with there would be the search plan for this project, of course, dependent on our involvements on those. Previously, I mentioned all of these questions that we asked, right? And based on that, we identified like the two simple kind of chunk of support that we provide to the projects and we call modifiers, development modifier if
we develop actual code, if we invest our engineering resources quite heavily to this project and hosting modifier when we provide the underlying Of course, that's mix and match of these supports for some of the for some of the projects, but for some of them is just one of the two. Right? But in all of these cases, it's counted as a sustained support and again, we would like
to make sure that this sustained support is continued. Go. Um and if as I mentioned, this is all kind of the the all all complex around the CRA and our commitment is to consistently evaluate open source projects and make sure we steward in the right ones, right? And that could be changed in the future, but the are usual suspects that we all kind of raised our our
hands up. Quite obviously, we are going to support them moving forward and will be proud uh to be a steward for those projects. So, that's that's our selection process, that's our approach, that's how we did it. Now, the next question would be, okay, let's dive in into the certain projects and I will bring only one example, but you probably can get an idea. It is the halfway
or part of the job to identify, okay, this is like Fedora, Ansible or whatever, like big project we are we are stewarding for, but this is actually the screenshot of Fedora project kind of chart. Uh this names are organizational chart, but this give you gives you an an idea about the diverse ecosystem of Fedora project, right? There are a lot of the a lot of the repositories,
a lot of the different pieces that are connected to Fedora project and that are united uh by the kind of common Fedora project governance and etc. etc. So, that's just a lot and this is of course the kind of small representation, the small picture. So, that's a lot. Right? Um how do you want to go about this, right? Um and we decided we need to actually take
care of what matters most and what makes sense to care of um asking the following questions and you know, questioning what's what should be in in scope. Quite obviously, the uh source code development platforms, hosting platforms, systems, infrastructure. all of these things should be in scope some of them are already mentioned in the CRA itself and in the commission draft guidance kind of clarifying what's, you know,
should be or could be uh those things that would be Um out of scope, for example, unfinished code, samples, demos, unfinished software, periodic documentation or abandoned repos that are no longer maintained and probably archived, probably not, but they're no longer maintained and there are no >> [snorts] >> uh the the there is there is no kind of there is no association with a product or or something.
So, that's those would be probably out of scope. now going down to the interesting things guidelines. So, we again, I I don't particularly like the words requirements or obligations or something like that when it comes to open source project because, you know what? Maintainers uh don't owe they they owe nothing, right? So, the Um and we thought a lot about the guidelines and we came up with
the two things. First that we call our lighter basic to satisfy [snorts] the stewardship obligations for Red Hat as a steward. Right? And that largely goes down to these three things. Uh they are written in the CRA text itself. We don't have that much other clarification what that means, so we kind of stick with the uh with the what we read in the in the law, security
policy, vulnerability management process that uh should be accompanied by ability to report actively exploited vulnerabilities and incident response pro- process that should go hand-in-hand with ability to report severe incidents local C C source and ENISA. There is also a cooperation thing, of course, but this is not necessarily like what what projects need to do. We of course fully committed to cooperate with authorities here and there, but
those three things we identified as the three major errors that we will work with each of the projects um to improve security posture, but also to help to satisfy Now, that's that's not really a lot and you can ask the question, you know, you talked about the good security practices. Here we go. Um the next bucket of the guidelines or recommendations would be uh that we call
the champion uh stewardship and we want it to be the champion steward for the certain Um we wish we we can implement all of these processes for all of the projects, right? But at least for those that are very well known and critical and etc. Uh SBOMs. I mentioned SBOMs and somebody raised their hands like, "No, this is not a requirement." But uh we think that SBOMs
would be quite instrumental for the ability to report vulnerabilities, especially at scale. Right? So, that's why it's on the first place for the champion requirements or the best practices and we'll try to make sure that this piece exists, you know, and we we kind of help to create this for all the projects. Uh now security self-assessments, which the machine-readable format, machine-readable spec. I will have an example
later on uh to actually uh express what security practices open source project implements. Uh contributing guidance, um quite, you know, important. It could contain security part, but it also kind kind of importance to um um order to say how you make development, how what's what's your life cycle and etc. etc. Release [snorts] documentation is very important. Defect reporting guide, um MFA multi-factor authentication branch protection license files.
Not all of the projects out there have license files so far, which is kind of fascinating to see, but it is very important we think. Also, we think that for the when it comes to the best security practices, the well-established framework at the moment, for example, Salsa, which stands for secure layers for software artifacts. It is It is It was for the builds initially, but then then
it's uh was extended to the source as well, but for the builds itself, we wanted to have these Salsa attestations done. Uh signing commits will be a good practice as well, which we're already implementing and rolling out across some OpenSSF open source project security baseline. I would like to make a caveat here uh and I heard these questions quite frequently. Kind of having your baseline controls implemented
at any level doesn't mean that you're compliant with the CRA {quote} {unquote}, but it is just a good that complements at least the spirit of the CRA and most likely as you implement all of those, uh your kind of security posture will be in line with the CRA and will significantly help to fulfill any requirements. Not equal to be sure you kind of get all of them,
but the excellent security practices. Uh and OpenSSF best practices badge, that's also a nice thing to have. This is basically the justification that the projects kind of self-attested to the certain controls and it has the nice GitHub badge that you can put to the to the repo for instance. So, this is not the full list, but I think the majority of the practices that we would like
to see from actually any open source projects to be implemented. Uh now we work with each project to create a tailored CRA readiness roadmap, which is quite important because I mentioned to you all the projects are different. They all um not all of them, but um they somehow use the different tools. The different source control systems, different build systems, different whatever, right? And you know, it's it's
it's impossible to say do this this and that and this is the tool set. That could be slightly different for all of them. So, we are implementing the tailored CRA readiness roadmap. Therefore, again, you know, this we are not insisting on, you know, take this tool, take this, take take take take that. And this is kind of unlike some other stewards do things, especially the foundations that
they run projects, some of them have their ecosystem established and their tool set established uniformly for all of the project and they kind of can get this, all of our projects, they have slightly different tool set, right? And that's why we just don't have this simple table, you know, use this tool, use that tool. That's kind of uh that took some time for us actually to learn
to communicate and to work on with the each individual And finally, for the timeline, probably you are wondering, you know, how what the timeline is for uh for this. We decided to align timeline with the obligations for manufacturers, right? It is for reporting parts and then it is the full compliance. We of course aim to fulfill everything as soon as possible, but at least uh to align
with the manufacturers obligations. Um now implementing or or kind of communicating the CRA readiness, again, they there is there's still unclear how and, you know, whether to communicate your CRA readiness posture and of course the attestation work that is happening, for instance, and due diligence work that's happening under Eclipse or C working group, which I'm very proud to be part of. kind of will probably clarify the
different specs and, you know, the white papers and the standards how to do this, but simply the checklist would be enough as a starting points, right? It's just a simple markdown checklist, you know, I done this this Uh to be a little bit advanced using the um tools that exist right now, again, I mentioned we are working on the, you know, the different ways and different recommendations
how to do it for uh already now um under OpenSSF security insights specifications specification um in the form of YAML file that you can actually document some of the things in it in machine readable format. Right? So, that could be kind of advanced machine readable format, but I I think that would be kind of essential uh in our upcoming uh agentic AI world, right? So, that we
can empower some of the agents to pick up the information in machine readable format as well. Not to talk about automation that's already exist in place for uh many of the companies. So, this is kind of how to simply document that you have done actually the good things in alignment with the CRA. It's super important to know that those best practices don't transfer CRA responsibility. it's it's
it's crucial and it's fascinating how many questions I personally receive from that regards from either open source projects or users or manufacturers out there. Therefore, um it is kind of recommended to also put some of the disclaimer to your to your repo if you're a maintainer. Uh that's, you know, this this is the voluntary thing that the project decides to do and if you have any questions,
you can, you know, either either find our stewards if it exists or just go away, right? But we owe nothing to you. And this uh disclaimer and some of the other guy um tips and tricks for maintainers, you can find at just recently published, I think it was yesterday, uh kind of uh release announcement at the stage. maintainers guideline uh at the um OpenSSF.org uh website, so
you can find the um not that big uh I think few pages document what the voluntary security practices make sense to implement, right? So, uh check it out if you will. Um now, obligations for maintainers. Right. Non-legally, but practically, friction is real, right? As we all understand, friction is real uh the maintainers, uh how many of us maintainers in the room? Okay, I have a few. Very
very good. Uh at least probably you have heard, if not received directly, some of the questions by like strangers on the internet, right? Are you CRA compliant? Or as part of our audit, here is the issues we found in your open source project. We give you 1 month to fix or to respond. Or, you know, I'm going to I I wanted to be open source steward. So,
that these kind of requests for open source projects questioning compliance posture recommendations are collaborate. Consider this an opportunity, you know, if there is something that they can that you think they can help you, express it. Uh maintain autonomy if you wish. Uh none of the open source projects have to have a steward, right? So, I mean, there's no obligations for maintainers have a steward. And make a
gentle response. Again, the good recommendation how to do it is on um or C working group org FAQ, right? How to communicate I'm not your supplier. I have no obligations. Provide the gentle response. I mean, don't be overreactive. It is like it is what it is and don't sign don't sign anything as a maintainer, right? Don't sign any declarations and etc. Uh it's kind of obvious, but
still make sure you you don't, you know, uh get yourself in the trouble unnecessary. what I just described and generally what we do here in Red Hat and what we do as a community, we do is in upstream, right? And all of those things that I told you during my presentation are not uh coming out of the blue. Uh we um have been working together with a
different communities uh work working group and of course we contributed and then been inspired back by the open source uh software stewardship white paper that you can access by this link. Also, we worked within the OpenSSF under Linux Foundation to on the stewards play playbook, which also has some of the good recommendations that then we applied to our stewardship approach. And yeah, that is that is our
approach. I can try to promise you that we're going to publish uh what we have done as a paper publicly for uh everybody like a document, but now you can read the the blog uh how we in general approach the stewardship, but hopefully uh later on in the year we'll be releasing the whole document, the whole, you know, guidance, how we kind of communicate it to the
projects and uh what we've done and uh I've just described to you. Righty, and lessons learned. Uh and I would say so far because we are just at the start of the journey, right? It's like really not clear, uh but um pitfalls, lessons, what we've learned. First of all, uh most people don't understand the C- CRA. I started my presentation with like the majority of us have
heard about this, and all of our maintainers that we communicated with kind of heard about the CRA, but nobody understand what that means exactly. Be patient, be simple, be mindful to people. We need to explain, we need to work together, we need to listen, and then just feedback because our mutual understanding, not only ours as a steward, actually shape uh the further approach. Uh respecting each community
practices is the only way to sustainable success. I've been talking about that quite extensively. Each community is diverse, and we need to uh accept their uh processes, their practices, and work out of this, not invent uh the real estate hey, now we do this, this, this, and and that's like out of Uh maintaining uh man- mandating security controls without community buy-in backfires, right? That's why we've done
this communication, that's why we try to work proactively. Um there will be more than one styles and types of stewardship. We figured out that we're different from the foundation, for example, how to approach all of these things. and yes, legal obligations can't be transferred to projects themselves. Kind of obvious, but um it should be clearly stated or clearly communicated. This is kind of lessons learned again, some
of the some of the things. Um and finally, there are many unknowns, right? To put gay water, iterate. So, this is um this is what we need to do uh to in order to be successful. Now, remember this picture and all of these people that's supposed to be happy, right? And all of these question And our answer to this is how to do it. The trust is
key for success. That's the main takeaway that we found uh along our stewardship way, actually. Uh trust is priceless, and it's super hard to to earn, but we need to do it, and then we need to make sure that we will not lose it. Join community collaboration to continue building trust. Thanks very much. >> [applause] >> Thank you, Roman. We have time for one if any. It
looks like people is hungry and thirsty, and we have the break now. What I'm wondering is about patching in the CRA. There is some words about patching from the project source to the final application. First question here is as Red Hat, do you recompile or do you compile all those projects that are part of your applications? Uh when you do that, I see it's easy to patch,
and the second question here patching and building the task of the steward or the task of the manufacturer? I see you both are Red Hat, but is it under the head of steward or under the head of manufacturer? Yeah, the perfect question, and they kind of connected all of these two questions. First question, we need to distinguish uh between the manufacturer and the steward, right? We have
the commercial products that we, you know, put on the market, and for those, there is a different process that is that was not subject of this presentation. Of course, we're going to be fulfilling the uh manufacturer uh for for those products, including patching and everything, right? That's for the product. For the open source projects that are not commercial products and that are kind of purely community maintained,
that would be the uh responsibility uh at the end of the day of the maintainers to do this, but the um the uh beauty of the stewards and the expectation of the stewards that they're going to be facilitate these thing. Uh I see nothing bad if the engineers from the big companies like Red Hat, Microsoft, Google, and other companies of the world like kind of go ahead
and these patches and this work to the open source projects them- themselves. But then, those fixes will be incorporated into the source and and will be packaged by the open source project itself, not by Red Hat, right? So, that's for Fedora, for example. And how do you verify an SBOM, for example, that the the binary contents really are built out of this one Git commit ID? That
are is is stored to be be um part uh be part in the binary. Don't you recompile everything? >> [sighs and gasps] >> That is uh that I think that depends on the on the on the project, right? And uh within Fedora, for example, we kind of package uh everything on Fedora side, right? And there are, as you know, many types of SBOMs, and we with the
open source projects, as a Red Hat as a company, we publish all the SBOMs, all the built SBOMs to be precise publicly, you can find them on our website. Uh for the open source projects, we're still navigating how to do it better, especially for these large enormous projects like uh Fedora, and how to uh those dots. As a manufacturer, we do our you know, our own things
for years, I think, already. For these open source projects, it's still yet to be navigated. Maybe the right password here are reproducible builds. So, if you if you implement reproducible builds, it's easier to follow up if the SBOM is actually for that for that artifact. Yeah, exactly, and we think about this as well along with other distributions and uh in the com- community, but I can't commit
to it right now, but uh this this is one of the approach that we are we are looking into. Thanks, good questions.
