Home » Security Bloggers Network » Are the Fears about the EU Cyber Resilience Act Justified?

Are the Fears about the EU Cyber Resilience Act Justified?

by Thomas Segura on December 1, 2023

On Wednesday, July 19, the European Parliament voted in favor of a major new legal framework regarding cybersecurity: the Cyber Resilience Act (CRA).

According to the press release following the vote:

"The draft cyber resilience act approved by the Industry, Research and Energy Committee aims to ensure that products with digital features, e.g. phones or toys, are secure to use, resilient against cyber threats and provide enough information about their security properties."

This choice of examples, mundane as they may seem, subtly underscores a critical debate surrounding the CRA: its broad scope of application. While some may question the inclusion of such commonplace items, it reflects the Act's comprehensive approach to cybersecurity.

The CRA's introduction is timely and vital. It represents a concerted effort to enhance the resilience of digital products against cyber threats, demanding international collaboration and strategic foresight. This initiative is a significant stride in bolstering EU's cyber defense and asserting its digital sovereignty.

For context, the European Union Agency for Cybersecurity (ENISA) highlights a concerning escalation in both the frequency and complexity of cyberattacks targeting the EU, as detailed in their Threat Landscape report. Public administration, constituting approximately 19% of these attacks, emerged as the most vulnerable sector in 2022 and 2023.

Decoding the Cyber Resilience Act: How Will It Work?

The CRA's main objective is to establish a universal cybersecurity baseline for all products with digital components sold within the EU. This encompasses a wide array of items, from software and network-connectable devices to items containing embedded computing systems. Significantly, the Act does not differentiate between consumer and enterprise-grade products.

To manage this diverse range of products, the Act proposes a categorization into three security tiers: the default category, critical "Class I", and "Class II". According to the EU Commission, it is anticipated that a majority (around 90%) of products will fall under the 'default category'.

Are the Fears about the EU Cyber Resilience Act Justified?

Based on this product categorization, the CRA introduces differentiated levels of security assessments. Most notably, "critical software" demands rigorous third-party evaluation. However, the categorization's scope is not always straightforward. Consider the example of hard drives: while generally classified under the default category, ambiguity arises when these hard drives are employed in cloud data centers handling sensitive data. This grey area highlights the need for more nuanced guidelines within the Act.

One aspect of the CRA that stands out is its stringent approach to enforcement through substantial financial penalties. Vendors operating in the EU single market face fines up to €15 million or 2.5% of their global revenue for non-compliance. This measure reflects a shift in perspective, treating security as a fundamental, non-negotiable aspect of product development, rather than a secondary consideration.

This emphasis on financial accountability is a strategic move by the EU. By assigning a tangible cost to cybersecurity risks — costs that some companies have historically been willing to absorb — the CRA aims to recalibrate the risk-reward equation in favor of enhanced security measures.

But this raises another fundamental question: who in the supply chain should be held accountable? Or said differently, who bears the risk?

Who Bears the Risk? The CRA's Stance on Responsibility

The CRA is unequivocal in assigning responsibility for digital product security: the onus lies with the manufacturers. In cases where the manufacturer and software producer are the same, this is straightforward. However, the act enters murky waters when it comes to open-source software. Defining security ownership for code written by one and reused by another presents a complex challenge.

As a reminder, open-source is a pillar of modern software. It typically accounts for 70% to 90% of code in Web and cloud applications — application security firm Synopsys found that 98% of applications analyzed using its service included open-source software, and 75% of the average codebase came from open-source projects. They also found that, on average, a software application relied on more than 500 open-source dependencies.

This underscores the significant challenge faced by nearly every commercial business in conducting necessary due diligence. They should ensure that all open-source components have been accurately evaluated.

Reactions from the Open-Source Community

The primary worry comes directly from the open-source community itself. Many prominent open-source projects express concern because the Cybersecurity Act appears to suggest that the responsibility of compliance should fall on the shoulders of open-source developers. This implies that if any commercially sold software in the EU market incorporates an open-source component, its creators could be held accountable for its security.

This literal interpretation could potentially create an unsustainable situation for those contributing to open-source projects.

However, it's important to note that the CRA does specifically exempt open-source software that is developed or supplied outside of commercial activities. The issue, though, seems to lie in how the CRA defines open-source activity. The act seems to be permeated with the notion that most open-source activity stems from "benevolent work," a perspective that is largely considered out-of-date in today's context.

