CRA, NIS2, DORA: What senior Java engineers must deliver before 2027

This talk addresses the implications of the Cyber Resilience Act (CIA) and other EU regulations that affect the software industry directly. The speakers, seasoned developers with extensive backgrounds in open source and software engineering, emphasize the significance of compliance with these regulations by the December 2027 deadline. They highlight the substantial financial penalties and other motivations for adherence, including the requirements for secure software design, vulnerability handling, and proper documentation. The discussion also covers the role of software bills of materials (SBOMs) and the use of frameworks that assist developers in meeting the new compliance standards. By emphasizing the growing need for security and transparency in software, the speakers argue for a shift in industry practices to align with regulatory expectations, aiming for enhanced cybersecurity and consumer trust.

[music] Hello everyone. Welcome to our talk about the CIA and not only the CIA but also other regulations that that the EU has put into place and um what all those abbreviations mean. They are of course a beautiful uh artifact of or of of buzzwords and everything and uh we will give you a good overview how it affect us and what we must do to deliver by

the deadline or the efficient date for the CIA and let you learn a little bit about the other regulations as well. Before we continue like who is here surprised by any of the words like CRA we know we are here for that but for NIS2 okay I have two three hands Dora who has already been living the Dora dream and I'm not talking about the cartoon yes

okay two hands here so another thing that appeared it was of course the definition of of the sublet letter but also this is a developer session for developers like we are both developers. So why are we here Marcus apart from the 2027? >> Yeah to give some motivation actually there are some financial penalties and economic risks attached to it because legislation without threat are not take serious

for the players on the market. So the regulators have decided to put in serious fines if people do not comply to what's requested by the regulations and you see here for the CIA um fine up to 50 millions or 2.5% of the global annual turnover >> but for that's for the high tier but in in any case it's going to be expensive in more ways than one.

>> Yeah. And you will learn in a minute that it's even not only money there are there's more attached to it. So people should really be motivated to take care for these topics and um yeah besides that besides being forced by these fees there are also other pos motivations. We will get to a point but who's talking to you? Um my name is Marcus Ling. I'm a

software engineer and now a co-founder and nowadays CEO of Carakun. Um I'm also uh present at conferences. Uh I really like the community. Um, yeah, that's uh my background. And who are >> Okay, so my name is Ishel Ree, like Michelle without the M. And I'm from Mexico, living in Switzerland. That's the accent that you're hearing. Uh, I'm a Java champion, an Oracle Ace uh pro, a

test container developer champion. I work a lot on open source. I'm also part of OASP and I was also part of the CDF foundation. And on top of that, I'm a consultant. So ideal and I'm happy to help my customers uh solve problems every single day. But the point is that we saw each other at the beginning. I am a developer. So this is what developers should

be worrying about in 2027 11 of December 2027. Another important thing that I always like to highlight about my company uh we both work for Caracon and we have been uh behind open source for a very very long time. We have a program called the hacker garden. Go to hacker garden net. If you like the idea please please start start your own chapter in your own city.

As you can see we have been running for 17 years. We have done for 4 460 plus events. This is an old update because I did the update at the JCP EC uh board. I'm part I'm also didn't mention before I'm part of the JCP board member. I'm the associated uh seat. I was both in last November. So, hey, so we are actually trying to uh bring

the developers perspective to different um audiences. >> Let me extend one sentence about the hacker garden to give you more context. The idea of the hacker garden is to meet to spend the evening together and to get ready a contribution during that evening to any open source project. So finishing it the evening is crucial to not take another to-do list item home and to have fun together

contributing back to the community while most of us doing the day jobs do not get the chance. So we have the hacker garden events to actually do these contributions we always have in the back of our heads. >> So if you go to the page you will see what were our achievements because that is our achievement. a merge request or a pull request into open source project

and we are very very lucky we have a lot of um project source leads that are with us working in the evening so most of the time we get it merged into the project so I'm very very proud about that but why are we here [snorts] Marcus >> yes talking about the CA and the regulators coming up with the regulations and changing the industry why do are

