Securing digital products under the Cyber Resilience Act
In this Help Net Security interview, Dr. Dag Flachet, co-founder at Codific, explains what the Cyber Resilience Act (CRA) means for companies and how it compares to GDPR in terms of regulatory complexity and impact on organizations. He discusses the technical and procedural challenges posed by CRA, particularly in secure software development, and highlights the role of frameworks like OWASP SAMM in conducting readiness assessments.
In your view, how does the CRA compare to GDPR in terms of regulatory impact and complexity for organizations? Can you elaborate on what that impact looks like in practical terms for organizations?
Under GDPR the most impactful aspect for businesses are the limitations around what you can do with the data of the individuals. The data can only leave the EU under certain strict conditions and can only be used for the purposes for which the subject provides consent. This means that companies (data controllers) must have contracts with all their suppliers (data processors) etc. Complying with the 8 data subject rights is relatively easy once we have a clear inventory of where the data is and a contractual agreement with everyone who processes the data.
CRA sets a minimum level of security for all products with a digital component, that includes all software that is sold, built to order, and on-prem SaaS solutions (it excluded cloud SaaS, and products covered by other legislation such as radio equipment and medical devices). It also includes physical things like baby monitors and smart fridges. Whereas GDPR is all about personal data, CRA includes B2C and B2B products. CRA is built on the CE product safety labeling system.
This implies that companies have to demonstrate compliance and depending on the classification of criticality may need external verification or a certified quality control system. But the main challenge at this point is not the certification, it is the fundamental security practices that are needed to comply with the requirements of the regulation. These are required for all products with digital components, including those not deemed critical. In practice millions of companies, including worldwide suppliers will have to upgrade their appsec program or create an appsec program from scratch in order to have the security activities in place to comply with the regulation.
Can you explain how the SAMM model was used to assess CRA readiness, and why it’s a meaningful lens for this kind of regulatory compliance?
OWASP SAMM is an inventory of all the recommended organizational processes around application security, categorized per maturity of the process or the broader security activity. Nobody does it all, and nor should they, that would be wasteful. Instead SAMM is used as an inventory and a map of the current situation, and to make strategic choices about investments in security. Choices depend on risk profiles, risk appetite, technological context, business context and regulatory context.
Therefore SAMM is ideal to provide concrete identification of the organizational processes around security that are needed in order to be able to comply with CRA.
Threat modeling and application risk profiling had some of the largest readiness gaps. What will it take for companies to build up maturity in these areas fast enough to meet CRA timelines?
CRA explicitly states that products should have appropriate level of cybersecurity based on the risks, the risk based approach is fundamental in the regulation. This has the advantage that we can set the bar wherever we want as long as we make a good risk based argumentation for this level. This implies that we must have a methodical categorization of risk, hence we need application risk profiles. In order to implement this we can follow the quality criteria of maturity level 1, 2 and 3 of the application risk profiles practice. This includes having a clearly agreed upon, understood, accessible and updated risk classification system.
We must also be able to demonstrate that we protect data’s confidentiality and integrity by “state of the art mechanisms and by using other technical means” and that we systematically analyze potential risks. Threat modeling, and the remediation of its findings are essential to these requirements. To develop this capability companies can follow the prescriptive guidance of OWASP in maturity level 1 and 2 for threat modeling. This includes a standardised and documented process for threat modeling linked to application risk profiles and the business context.
What practical steps should organizations take right now to close the CRA compliance gap by 2027? Are there particular security frameworks or tools that can accelerate this progress?
The first step should be to identify gaps. Many companies already have SAMM assessments, if you do not have SAMM assessments but use another maturity framework such as OWASP DSOMM or NIST CSF you could use the available mappings to accelerate the translation to SAMM. Otherwise we recommend doing SAMM assessments and identifying the gaps in the processes needed. Then deciding on a roadmap to develop the processes and capabilities in time.
Why not go at it without SAMM? Because you would have to define the processes and best practices. Which has already been done by OWASP, and referring to OWASP’s guidance is considered as compliance with industry best practices by regulating bodies. Having a solid maturity framework behind your application security program also ensures a proper inventory of processes in place and facilitates multiple compliance efforts, it avoids having independent and sometimes contradictory documentation for different compliance efforts.
What lessons should companies draw from GDPR enforcement patterns when preparing for CRA implementation?
Under GDPR we need to have a good picture of where data goes, think data flow diagrams including those of our subcontractors and their subcontractors. Without a strict control over where data travels, it is very challenging to comply with GDPR. In CRA we need to demonstrate that we have adequate security processes in place, and that we do not ship products with known vulnerabilities. So apart from having a good picture of the data flows we need to have a good picture of the processes in place.
Based on the GDPR, fines will start off slowly and then accelerate a few years into the regulation until the principles are well internalised and implemented by the industry. Then fines start decreasing. We can avoid risk, stress and fines by doing our homework and having our house in order from the start.