This blog is the ninth of our Tales From the Trenches: CRA Lessons Learned blog series. Our objective in developing these blogs is to help manufacturers, software vendors, and connected-product providers understand practical implementation realities of CRA compliance programs. We will draw on lessons we have learned from working with our customers and in talking to industry leaders. Organizations are learning that sustainable compliance requires governance, visibility, accountability, and lifecycle management capabilities that extend well beyond traditional cybersecurity activities. Building a secure product is not enough to achieve CRA compliance.
Why the Cyber Resilience Act Is Elevating Software Supply Chain Risk to an Executive Priority
For years, use of open-source software was largely considered an engineering decision.
Developers selected libraries. Architects approved frameworks. Security teams tracked vulnerabilities. Product teams focused on functionality and delivery schedules. Most executives rarely needed to think about the hundreds of open-source components embedded within their products.
Those days have ended.
The European Union’s Cyber Resilience Act (CRA) is changing how organizations think about software supply chains including open-source software. What was once viewed primarily as a technical issue is increasingly becoming a business, compliance, and governance issue.
Why Open Source Is Different
Open-source software powers virtually every connected product. Unlike commercial software, manufacturers typically have no contractual relationship with the developers who create and maintain it. Many open-source projects have no commercial support, no guaranteed maintenance, and no service-level commitments.
Organizations are increasingly expected to understand the software that powers their products, maintain visibility into dependencies, respond rapidly to vulnerabilities, and demonstrate ongoing governance throughout the product lifecycle. Under the CRA, this extends beyond software developed in-house or licensed from commercial vendors to include open-source software.
This reality is pushing conversations about open-source software out of engineering teams and into executive leadership meetings, compliance reviews, audit committees, and boardrooms. The issue is not that open-source software is inherently risky. The issue is visibility and accountability.
Executive Insights
A critical lesson emerging from CRA readiness programs is that software supply chain risk has become a business risk. Historically, organizations focused on whether open-source software accelerated development, reduced costs, or improved product functionality.
Boards should ask not only what open-source components are used in their products; they must also consider the impact that open-source software components have on CRA compliance. This means determining whether those open-source projects are actively maintained, how mature they are, whether they have commercial backing, if there are vulnerability reporting processes in place, how quickly vulnerabilities are remediated, and whether unsupported or abandoned components remain in shipping products. To the extent that there are gaps in support, companies must determine if they can address these gaps internally. In some cases, large enterprises have chosen to join or support open-source projects to help create sustainable processes for vulnerability reporting and mitigation.
These are not engineering questions. They are governance and management questions. Under the CRA, organizations are required to demonstrate visibility into software dependencies, maintain vulnerability management processes, support coordinated disclosure activities, and provide evidence of ongoing cybersecurity governance.
As a result, many leadership teams are discovering that use of open-source software directly affects regulatory compliance, customer trust, product security, brand reputation, and long-term support obligations.
Why Open Source Has Become a CRA Challenge
Open-source software itself is not the problem. In fact, modern software development would be nearly impossible without it. The challenge is that many open-source projects have no commercial support, no guaranteed maintenance, and no service-level commitments.
Vulnerabilities Can Impact Multiple Products
A vulnerability discovered in a widely used open-source component can affect hundreds of products across multiple business units. Organizations must be able to rapidly identify affected products, impacted versions, customer exposure, and available mitigations.
Without visibility, response times increase dramatically.
Long-Term Support Creates Accountability
The CRA emphasizes lifecycle responsibility. Organizations must be prepared to manage software dependencies throughout the supported life of a product. This creates difficult questions regarding open-source software. These include determining if the company is using unsupported or abandoned open-source projects, how vulnerabilities in open-source software are tracked, and how the company can mitigate vulnerabilities found in open-source software. Can the company update the open-source software itself? Or can they find contractors or companies who provide long-term support for critical open-source components?
Widespread usage of Open-Source Software
Organizations are increasingly dependent on open-source software. When people think of open-source software, they usually think of major projects like OpenSSL, Linux, or PostgreSQL. In reality, those are only the tip of the iceberg.
A single application typically includes programming language runtime libraries, development frameworks (Spring, .NET OSS packages, React, Angular, etc.), cryptographic libraries, networking libraries, build tools, JSON/XML parsers, and logging frameworks. Each of these, in turn, may depend on dozens of package dependencies.
Real-World Examples
As with in-house developed software, visibility into use of open-source software is a challenge for many organizations. When a critical vulnerability is announced in a widely used open-source library, security teams immediately begin asking whether the component exists within their products.
The answer should be simple. But without centralized and complete documentation, it is often a challenge. Each engineering team must search code repositories, documentation systems, and development environments to determine exposure. This can take days, which is a real problem given the CRA’s 24-hour reporting requirement.
This is further complicated by the nature of open-source projects. There is no contractual relationship with a supplier from whom companies can request information regarding software composition and vulnerability exposure. The manufacturer is often left on their own to determine their level of exposure.
Best Practices for Managing Open-Source Risk Under the CRA
Virtually all companies utilize open-source software in their products, even if executive teams are not aware that they do so. As a first step towards managing open-source software, CRA compliance teams should establish formal acceptance criteria for using open-source software. Important criteria include project maturity, maintainer activity, release cadence, security history, governance model, licensing, testing practices, and long-term viability.
While this is an important step, defining acceptance criteria for open-source projects is a forward-looking activity. This is helpful in managing use of open-source software in new product development efforts, but it does not address use of open-source software in legacy projects. Additional steps are required for open-source risk management programs designed to achieve CRA compliance.
Maintain Comprehensive SBOMs
Companies must maintain and update SBOMs throughout the full lifecycle of their products and must ensure that all use of open-source software is documented and monitored. Once the set of open-source software projects is identified, companies must plan for how they will manage and maintain these solutions to achieve CRA compliance.
Determine support and migration plans
Once companies have an inventory of the open-source solutions being used, they must determine how they will support these components. Companies may choose to migrate away from some open-source components, seek support from 3rd party companies supporting the open-source components (where possible), or plan to provide support for these components themselves.
Given the heavy dependencies upon open-source software, many companies are finding themselves between a rock and a hard place. Migration away from open-source software is often infeasible and providing support in-house may be equally impractical. As an alternative, some companies are choosing to financially support open-source projects. In other cases, they are able to contract with companies providing support for the open-source libraries.
Monitor Vulnerabilities Continuously
Organizations should continuously evaluate emerging vulnerabilities against software inventories and deployed products. Automation can significantly improve response speed.
Common Pitfalls
Several recurring mistakes appear across CRA readiness initiatives.
Treating all open-source software equally
There are thousands of open-source software projects with widespread use. These vary from projects created by a single developer to large, well-funded projects. For example, the Linux Foundation has an annual budget of over $300 million and supports over 1300 distinct open-source projects.
Given the number, size, and usage of projects, it is unsurprising that there is a vast difference in the level of quality and support between projects.
Assuming popularity equals quality
Widespread adoption of an open-source project is not a guarantee of higher quality or lower security risk. In some cases, the opposite is true. More popular projects attract a wider set of developers which may result in inconsistent coding quality, challenges in ensuring all new features and code changes are properly reviewed and tested, and a rush to add new features to support new use cases. These factors can contribute to lower code quality and the introduction of unexpected vulnerabilities.
Large, complex, and widely used open-source projects are also popular targets for bad-actors. As the software is published and easily downloadable, bad actors can analyze the code to attempt to find vulnerabilities that can be exploited in deployed systems. With new AI tools capable of scanning code for vulnerabilities, this risk is higher now than ever. Bad actors can also attempt to insert cleverly hidden back doors or vulnerabilities into open-source software by posing as legitimate developers. In large projects with many developers, the risk of malicious code being added without being noticed increases.
Relying on unsupported projects
While many open-source projects remain under active development, this is not true in all cases. Many open-source projects are created by a single developer or a small team seeking to solve a specific problem. Once the project is complete, the developers often move on to other projects and don’t continue to maintain the original code base.
For companies using these projects, this creates a long-term compliance risk. This is especially true for critical and long-lived products. A vulnerability may be discovered long after the project is abandoned. Any companies using the affected component are left on their own to deal with the issue. Depending upon the complexity of the open-source software, this can be a real challenge. They may not have internal developers with the required skills to fix the problem. Even if they have the required skills, it can take weeks to understand an unfamiliar code base, debug the problem, and architect a fix.
Treating SBOMs as Compliance Documents
SBOMs should serve as operational tools that support vulnerability management, product visibility, and lifecycle governance. While they are important documentation in a compliance program, they are just a starting point.
Action Items for OEMs and Software Vendors
Organizations seeking to address the use of open-source software in their CRA-readiness programs should consider the following actions.
Immediate Priorities
- Establish guidelines for use of open-source software.
- Create complete inventories of open-source software components across all products.
- Identify approved open-source software projects for continued use.
- Create migration plans to eliminate use of open-source software projects that are unsupported, abandoned, or considered high-risk.
- Create vulnerability monitoring programs for open-source software components that are used in company products.
- Create vulnerability response plans for open-source software components that are used in company products. This may include finding companies providing commercial support for these projects or developing in-house resources capable of supporting the software.
- Consider supporting open-source projects that are critical to the company.
- Assign ownership for open-source software usage within the company.
- Document open-source software usage policies and vulnerability mitigation plans.
Open-source software is not going away, but organizations need continuous visibility into the software components within their products and the risks they introduce. As products, dependencies, and vulnerabilities change, that understanding must change with them.
How OmniTrust Certify Can Help
Open-source software is not going away, but organizations need continuous visibility into the software components within their products and the risks they introduce. As products, dependencies, and vulnerabilities change, that understanding must change with them.
OmniTrust Certify creates a living product profile that connects software composition, vulnerabilities, cyber risk, regulatory requirements, controls, and evidence throughout the product lifecycle.
With OmniTrust Certify, organizations can:
- Generate SBOMs from source code, binaries, or firmware, or ingest existing SBOMs
- Identify open-source and third-party software components and dependencies
- Continuously monitor emerging vulnerability intelligence and match new vulnerabilities to affected products
- Assess how identified vulnerabilities affect product cybersecurity risk
- Track vulnerability review, treatment, mitigation, and supporting evidence
- Assess products against CRA requirements and other applicable regulations and standards
- Continuously reassess as products, components, vulnerabilities, and requirements change
Rather than treating the SBOM as a static compliance document, Certify connects it to a living product record that helps organizations understand what is in their products, what is vulnerable, what is at risk, and what needs to be done about it.
Summary: Open-source software remains one of the greatest accelerators of innovation. The CRA does not discourage its use, but it requires organizations to manage it responsibly. Unlike commercial software, organizations inherit responsibility without control. Successful manufacturers will understand not only what open-source software they use, but also the maturity, health, supportability, and ongoing security posture of every critical dependency. That is why open-source software has become a boardroom issue.
Subscribe to the Blog on our blog homepage for notifications on future blogs in this series which continues with “Blog #10: Assessment Is Easy. Remediation is Hard.”