they doing that. It's mostly because we as the software industry did not come up or really stay up to par with the expectation normal people out there could rightfully have after we had the situation of software is eating the world. We was we were saying a couple of years ago and that means that software is nowadays inside of everything. every device basically every device we can buy

uh any new fancy feature we get somewhere is defined via software or at least software plays a plays a part of it on the other hand um we see software failing all the time so it's not up to expectations of the consumers of those people buying the products failing not in the terms of functionality is not there or not uh all the time there and stops working

at some point but also it's being turned around like sens sensitive data gets lost um the devices are controlled by somebody else uh apparently and somebody else uses your CCTV without you knowing it and this this situation where this industry did not really come up with the responsibility we got by having our products everywhere this led to the to the effect that Now the regulator has said

okay let's do something about that we need to establish a a serious standard of what people can expect from the products and this is how they brought up the CIA the cyber resilience act to respond to security and um all the risks out there but also the other regulations like the uh NIS for critical infrastructure like the Dora for financial institutes and the AI act of course

because there are um just in time to do something about this world changing technology AI which is now really hyped everywhere and I think it's good that we have the AI act so there is a response from the legislation legislation to that so this is where we are coming from what I miss >> you didn't notice anything but I actually agree I only want to highlight extra

highlight that this is an era that we have to pay more attention into the software that we are putting out there and I think it's even more important at the moment because now we see a proliferation of software that it is affecting my life uh in a ways that I don't I didn't foresee and sometimes I don't agree so not only we are consuming software that we

don't know what is inside we don't know how it was made and there is a lot of problems attached to it and some of them are closer to home. This is this was very fairly recent in LinkedIn talking about a software in in in the Swiss um in the Swiss industry and you as as I said I live in Switzerland so that hit very very close to

home. So the CRA is actually and another disclaimer before this. This is the second time I'm we are giving this presentation and I'm bringing it to closource developers which actually they need slightly a little bit more help from my perspective. I can go into that after after the session with coffee. So the CRA had two major project problems. Marcus what what you >> the ACIA is addressing

two major problems. So one of them is this low level of cyber security that didn't come up with the expectations the rightful expectations by the consumers. So uh products were put on the market and not cared about anymore. And we nowadays see especially in the global political situations where not only hackers who wants to make some money are on the market but also state actors are there

who wants to weaken uh the field or wants to weaken other states as a whole. And so they really we have another level of threat that threat level I don't like that term exactly but it it nails it pretty much. Um this is uh one of the major problems the CIA tries to address. And the other one is that um there was not enough understanding from the

people from the consumers of what they are actually buying and this is also by providing more information by providing more details what the CIA wants to help with. Yes, I mean it it has been long due that we go and see software as a product and say well what is inside this? What are the actual decision factors that I can take into the consideration for choosing product

A or product B? This is the first time that we're following for example the food industry where you have a right tracibility of what are the ingredients in your products. So that's why it makes sense when you have a potential harming ingredient there is a recall can be reached faster to the consumers before something happens. So the CRA and we started with a lot of regulations but

we are focusing the CR right now and the date that we put in our subtitle was 11 of December 2027 because that is the date that the CRA becomes fully applicable. So what does that actually mean? Does anybody know here what fully applicable means? Okay, two hands. So I'm in the right place with the right audience. I love >> And here we come back to the motivation

table we had at the beginning. Yes. And we added one more column which I um which I like sneak previewed or mentioned that is the column about what's beyond the fines. What what other motivation does the regulator do the regulators give to comply with these um with these laws? It's actually that they say okay if you do not comply to the CIA we take the product from

the market or for NIS2 if you do not comply with what we expect from you we uh invalidate your certifications and with a business where it's a lot about establishing a company in the context of having certifications this is a really good motivator I would say to comply or to address the needs from these Yes. So, what I like to joke about is like by 2027, if

