How to Integrate DevSecOps to comply with the Cyber Resilience Act?
The European regulatory context
In recent years, there has been a significant buzz in geopolitical and economic arenas surrounding issues related to cybersecurity and their consequences. The highlighting of these crucial matters for our organizations has led European authorities to initiate a dynamic approach to secure actors deemed critical for Europe. This strategy has manifested in the publication of various reports on cyber threats as well as the drafting of binding European regulations. These texts aim to define orientations in terms of cybersecurity to enhance the maturity level and protection of companies against systemic risks (regulations NIS 2 and DORA).
Thus, the year 2024 is marked by the publication of several major texts, particularly the national transpositions of the NIS 2 directive (Network Information Security) and the Cyber Resilience Act (CRA). The transpositions aim to communicate the national technical requirements that must be met to secure the systems of essential and critical companies within the European territory. The CRA, in turn, supports the NIS 2 directive and the DORA (Digital Operational Resilience Act) regulation published in 2022 for financial and banking institutions.
Indeed, despite the relatively broad scope of DORA and NIS 2, Europe has chosen to define specific strategic constraints within these regulations. For example, in the French transposition of the NIS 2 directive, security objective No. 4 concerning supply chain management requires a list of suppliers involved in the ecosystem of the entity.
Focus on the Cyber Resilience Act (CRA) and its implications
This is no longer the case with the CRA, which targets manufacturers, distributors, importers, and publishers of products that include digital elements intended for the European market.
This new text imposes major requirements on manufacturers to ensure security, notably through the establishment of a so-called "Security by Design" approach that defines 45 overarching requirements, 17 of which can be addressed through the DevSecOps approach.
Following its validation by the European Commission in October 2024 and its publication in the Official Journal, the affected companies will have between 12 and 24 months, depending on the criticality of the equipment, to achieve compliance.
Compliance with the CRA's requirements and obtaining the CE mark will enhance the credibility and security of the certified digital products.
By adopting the CRA, the aim is to demonstrate to clients a commitment to the secure and sustainable management of developed products throughout their life cycle. Achieving compliance will allow for anticipating future supply chain requirements. Thus, the companies involved will be able to protect themselves against possible sanctions and ensure the sustainability of their marketing authorization in the European market.
DevSecops : a structuring approach to meet new requirements
In the face of increasingly demanding regulations, methodologies must be deployed to combine compliance and operational efficiency. Among the solutions, DevSecOps emerges as a key approach to integrate security throughout the product life cycle.
However, its success relies on the prior execution of the initial phases of a risk analysis. These activities will help identify specific threats, potential vulnerabilities, and challenges, not only in terms of compliance but also for the product itself.
By relying on the guidance resulting from the risk analysis, the DevSecOps approach can be effectively deployed with security requirements integrated from the design phase, rigorous validation processes, and proactive vulnerability management.
This structured framework not only ensures compliance with the CRA but also strengthens the resilience of products against increasingly significant cyber threats. This strengthening will also indirectly enhance the competitiveness of products that will ultimately be favored by European companies.
The requirements of the Cyber Resilience Act
Annex I proposed by the CRA regulation lists the requirements to be applied to products containing digital elements. These 13 requirements related to the properties of the products represent the key points to consider during their construction. These requirements can be summarized as follows:
References | Requirements |
I.1.1 | Implement Security by Design throughout the product lifecycle to ensure an appropriate level of security based on risks |
I.1.2 | No known exploitable vulnerabilities should be present at the delivery of a product |
I.1.3.a | The default configuration proposed for a product should be secure |
I.1.3.b | Protect products from unauthorized access |
I.1.3.c | Protect the confidentiality of data (storage, transit, processing) |
I.1.3.d | Protect the integrity of data (storage, transit, processing) |
I.1.3.e | Only process the data necessary for the use of the product |
I.1.3.f | Protect the availability of essential product functions |
I.1.3.g | Limit negative effects on the availability of other devices |
I.1.3.h | Limit the attack surface |
I.1.3.i | Design the product to minimize the consequences of an incident or exploitation of a vulnerability |
I.1.3.j | Implement logging to monitor sensitive internal functions |
I.1.3.k | Provide a mechanism for updates to fix vulnerabilities |
The following section of the annex presents 8 requirements related to vulnerability management that must be implemented:
References | Requirements |
I.2.1 | List and document the components and vulnerabilities of the product |
I.2.2 | Address new vulnerabilities without delay |
I.2.3 | Conduct regular security tests |
I.2.4 | Provide updates and communicate about existing vulnerabilities |
I.2.5 | Implement and enforce a coordinated vulnerability disclosure policy |
I.2.6 | Allow third parties to easily report a vulnerability |
I.2.7 | Provide a secure mechanism for distributing updates |
I.2.8 | Assist the user in applying security updates |
Other annexes of the regulation list the requirements related to the information to be provided to users, compliance declarations, and the content of the documentation to be produced. These elements are not directly addressed by the activities proposed by DevSecOps and will need to be handled through support from experts in Governance, Risk, and Compliance.
The prerequisite of this CRA regulation
To meet the requirements of Annex I, it is essential to have solid foundations. This includes raising awareness, training employees, and providing a necessary toolkit to peacefully integrate security. Technical skills alone are not sufficient and must be accompanied by the integration of security into the software development lifecycle (SDLC). Once these prerequisites are met, a set of security activities can be implemented throughout the product lifecycle, starting from the preliminary phases.
Implementation of the CRA within your infrastructure
The risk analysis mentioned earlier is the first step in defining the security level and the points of attention to be considered. Once completed, each stage of the SDLC must integrate security activities. The goal is to design and develop digital products while ensuring an appropriate level of cybersecurity based on the risks (Security By Design).
Among the security activities that can be integrated into the SDLC (Software Development Life Cycle) before the development phase, the following elements can be found (non-exhaustive list):
Definition of security requirements: define the appropriate level of security and provide a list of factors to consider (such as availability, integrity, confidentiality, etc.)
Use of secure reference architectures: avoid reinventing the wheel and capitalize on proven architectures (authentication, data storage, etc.)
Implementation of a logging system: define which types of logs need to be stored, the different levels, integrity management, etc.
Threat modeling: put yourself in the attacker’s shoes and identify vulnerabilities in the proposed architecture.
In the development phase, activities focus on implementing and following best practices for secure development (such as input sanitization, logging, etc.), conducting security-focused code reviews, and deploying detection tools like SAST (Static Application Security Testing) or SCA (Software Composition Analysis) directly within the IDE (Integrated Development Environment) to detect vulnerabilities as early as possible.
In addition to the daily activities of developers, establishing a community of "Security Champions" is an opportunity to capitalize on everyone's work and issues.
To be able to react quickly in case a vulnerability is discovered and provide an update to clients, it is essential to industrialize and automate the delivery pipeline. This pipeline, which lies between the production of code and the delivery of the product or its updates, must be maximally automated.
To achieve this, setting up a CI/CD (Continuous Integration/Continuous Delivery) pipeline is essential. It includes tests ensuring the proper functioning of the application (unit tests, regression tests, etc.) combined with static security tests (SAST, SCA) and dynamic tests (DAST) to build and deliver a quality product.
To meet the requirements for documenting the components of the product and the associated vulnerabilities, this supply chain can also integrate a step for generating an SBOM (Software Bill of Materials) for the components and associating it with information from VEX (Vulnerability Exploitability eXchange) for vulnerabilities.
Please note that among the 21 main requirements of Annex I of the CRA, DevSecOps-related activities address 17 of them.
Thales by your side in supporting compliance with the Cyber Resilience Act through the services offerings listed below:
Compliance Support
- Identification of the applicability of the regulation to the scope (Class I, II, and critical)
- Deployment of operational governance to ensure compliance throughout the asset lifecycle
- Security related to product properties
- Vulnerability management
Risk Analysis
- Identification of the risks inherent to each product to adapt the depth of DevSecOps activities
- Conducting analyses based on known frameworks (e.g., EBIOS RM, ISO 27005) or tailored to your needs
- Establishing a consistent view of risks across all marketed assets
DevSecOps
- Maturity assessment regarding the requirements of the CRA
- Proposal of a roadmap based on the three pillars: People, Processes, and Technology to achieve compliance
- Support in implementing activities throughout the product lifecycle
Why working with Thales for your CRA compliance?
Compliance with European regulations such as the CRA, DORA, and NIS 2 is crucial for the security of your critical infrastructures and the sustainability of your activities. Our compliance and DevSecOps experts possess combined expertise to help you meet the specific compliance requirements of the CRA, guiding you through this sometimes-complex European regulatory landscape.
As an industrial group, we combine expertise in product manufacturing and security with knowledge of standards and regulations, enabling us to transform regulatory challenges into opportunities for enhanced security. Leveraging a large number of critical infrastructures clients we have supported in their compliance processes, we provide tailored support that ensures operational security while meeting regulatory requirements.