As an example, projects receiving donations or with corporate contributors would not be considered benevolent work and fall under the act's purview. But this view couldn't be further from the reality: open-source and commercial activities are often intertwined in complex hybrid operating profiles. Many open-source companies are developing open-source products with permissive licenses, while they monetize their activity through the selling of support services and premium features.

Conversely, it is not uncommon for tech giants to employ full-time engineers to work exclusively on some of the biggest open-source projects.

This highlights a significant misalignment between EU lawmakers and the open-source community. Key players in the open-source field, such as OpenSSF and the Debian Foundation, have criticized the legislators for failing to consult them during the drafting of the act.

The Future of Open-Source Under the CRA

Despite prevailing concerns, it's unlikely that the Cyber Resilience Act will signal the end of open-source software in the European Union. It's true that current versions of the CRA, don't explicitly define its scope. However, this doesn't preclude the possibility of future amendments.

The potential upheaval caused by mandating every software producer to scrutinize all its open-source components is simply too vast. We anticipate that the largest industry enterprises in the single market, all heavily reliant on software, will wield their considerable lobbying power to influence the law in their favor upon recognizing the potentially catastrophic impact. The stakes are too high, and the risk of damaging Europe's competitive edge is enormous.

Even if these efforts fail, there may well be grounds to challenge the law in court due to the ambiguities present in the text. Consequently, we can expect to see the language of the law refined in the coming months. Ideally, this will occur through close collaboration with leading open-source organizations.

Conclusion: A Regulatory Milestone with Challenges Ahead

The Cybersecurity Act (CRA) represents a significant milestone in the European Union's (EU) regulatory evolution, with the goal of unifying cybersecurity standards across its market. More than just a regulatory measure, the CRA is a political statement, intentionally timed to demonstrate the EU's commitment to combating cyber threats. The Act's broad scope and rapid implementation schedule can be largely attributed to the current geopolitical turbulence.

The CRA enforces security measures throughout a product's lifecycle, compelling manufacturers to prioritize cybersecurity. This bold move is essential for enhancing digital security within the EU. However, the Act's wide scope and numerous ambiguities have also created concerns. Are the fears of open-source organizations bearing the burden of security responsibility justified?

While it is ultimately up to you to form an opinion, we believe that these fears are not entirely justified, although there is some uncertainty. The existence of legal gaps and the potentially significant consequences for the EU economy if the law is strictly enforced in its current state are valid arguments for future refinements. These refinements should aim to enhance, rather than impede, the innovation and resilience that open-source technology brings to the digital landscape. However, achieving this will require vigilance.

In conclusion, the Cybersecurity Act represents a crucial step towards a more secure digital environment in the EU. While challenges and ambiguities exist, it is essential to strike a balance that encourages innovation while ensuring robust cybersecurity measures.

*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Automated Secrets Detection authored by Thomas Segura. Read the original post at: https://blog.gitguardian.com/are-the-fears-about-the-eu-cyber-resilience-act-justified/

December 1, 2023December 1, 2023 Thomas Segura Frameworks & Regulations

Thomas Segura