we don't comply with it, we may need to start opening our checkbooks and the checks are not going to be um easy. So, we're going to talk about a lot. I'm going to we are going to provide a lot of solutions. That's good, isn't it? Uh and most of the solutions are well documented and also coming from different organization. In this case, we're going to talk about

a lot what Anissa is doing for us and also what the CISA the it's doing on the other side of the Atlantic. Um >> and I thought this slide is pretty useful because InSA and CISA before I got in deeper into that topic, I never heard of these organizations before. So the one is from the European Union taking care for the cyber security aspects and the other

one is from the states. Um and it's really good. I think most digital products are marketed on in both contexts. So it's good to have knowledge about these uh institutions and what they what they suggest and provide for us. who is going to pay attention to the CRA? This is if you are placing a product with digital elements in the European market with commercial purposes. If you

highlight like you feel identified by this description, you are under their preview or the scope of the CRA. Now what does it mean putting in place or putting products or made available? Who are economic operators in the terms of the CRA? >> so you will have manufacturers, authorized representatives, importers, distributors. Okay. Second disclaimer, the slides are going to be available. You can ask for us for the

slides. the small letters is because I don't intend for you to have an exam an I exam today. So that's why please do not read because this is nothing compared what is coming next >> and this what this slide really shows or or might be surprising to some people because it's not only those who are creating the software and are putting them originally to the market. It's

also to those who take other products and bring them to the European market, those importers. And there are different roles considered in the CIA and it's important to reflect upon that because just because you're not originally making the software you are not out of the perspective. So this is really relevant to be aware of. >> This morning when we were talking we are the keynote somebody addressed

like they took care of opensource and yes they did took care of open source. So now we have uh an new idea that it's the open-source software steward that it's a new kind of interesting element in the CRA that will have specific uh uh requirements or obligations. We will see that in [snorts] a minute. So in a way as I said uh ANISA they are trying their

best to provide as many guidelines or um information to all developers or all organizations trying to tell you uh how to achieve um or fulfill the requirements. And for example, this is coming from Denisa and you will see in our in our papers uh in our slides all the all the references >> and again we are we will share the slides. So that's really not meant that

you read the text in the bubbles. That's like to see there is a flowchart where you can actually find out if you are considered as an original >> uh creator and supplier bringing it to the market and as a economic profit maker or if you seen as open source steward and then affected by different com requirements. >> The other thing that I want to highlight here it

looks like a decoration. No, that's not a decoration because it has draft with me which means that it has been published and the different organizations are waiting for our feedback and to provide feedback. Is this clear enough? We should include more data. Uh here actually at the clip foundation uh if you work with different working groups or special interest groups you can join into discuss the different

uh documents like this one. So if we see it in a different perspective, this is in another view, but it's almost the same. Who is outside of the scope of the CR? If you are an individual or maintainer, volunteer or paid developer, you're out of the scope of the CR, the CR, but if you if you are an open source software steward, uh you still have some

obligations except for the no sbomb obligation. If you're a manufacturer or you have you're an economic actor of any in any way the full CRA falls into you in other words we will have a lot of in other words so if you make brand import distribute uh or you are a steward and you put a commercial product with digital mments in the EU you are under the

scope of the CRA Okay, the contributors to uh free open source software are not the main targets. So it's only going to be the stewards and then you can define who is a steward and what is taking you. If you want the answer of that is if the stewards are the ones that provide sustained support infrastructure security and for open source projects intended for commercial share use

without placing a product on the market that's the small difference >> yes fine I mean now if I do not fall under these groups I can leave now right or is Am I mistaken? >> And I had that question actually that's why this photo is here because somebody told me I work for uh the government and we actually don't publish any software. We only it's internal software.

We build it. We are only running it. We provide a service to our uh the citizens but we are not placing it in the European market. So I can live and I was like yeah but no [laughter] and I love that answers I'm a consultant so it all depends and I said well you know what you belong to a critical or essential organization or maybe you are

