Mission: CRA-possible

In this talk, Melanie Bats, CTO at Obvious, discusses the importance of becoming compliant with the Cyber Resilience Act (CRA) in software development. She emphasizes that CRA is designed to reduce risks and ensure secure product design, transforming developers' responsibilities by mandating that manufacturers take accountability for security. Melanie outlines a systematic approach to integrate compliance seamlessly into existing workflows without hindering development processes by creating templates and checklists to guide teams in risk management, security lifecycle, and documentation. She stresses the necessity of automation and making compliance a shared system across roles, encouraging teams to focus on the essential tasks associated with their responsibilities. By aligning documentation with product repositories, continuous compliance becomes part of the development workflow, allowing for real-time tracking of compliance status and enabling teams to make informed decisions about risks and security measures.

[music] >> Hello. Um Can you hear me? Do you hear me? Yes, some of you. Is that okay? Good. So, hello. Uh I'm Melanie Bats, CTO at Obvious, and uh today I am your special agent for CRA. So, your mission, should you choose to accept it, is to become CRA compliant. And if you looked at the Cyber re re re re re re re re re re

re re re re re re re re re re re re Today, I'm going to show you how we approach it at Obvious. And like many teams, we had to figure out what that means in practice for us. CRA was not created to add more paperwork. It exists to reduce real risks and to prevent incidents and to build secure products by design. Um you can see how

fit like physical products, for example, toys in Europe, they must comply with CE standards. You don't check how they're built, you just trust they are safe. And CRA brings the same idea but to digital products. Um software and connected systems must not be secure by design. And CRA also defines who is responsible, manufacturers, importers, distributors, and authorized representatives. But in most case for us, a company like

mine, we realized that we are a manufacturer. Which means we are responsible for the security of what we build. And that's the real shift. Uh we're no longer just shipping software. We're responsible for its security. So, CRA is coming. It applies to most of what we build and we need to be ready for next year. But when you read it, it's long, ambiguous, and not actionable. So,

the requirements are complex, the language is legal, there are no clear steps, and it impacts multiple teams, developers, security, products, and in the end, reading theory doesn't tell you what to do on Monday morning. So, what now? Your mission is not just to be compliant, it's to be compliant without slowing down development and without adding heavy processes, without duplicating work because otherwise teams won't adopt it and

it won't scale. So, the real challenge is integration, integrating compliance into your existing workflow. Theory is actually simpler than it looks. It comes down to mostly three things. Understand your risks, address them, prove it with evidence. But, turning that into something teams can actually use is the hard part. Because now you need traceability, documentation, and consistency. So, we decided to structure our theory interpretation once for all

our products. We needed something we could actually use in all our products and we turned the regulation into a system. We create templates to structure deliverables, checklists to make expectations explicit, uh workflow to guide the process and the tool chain to automate evidence. So, our teams don't have to figure it out, they just follow the And we reuse it across all our products. So, what does that

system look like? This is what we ended up with. We translated each theory into certain deliverables. Not a checklist, as I said, a system structured into five blocks. Context and scope to describe the product with uh with also risk management to identify and twist risks, security life cycle to build and validate security, automated evidence to generate proof continuously, governance to define rules and policies. Each document has

a role. Everything is connected. This is our interpretation, as I said. So, I'm not a legal so okay, um I'm a technical woman. So, we work on that has been part of the Eclipse Foundation open open regulatory compliance working group and we will propose that to the working group soon. It's as I said based on our experience, it's still evolving. So, don't hesitate also to challenge it

and improve it and try it by yourself. Okay. Now, there is an important question you have to answer. Do you really need to do all of this yourself? It depends. Uh, as I said, CRA does not apply the same way to everyone. Responsibilities depend on your role. Your first question regarding your product is to understand your role. So, if you are the manufacturer, you design and build

the product. So, you are responsible for everything. Risk management, security life cycle, documentation, evidence, you own the full system. If you are an importer, you don't build the product, but you must ensure it is compliant. So, you verify. Uh, you ensure documentation exists, you keep evidence accessible. And if you are a distributor, you go even later. You ensure the product has a declaration of conformity and that

basic information is available. Just check that. And you don't need to do everything, you need to do the right Uh, our goal with this system is that this system is that adaptable to your role. Focus on what is required and rely on what others produce. So, compliance is not just an individual effort, it's really a shared system. So, now the next question is who actually does the

work? How do we produce all of this? And very quickly we realized something, some parts can be automated and some cannot. So, CRA requires a lot of work and not all of it should be done by humans. Some things should be automated as bomb generation, vulnerability detection, security scans, status tracking, but some things cannot be automated. Understanding your project, street modeling, architecture decision, risk decisions. And this

is the key insight. Introducing tools in your product tool chain don't make you compliance. That's not enough. They just produce evidence. And compliance comes from decisions. So, where are we? We understand that machines produce evidence, humans make decisions. But that's not enough. To make it usable we have to define a clear sequence. How do you start to make your product share compliance? First step, you start with

context. You describe your product and its environment. Then you identify your assets. What needs to be protected? Then you ask a key question. What could go wrong? This leads to threats. Then you evaluate risks and you prioritize what matters. After that you decide what to do about them. Um you define treatments. And finally you produce evidence to prove that everything is under control. There is not a

checklist as I said, it is really a sequence and each step builds on the previous one. You cannot skip steps. So, let's take one step and go deeper to walk through the sequence with an example. Let's zoom into one of the most important step. Threat modeling. Here you need to stop thinking like a developer, you have to start thinking like an attacker. Ask yourself three question. Who