What You Need to Scale AppSec Thomas Segura - Content Writer @ GitGuardian Author Bio Thomas has worked both as an analyst and as a software engineer consultant for various big French companies. His passion for tech and open source led him to join GitGuardian as technical content writer. He focuses now on clarifying the transformative changes that cybersecurity and software are going through. Website:https://www.gitguardian.com/ Twitter handle: https://twitter.com/GitGuardian Linkedin: https://www.linkedin.com/company/gitguardian Introduction Security is a dilemma for many leaders. On the one hand, it is largely recognized as an essential feature. On the other hand, it does not drive business. Of course, as we mature, security can become a business enabler. But the roadmap is unclear. With the rise of agile practices, DevOps and the cloud, development timeframes have been considerably compressed, but application security remains essentially the same. DevSecOps emerged as an answer to this dilemma. Its promise consists literally in inserting security principles, practices, and tools into the DevOps activity stream, reducing risk without compromising deliverability. Therefore there is a question that many are asking: why isn't DevSecOps already the norm? As we analyzed in our latest report DevSecOps: Protecting the Modern Software Factory, the answer can be summarized as follows: only by enabling new capacities across Dev, Sec and Ops teams can the culture be changed. This post will help provide a high-level overview of the prerequisite steps needed to scale up application security across departments and enable such capabilities. From requirements to expectations Scaling application security is a company-wide project that requires thorough thinking before an y decision is made. A first-hand requirement is to talk to product and engineering teams to understand the current global AppSec maturity. The objective at this point is to be sure to have a comprehensive understanding of how your products are made (the processes, tools, components, and stacks involved). Mapping development tools and practices will require time to have the best visibility possible. They should include product development practices and the perceived risk awareness/appetite from managers. One of your objectives would be to nudge them so they take into account security in every decision they make for their products, and maybe end up thinking like adversaries. You should be able to derive security requirements from the different perceptual risks you are going to encounter. Your job is to consolidate these into a common set for all applications, setting goals to align the different teams collaborating to build your product(s). Communicating transparently with all relevant stakeholders (CISO, technical security, product owner, and development leads) about goals and expectations is essential to create a common ground for improvement. It will be absolutely necessary to ensure alignment throughout the implementation too. Open and accessible guardrails Guardrails are the cornerstone of security requirements. Their nature and implementation are completely up to the needs of your organization and can be potentially very different from one company to the other (if starting from scratch, look no further than the OWASP Top10). What is most important, however, is that these guardrails are open to the ones that need them. A good example of this would be to centralize a common, security-approved library of open-source components that can be pulled from by any team. Keep users' accessibility and useability as a priority. Designing an AppSec program at scale requires asking “how can we build confidence and visibility with trusted tools in our ecosystem?”. For instance, control gates should never be implemented without considering a break-glass option (“what happens if the control is blocking in an emergency situation?”). State-of-the-art security is to have off-the-shelf secure solutions chosen by the developers, approved by security, and maintained by ops. This will be a big leap forward in preventing vulnerabilities from creeping into source code. It will bring security to the masses at a very low cost (low friction). But to truly scale application security, it would be silly not to use the software engineer's best ally: the continuous integration pipeline. Embed controls in the CI/CD AppSec testing across all development pipelines is the implementation step. If your organization has multiple development teams, it is very likely that different CI/CD pipelines configurations exist in parallel. They may use different tools, or simply define different steps in the build process. This is not a problem per se, but to scale application security, centralization and harmonization are needed. As illustrated in the following example CI/CD pipeline, you can have a lot of security control steps: secrets detection, SAST, artifact signing, access controls, but also container or Infrastructure as Code scanning (not shown in the example) (taken from the DevSecOps whitepaper) The idea is that you can progressively activate more and more control steps, fine-tune the existing ones and scale both horizontally and vertically your “AppSec infrastructure”, at one condition: you need to centralize metrics and controls in a stand-alone platform able to handle the load corresponding to your organization’s size. Security processes can only be automated when you have metrics and proper visibility across your development targets, otherwise, it is just more burden on the AppSec team's shoulders. In turn, metrics and visibility help drive change and provide the spark to ignite a cultural change within your organization. Security ownership shifts to every engineer involved in the delivery process, and each one is able to leverage its own deep (yet partial) knowledge of the system to support the effort. This unlocks a world of possibilities: most security flaws can be treated like regular tickets, rule sets can be optimized for each pipeline based on criticality, capabilities or regulatory compliance, and progress can be tracked (saved time, avoided vulnerabilities etc.). In simpler terms, security can finally move at the DevOps speed. Conclusion Security can’t scale if it’s siloed, and slowing down the development process is no longer an option in a world led by DevOps innovation. The design and implementation of security controls are bound to evolve. In this article, we’ve depicted a high-level overview of the steps to be considered to scale AppSec. This starts with establishing a set of security requirements that involve all the departments, in particular product-related ones. From there it becomes possible to design guardrails to make security truly accessible with a mix of hard and soft gates. By carefully selecting automated detection and remediation that provide visibility and control, you will be laying a solid foundation for a real model of shared responsibility for security. Finally, embedding checks in the CI/CD system can be rolled out in multiple phases to progressively scale your security operations. With automated feedback in place, you can start incrementally adjusting your policies. A centralized platform creates a common interface to facilitate the exchange between application security and developer teams while enforcing processes. It is a huge opportunity to automate and propagate best practices across teams. Developers are empowered to develop faster with more ownership. When security is rethought as a partnership between software-building stakeholders, a flywheel effect can take place: reduced friction leads to better communication and visibility, automating of more best practices, easing the work of each other while improving security with fewer defects. This is how application security will finally be able to scale through continuous improvement.

thomas-segura has 62 posts and counting.See all posts by thomas-segura