working with an essential infrastructure so NIS2 applies to you we're talking about the CRA because it will actually impact the most amount of people than the sisters legislations. Yeah. Especially if you are then also financial in institutes entities and or and it doesn't matter if you are in the EU or in the Swiss market as we are originating from Switzerland. So we always have that in mind

and we need to remind people in Switzerland. It's the EU is the big player here bringing in the legislation but usually the Swiss do also implement something very very similar. So in this case it's next to Dora there's FINMA for the Swiss market. So it's relevant with really much pretty much the same requirements and um also if you are even not within NIS or Dora Finma then

you are probably as of the hype everyone wants to use AI and brings in AI to everything there is the AI act and to learn that what these five big letters combination do have in common we we can have a closer look. So um first of all there is a quick overview what the letters all mean but more importantly there is this table and um then again

the text in the boxes is only the references for later for you to to uh uh to come back to but the in the first column there are the aspects of the regulation and you see in different order or in different combination they are all covered in all of those regul regulations. So if even if you see that you are not covered or affected by the CIA,

it's really likely that you might be covered by one of the other regulations. So the topics from the regulation do have relevance for all of us in this industry. So this is where my first saying we as an industry are getting regulated. The somebody said the wild west is over. So really now people look onto what we are doing and they request us to do it more

seriously. What does that mean that doing it? >> So again most of them depending on the scope we saw the CRA it's targeting products. NIS2 is targeting critical organization. FINMA and Pandora are targeting financial institutions and the AI act. Well, I think it will target every single one of us now in the AI era. They trying to consolidate the different requirements saying like we're going to cover

it. We're going to cover it in different articles and we're going to cover it in different ways. But at the end of the day, they're trying to create uh a seemingless kind of parallels that we will have to deliver or or or fulfill when we're writing software. And I always tell people like the AI act it's going to be born fully fledged because it is coming with

all the experience from the previous ones and they already know the pillars that we should be uh creating. In this case remember a developer session for developers. Why? Because at the end of the day somebody is going to come from CISO or from management. I'm going to tell me Excel, it's December 2027. Are we compliant with the CRA? And I'm going to be like, uh, what do

you mean? And they're going to say, yes, yes, you're building the software shell. You are the one that has to deliver everything. And then I going to be like, um, maybe it all depends. So what I'm trying to do or we are trying to do here is provide you with the tools or the knowledge to fulfill parts critical parts of the CRA. So in this case we're

going to be focusing in what is inside the software and as a side product because you cannot do uh risk management and for example reporting the incidents if you don't know what is inside of your product. And when I give this session, I have been in this topic for several years. And in the past when I was in front of the audience, I was saying if we

do release scalants, if we do sbombs, if we take care of this or that, it's going to improve the quality of the software that we do. And sadly in closed source software, everybody's like change log Excel. But if my consumers are internal like I don't need to prepare a change log semantic versioning why I only publish that into our Nexus repository somebody will consume it so it

actually felt in deaf ears so this is the first time that I feel vindicated like I'm so happy because now we are going to make a better world because we are inspired or because we're going to be fined. But I will take it. We're going to build a better world. >> This is a pretty pretty good turn on it because I think this all this motivation by

pressure might also be frustrating to people. And this is actually having a look at it and saying, okay, we now finally get the argument to apply what we know what we have known as best practices, but we never got the time to do it. This is also a more positive way to think about it. Yes. I mean, in essence, we want to build solutions that are secure,

that are uh reliable, that are long-term usable. And so now these regulations, regulations and legislation help us to have arguments to really get to the point that we are allowed to do it and we get the time to do it. And so we can finally apply those both best practices. We have been we know we have been known for a long time. >> Yes. So I get

