Skip to content
Published on

The Cyber Resilience Act – Part II : CRA, Open Source and Test Automation

Categorized
Articles

Open Source and the CRA

The CRA explicitly addresses open source software (OSS) but with important nuances and exceptions.

Scope of Responsibility

Open-source software is generally exempt from CRA requirements if it is

  • Developed or supplied outside the context of a commercial activity

  • Shared freely for public use, without direct financial gain

This exemption aims to protect non-commercial contributors, such as community-driven and academic OSS projects, from regulatory burden.  However, given the actual mix of commercial and non-commercial OSS development, this language is highly contentious.

Commercial Context

OSS becomes subject to CRA requirements if it is distributed or integrated as part of a commercial product or service. For example

  • If a company incorporates OSS components into products and profits from their distribution, it must ensure compliance with CRA cybersecurity standards.

  • Businesses leveraging OSS must take responsibility for security assessments, vulnerability management, and updates related to those components.

Vulnerability Management

The CRA emphasizes secure software development practices. Organizations incorporating OSS must ensure that known vulnerabilities are addressed and that updates are available and applied appropriately. The onus of this requirement lies not just with the software development team, but with integrators and potentially, with end-users.

Concerns and Challenges

By distinguishing between non-commercial and commercial activities, the CRA seeks to balance promoting security with avoiding undue impact on open source development. However, its practical implications for developers and organizations remain a topic of debate. Critics argue that the CRA approach will discourage contributions to OSS projects and/or increase the compliance burden for developers and even casual contributors.

OSS Consortium Response

To date, the primary response has been from the Eclipse Foundation through its Open Regulatory Compliance Working Group. This initiative from EU-based Eclipse the stated goal of

formalizing industry best practices and offering essential resources to help organizations navigate regulatory requirements across multiple jurisdictions. Additionally, it aims to assist government entities in providing greater legal certainty to the open source ecosystem and software supply chain.

and to

address compliance with open source-impacting requirements in general,[and] its immediate focus is the European Cyber Resilience Act (CRA)

The working group include the Apache Software Foundation Blender Foundation, the OpenSSL Software Foundation, the PHP Foundation, the Python Software Foundation, and Rust Foundation in addition to Eclipse.  The group revealed their intentions to pool their collective resources to create security best practices in open source software development.

The Linux Foundation, for its part, is highly critical of the CRA, averring that It will not work.

CRA Impact on Test Automation

The EU Cyber Resilience Act (CRA) will significantly impact test automation, as compliance with the CRA's cybersecurity requirements will require robust and systematic validation of software and digital product security. Here’s how it will influence test automation:

Increased Demand for Security-Focused Test Automation

Security Compliance Testing: The CRA mandates that digital products meet stringent cybersecurity standards. Automated tools will be essential for

  • Identifying vulnerabilities, including known Common Vulnerabilities and Exposures (CVEs)

  • Verifying secure-by-design and secure-by-default principles

Continuous Security Validation: Automated testing will play a key role in continuously monitoring and validating software updates to ensure compliance throughout a product’s lifecycle.

Integration of Cybersecurity in the Development Pipeline

Shift-Left Testing: To meet CRA requirements, cybersecurity testing will need to be integrated early in the software development lifecycle (SDLC). Test automation will include

  • Static Application Security Testing (SAST) during coding.

  • Dynamic Application Security Testing (DAST) in staging environments.

  • Penetration testing simulations.

DevSecOps Adoption: Automated test suites will become central to DevSecOps practices, ensuring security is embedded into CI/CD pipelines.

Validation of Vulnerability Management

Automated Patch Testing: Since the CRA requires regular updates and vulnerability patching, automated testing tools will be crucial for

  • Validating that patches do not introduce new vulnerabilities

  • Ensuring backward compatibility and functional stability post-update

Regression Testing: Automated regression tests will ensure that updates maintain compliance and do not break existing features.

Comprehensive Coverage of Product Types

IoT-Specific Testing: IoT products require specialized testing for

  • Network security, including automated penetration testing.

  • Hardware-software integration vulnerabilities

  • Communication protocols and data security

General Software Testing: Non-IoT products will require automated validation of software logic, dependency security, and cloud-based interactions.

Transparency and Reporting

  • Compliance Evidence Generation: Automated testing tools will aid in generating reports that document compliance, an essential requirement under the CRA

  • Audit-Ready Outputs: Test automation frameworks will need to produce outputs that align with CRA audit and documentation standards

Challenges to Adoption

  • Increased Complexity: Automation frameworks will need updates to accommodate CRA-specific tests, such as those for secure-by-default configurations and lifecycle management

  • Cost and Expertise: Adopting or upgrading automation tools for CRA compliance might require investments in new tools, training, or expertise

Conclusion

The CRA will elevate the role of test automation in ensuring cybersecurity compliance. It will drive innovation in security testing tools and methods, integrate security checks throughout the SDLC, and increase the adoption of automated tools for continuous compliance. Organizations that proactively align their test automation strategies with CRA requirements will benefit from smoother compliance processes and enhanced product security.