The Digital Operational Resilience Act requires financial entities to integrate DORA source code review practices within a DORA secure SDLC to mitigate risks related to application vulnerabilities and malicious code.

Meaning of “where feasible”

Article 25 of DORA establishes that software testing programs must include source code reviews “where feasible.” This constraint applies when the source code is actually available to the financial entity. Consequently, code review is mandatory for internally developed software and custom developments made by third parties, while it may be excluded for “off-the-shelf” packages when the code is not provided.

Code review, SAST, DAST and manual review

Financial entities must adopt a rigorous approach to DORA software testing in line with Delegated Regulation (EU) 2024/1774:

• Static Application Security Testing (SAST): Static analysis of source code to detect logical and security vulnerabilities without executing the program.
• Dynamic Application Security Testing (DAST): Dynamic tests performed with the software running to identify flaws that emerge during execution.
• Security Testing for exposed systems: In-depth security checks are required for applications and systems accessible from the Internet before they go into production.

Custom applications and critical functions

The level and intensity of testing must be correlated to the criticality of the business functions supported by ICT assets. For applications that support critical or important functions, DORA provides for:

• Verification through testing that new systems are adequate to operate as intended.
• Analysis of the quality of internally developed software to prevent errors that could cause operational disruptions.
• Implementation of controls to safeguard the integrity of the source code, preventing unauthorized manipulation during development and deployment.

Integration into the development cycle (Secure SDLC)

• Segregation of environments: Development and test environments must be strictly separated from the production environment.
• Test data management: The use of real data in non-production environments is prohibited, unless it is anonymized, pseudonymized, or randomized, while protecting integrity and confidentiality.
• Project governance: ICT projects that impact critical functions must be reported regularly to the management body.

Evidence for audits and remediation management

• Identification of anomalies: Every vulnerability or anomaly detected must be analyzed.
• Action plan: It is mandatory to prepare an action plan to correct deficiencies, defining responsibilities and timelines.
• Monitoring: The implementation of corrective measures must be constantly monitored to ensure that the residual risk remains within the established limits.

FAQ

• Is code review mandatory?
• Yes, it is necessary for all software developed internally or custom. For third-party software, it is mandatory “where feasible,” that is, when the supplier makes the source code available.
• Is SAST enough?
• No. It is required that code reviews include both SAST and DAST for a complete application security assessment.
• How to define priorities?
• Priorities must follow a risk-based approach, with precedence given to systems that support critical or important functions and those exposed on external networks or the Internet.

Build resilient software: request an assessment of your secure SDLC and your application testing program to align your development processes with the technical requirements of DORA.