motivated by either inspiration or desperation. You can join me in whatever you want. My disclaimer, my personal disclaimer, I'm not a lawyer. So this was me trying to well from several years understanding what is happening, understanding uh what was going to be required of us. I joined a lot of uh working groups or special interest groups. So, but I'm an engineer. I still write sometimes code. I

still sometimes read code. Sadly, my experience sometimes is like this. When I see my code, what what was I thinking? Wait, was I even thinking when I wrote that? But jokes aside, um, if you have a special questions about your industry, your product, uh, in terms of deadlines instead of like lifetime, what does lifetime mean in your case, please do consult the actual we go directly and

fully into the cyber resilient act. Now that's because of the cyber resilience act has been installed and it's now getting step by step more and more effective and as we said it will be finally fully effective by the end of 2027 but there is a risk of saying 2027 uh in April 2026 because it's over a year in front and people might go oh we take care

of that later but there is work involved that establishing something like a vulnerability management process is really something that's not done into two weeks and sometimes not even in two months. And so really people should start to care about that especially as we have this first steps now where we are required to do reporting and um to monitor and follow those uh those uh weaknesses we have

in our software and be even manage to be aware of those. And this is the thing like we have two purposes. First bring some uh light into what the CRA means for developers. The second is remind people that even though we still haven't published all the standards as you can see there is in the third quarter of this year we have the first standardization delivered for different

product specific standards. So we're still working in progress and this is what Anisa says to us like monitor follow and stay update on the progress of the new initiatives but also to remind people that they are publishing a lot of documentation and this is our time to ask the questions before they are written on stone or we want to know uh in our specific cases this is

the right moment to do it. So this is actually what the cyber resilient act says on the article 13 paraphr um so we need to ensure that products with digital elements are designed developed and produced in such a way that they ensure an appropriate level of for that they are incorporating a lot of requirements. So now software has to be secure by design on default. We will

have to have a vulnerability handling reporting obligations technical documentation and I always laugh um life cycle responsibility. >> Yeah. Yeah. The that's absolutely and I you love about the technical documentation me as a documentation nerd I'm happy to finally [laughter] see another requirement for that and we are we finally get a good argument to do that more carefully. So where is the security by design and default

being um mentioned in the annex one part one and it says actually in no shipping with nonritical vulnerabilities and security has to be part. So this is when I always tell people locking your dependencies. It's a good practice, but please only do it at the end of the re like before releasing not day one and you keep the same the same dependencies for the entire development process

of your software. No, because chances are that you are not updating recently and then you're going to ship with vulnerabilities. And in this case, the zero is saying, uh-uh, you should ship with whatever you want, but it has to be the least critical vulnerabilities inside there. So update often, update carefully, >> consciously. Yes, [laughter] just because on the other hand we have seen that just updating to

always to the latest version might be a danger as well as we have seen these exploited packages published on different repositories. So we really need to have the find the golden path between these options and so using the tools out there but we can come to that in a in a second. >> Yes. do a curation like support LTS do a scorecards whatever you want but choose

rightfully. So the second one is uh vulnerability handling and remediation. So not only we will have to provide an specific list of materials like with everything that it's inside us we also need to remediate have a plan produce produce patches [snorts] uh for all the software that we are placing there and we need to report it >> but we are >> exactly So who here has heed

about NVD a lot CV CVE and the weakness enumeration etc etc that's good and was tasked with creating the EU vulnerability database so most of it but don't worry most of this the the vulnerabilities reported here are being funnel from other well-known uh databases so If you already are publishing to one of the big databases, then you don't have to worry except for double-checking that it is

landing here. That's the only thing. And if you are not publishing any vulnerabilities for the time being, maybe you can adopt this one because this is the one that is going to be closer to the cyber resilient act and from the perspective of the ENISA. That's the only comment And then technical documentation. Yay, we finally get to it. And uh we now required to provide appropriate technical

documentation because we need to be able to explain our product in the case somebody comes along and wants to audit us. Somebody requests those things that are defined in the in the legislation. And um that includes security measure measures that includes the overview of architecture and components which should be best practice anyway. But now we have a good argument to do it the right way. >> And