can attack? What do that What do they target? And how do they attack? We can take a simple example, a public login API. So, we should answer the question, what could go wrong? Imagine a brute force attack. Who attacks? An external actor. And that's a threat. On your product you need to start simple if you want to do that. Start with five to 10 stress is really

enough. You You refine that Then what? We know now that we could go we know know that what could go wrong, but we need to decide how serious it is. For each identified threat you define likelihood, impact, risk level. And then you ask you you you answer one question, is it acceptable or not? So, Siri forces you to make that decision. There is no gray zone. If

we take our simple example, the brute force on your login API. What is the likelihood level? Quite high. Uh what is the impact? Moderate. What is the risk level? High. So, can you accept it for your product? Definitely not. Security is not about finding risks, it's more about deciding what to do with them. And once you decide, you have to act. So, we need to a decision.

We have identified a risk, which is not acceptable. And this is where things become concrete. Now what? We act. We have to choose a treatment, mitigate, avoid, transfer, accept. Take our example, the brute force on the login API. Our answer cannot be only improve We need concrete measures. For our login API, concrete measures would be rate limiting, hack and lockout, MFA. It is actionable. It is testable.

We have no vague actions, only concrete measures. Now, we need to prove that our concrete measures are implemented, and this is where tools come in. You don't generate evidence manually. You automate it. Every build produces compliance evidence. Your pipeline becomes your proof. For example, you generate SBOMs automatically, you run security analysis with SonarQube, you track dependencies with Snyk and C track, you centralize everything in DefectDojo, and

all of this produces evidence, SBOM, V&V reports, CV logs, and you got your compliance status. It is always up to date. Evidence is not something you write hands, it is something you generate continuously. So, we build a system of documents, but we still need a way to implement it. We decided at Thales to use simple tools. All our documents are written as templates in AsciiDoc. They are

centralized using Huntera. Uh one template per deliverable. Then for each product, we instantiate these examples and these templates. So, we decide that they live directly in the product repository, versioned with the code. Compliance so is not separated, lives with the code. And this makes everything easier to maintain, easier to evolve, and easier to scale across products. So, compliance becomes part of the development. So, now everything is

running. We implement one more thing to follow our progress, to see our compliance for all our products. So, we track three things: approved documents, internal approved of the documents, the critical risks we identified, and critical vulnerabilities. That's enough to compute a status, not started, in progress, ready for declaration of conformity, and compliant. At any time, we know where we stand in our C application at Thales, and

we know what is missing. So, we've seen the system, we've seen how it works, we've seen how to implement it. So, let's take back. Here is the full picture. This is our reference card. Everything is here. The structure, the sequence, the Uh you don't need to remember everything. You don't even need to read it right now because it's a 15-minute talk, it's too short. Just remember that

this exists in my slides, and to come when you come back on Monday morning, you can try to apply that on your organization. As I said, we defined certain deliverables. This is our backbone. But in practice, this is not the whole story. We also use additional documents, not required, but recommended. We found them very useful in practice, they enrich the system. For example, we also had architectural

documents to help us understand the system better and improve threat modeling, secure development guidelines, operational documents to help with monitoring, supply chain documents to improve risk management, and testing strategies to enforce validation. So, the certain deliverables give you a structure and these additional documents make the system stronger. So, after going through all of this, what did we learn? Security compliance is not a checklist, it's a system,

a system with a sequence, a system where decisions are explicit and where evidence is produced continuously. And when you do that, compliance is no longer a burden, it becomes part of your product quality. Compliance is not extra work, it is structured work. And as I said, what I shared today is our current understanding. So, it's something we are building, still testing, and it will continue to evolve.

So, the next question for you now is how do you turn this into a system in your team? So, remember first how to start. You don't need to transform everything, start with one product, follow the sequence, create your own templates based on the backbone I gave you, automate what you can, and you'll see series stops being a problem, it becomes more a system. Thank you. And this

presentation will self-destruct in 3, 2, 1. Or maybe not. >> [applause] >> And if you want to go further, I have 2 minutes for questions. [laughter] You have questions? >> Questions. No, definitely not in 15 minutes, it's So, one quick question. Is there anything from your shirt available in open source, like checklists, tools, documents, etc.? >> Yeah, my the idea is that we would contribute that to

the OSC working group. I need to send an email to this guy. >> [laughter] >> And the idea is not to just to give the structure first and we'll see if the structure is the case and maybe we will work on the different template because right now it's really our own templates, but even having the structure and the sequence, that's a huge work. That's brilliant. Thank you.

Thanks. Other questions? >> Other question with Yeah. Just a quick one. In addition to to the templates, do you also provide guidelines for the for example, the the risk measure that should be there or the threat analysis the threat modeling method we should use for that? We decided to use one, but there is so much that exists. You need to choose the one which will fit with

your company, with your team, with their mind how they will their mindset. So I I can share which one we're using, but then it depends. the application. >> If if it's supported by some open source tools, it would be great to to know >> It's for for this is mainly for the risk analysis, it's mainly something you need to create a matrix. So >> It's done by

hand right now. There is no tooling for that. One last question. Okay, thanks. >> Very quick. The answer may be very long. How much did it take for you and your team to embrace this and start implementing this and then Okay, so >> reaching the the the point you are right >> We are not yet reaching the end point. Right now, it takes us I think we

start working on that in October last year. And we produced all those things with two persons, one with a technical one and one with a legal one. And yeah, it's take some times. So that's why I would like to share that also with some others in cities could have a look on it and to check if it's okay. Okay, thank you. >> Good. Thank you very much

Melanie and yeah, we are likely >> [music]