and honestly before AI I was I I would have said like oh my goodness this is a lot. But now with AI I'm actually happy because it it actually documents quite well. So I'm not so worried but I'm happy that we are now it has part of our requirements. >> Yeah. The fifth and the last one. >> This one is a crucial one to understand because it

requires us to deliver updates for there are different time spans. Uh one I have in mind is five years. There are others right but that this is crucial to understand we are we cannot just put out something and just say it's there use it or leave it. No if it if we published it if we sold it even then we are required to provide the security updates.

So, and this brings implications to bringing something to the market. You have to calculate having this security and vulnerability management process running for five years and everything attached to it. >> And this is important because as as Marcus mentioned, it depends on the industry. For example, in the medical devices when updating and and patching it's not a best practice like it takes a lot of time even

to disconnect all the equipment, go through the process of updating. So different organiz the different industries will have different perspectives about this. So make sure that you read the document the legislation and all the examples of >> especially and uh as a side note for from as you mentioned medical devices these the medicine medical devices they are not fully covered by the CIA because they have their

own legislation. So, but it's it's really crucial to be aware and really have a close look if you are if you are or maybe your project might be affected or if there's other legislation requiring similar from you. So, like medical device and also parts of the automotive industry are not covered by the CRA. They are covered by other legislation, >> but they are going to be very

similar. That's the whole point. I'm going to go super fast because I have a lot of information that I want you to have or at least see it. So I and we are running out of time. So we're going to talk about a lot of the sbombs. Probably here everybody knows about sbomb, the software bill material, the list of ingredients that is inside. Um there are three

different formats and I can tell really beautiful stories about different ones. Different ones have different formats and different scopes. They were born at different times of the of the uh timeline. In our world, Java mostly, uh, Cyclone DX won the battle and now most of the tools that you see out there is going to generate the Cyclone DX format. Uh, as I said, they exist for several

reasons. Once were historical and the other ones was because they answer different questions and they have different audience. For example, there are different organizations that depending on who they are targeting or who they want to be consumed by, they will generate one or the other. And as you can see, there has different focus. Promise that the slides are available uh because I'm going to to start going

every single one answer different questions in better quality than the others. For example, S swax uh was born in the IoT industry. So they answer very specific questions about what was happening before the the software was installed and what happens when you remove it. Uh Cyclone DX is very good for our life because um it's generated at build time or uh at source Um again many organizations

that are very very big or very mature probably are going to use the three of them because of different audiences inside the organization and with different uh uh information that they want to provide. So now you know like what is sbomb you know that the the scope that you want to create the the sbomb to whom then you probably now know what is the format that you

have to create now which tools and this is why we mentioned that for example uh the organizations that are providing information and solutions to us in this case this comes from ana another paper that it's uh the guide for implementations towards esbomb that was published in 2025 and in December and they are saying they they're helping us saying if this is your programming language this is are

the tools that you can use to generate the sbombs and this is what you have to take into consideration and this is what you have to take into consideration it's also important for you as developers for example if you ask me as a person that works in Java it's going to be more about like how we're going to treat how are we treating our pom files how

questions like that are we are we having uh package JSON logs etc etc. So that is an interesting information from their different organizations. So you would ask me Excel we defined the scope we identified the format now we have the different tools let's build the sbomb and my answer will be which one okay which one and it don't don't don't look like this is good information for

me because it provides us with different ideas of what is what is possible and every single one has its own use. Uh the green ones is going to be my suggestion to you. Uh the blue ones are probably where we are and the yellow one it's going to be like pay attention to this one. This pro this taxonomy is coming from the cyber security the CISA which

has two or three years ahead of us in terms of the formalization of all these concepts. So if we have an SBOM at the beginning it's going to provide us with a better overview of what are we going to add into our software. In the analyze, you will see why it's in in in yellow in the in the ones. They also provide a table which which ones

what are the pros and the cons. And this is the moment where I highlight the yellow If you are introducing a third-party dependency that does not provide the ESO and I am putting a digital product in purposes, I'm liable. What does it mean that I have to go and in the Java world pull the jars open the jars jars is a zip file and do the analysis

and generate the sbomb. So we're going to be doing this for all the third party dependencies that are not providing sbombs for us. How deep are we going to do this? As deep as possible. How many ledgers? N layers. So this is also a call for projects that are very popular. Please please generate your sbombs so your consumers can consume it. >> And this now as deep

as possible now we do the bridge towards outside of the jar files. Now most or many deliveries are also done as docker containers nowadays. So it's not about these this aspect. We need to extract the pom files. We now need to go to the next level of analyzing what we do deliver and we do need to do this for our containers as well and for all the

layers underneath our actual application we install onto it. So the so the base layers we are building upon >> the uh story didn't end up there. The story continues because there are different times where you can create an sboom and again this different perspectives what are the advantages what are the dis disadvantages I suggest again the the green ones in the pre-build to give us better overview

and you're probably going to do the runtime too because that actually answers the question that is the spirit of the CRA is this particular server with this particular tenant affected by this particular vulnerability that that actual question is going to be answered only with the som in runtime. >> And just as a motivation from the past why this is relevant, just remember how long it took some

of us to find out where lo forj was installed and where we need to deliver patches when the lock forj vulnerability was going public. And so this is a good reminder of that we all or many of us have been in this situation where we were be happy to would have been happy to have this. Sorry for the last two minutes I want to go super fast

saying like now we have to think about the release process in in our internal uh projects and be more careful about that and this is for me it's like it's not a tool change we have seen the tools we have seen why to use the tool we have seen uh at what time use the tool but it's not only a tool problem it this is a culture

change because now we have to have resilient reproducible releases in a way that we are able to add that because I said sbombs has to be immutable and reproducible. So if you haven't seen this one, please please have a look. It's marvelous. There is a new uh new published um release in 2025 and it covers obviously agile, it covers AI and it like have a look. I

totally recommend it to you. So they define the release process as something like this. And for example all these questions that I started change lock uh have a scope and change control versioning management control deployment control rollbacks traceability and documentation. It has been part of our documentation and how we supposed to be doing the software for far too long. This is a release layer the trust uh

stack that I'm proposing to you or tools that can help you to do that. Who has here heard about reproducible builds? Yes, you're my crowd. Thank you. Okay, so what this is what I'm telling all most of the uh the the development teams out there. Our releases have to be reproducible releases. No more trust in Santa Claus or the goodness of the world. If you haven't seen

salsa, please have a look. I can explain a little bit more about salsa. There is a guide of quarkus with j releaser because it packages quite nice. There is sift for the containers that will generate the sbombs that they also have the vulnerability check on that. Maven, if you're working with Maven, we have the cyclone DX Maven plugin. We have the reproducible builds Maven plugin. So, no

more no more uh uh excuses if you're using Gradel. We have the cyclone DX plugin. We have the gradal plugin for reproducible builds and uh that's a okay and the protobomb. Remember the different types of uh formats that we were talking about cyclone DX, SPDX, SWAD tax, they can talk between SPDX and Cyclone DX. What do we do with our Sbombs? We create a node graph of

it and we can have a better questions or better answers. Actually, we want the answers about where are we vulnerable. J releaser will do a lot of the stuff that I have said in a really nice way. Join as many uh working groups or special interest groups to provide feedback and to learn more. >> Yeah. And maybe as we have seen that icon of the Eclipse open

regulator regulatory and compliance group there is a really good FAQ uh regarding the CIA provided by that group. I can only recommend also to have a look at that >> and please provide us feedback. I want to deliver this message to as many development teams out there and I has to be a good message and that's [snorts] where you can contact us for the slides. Thank you

very much. [applause] >> [music]