The new EU legislation will mean a new business model for many products
Free and open software is a major part of any software product today, whether it is an embedded system, an IoT sensor, a mobile app or a major cloud service. The cost of using these components in a commercial product has been almost zero compared with developing all the code within the company. The new EU legislation, the EU Cyber Resilience Act (CRA), will mean a change in the business model for almost any company that place products on the EU market. Each third-party component used will have a cost, defined as a cost per dependency.
The vendor will be responsible for all components
The EU CRA is focusing on transparency, risk based security management and a process of managing the security of a product during the expected lifetime. This means that the responsibility for all components included in a product will be the vendor’s. If the product is placed on the market by a company that imports it from other parts of the world, the importer gets the same responsibility as a manufacturer.
Keeping the product secure is a new work stream
This new requirement will mean that each component needs to be constantly managed. If there’s a vulnerability, it needs an update. If there’s no update, the manufacturer will have to produce a fix. For a product with a large amount of components, like an embedded system with Linux, there will be issues to manage every week, if not every day. Security fixes should be publicly published (not only to existing customers) and updates should happen automatically (if the customer has not turned it off). Keeping the product secure and up to date is no longer a short-time project, it is a constant process during the life time of the product – at customer’s site. End-of-life of a product in the sales channels does not imply that the security updates will not happen any more.
The cost per dependency needs to be under control and managed at all times. Free software is and will always be free, but nevertheless, it comes with a cost.
Being ready to handle critical vulnerabilities and exploits
If there is a critical vulnerability that has been exploited in the customer base, the action required by the CRA involves interaction with the country C-CERT. An issue like this needs to be reported within 72 hours and customers needs to be alerted. This applies every day of the year, including public holidays and vacations.
Vulnerability management is a process, not a short-term project
This means that for a given product, all components needs to be monitored and many of them will have to be updated to a supported version. This may mean API changes, that will require new code in the software. The development team needs to be on call and work on the code constantly to keep it secure and not put the users in a risky position. At the heart of the process is the bill of materials (BOM) for software (SBOM), hardware (HBOM) as well as for cryptography (CBOM).
CRA means long term effects on the business model
Previously the cost of development was mainly an issue before product launch, a huge investment made to create a new product. After that, additional development only happened when new features where required or bug fixes needed. For many products, no developers where ready and standing by to work on the code.
The CRA will mean that development is a constant process. Customers has the right to free security updates during a product’s lifetime. This will of course mean a higher price on the sales of the product. In some cases, trying to add a recurring fee for users will help managing the cost during a product’s lifetime. The fee will not apply to security updates, but can include support, feature updates and other services, like online automatic access to SBOMs for the products the customer has bought.
Keeping the number of components under control
In order to keep the cost under control, each and every component needs a due diligence before being integrated. Does the vendor or project actually manage vulnerabilities? Will the manufacturer get up to date SBOMs automatically from the upstream vendor?
The most basic question is of course if the full component is really needed? What is the alternative? Each component needs to be managed, monitored and kept up to date during the life time of the product. While the savings may be good at initial development the costs may be high as seen from a total lifetime of a product. For many open source components, building a limited binary with limited functionality may reduce the number of dependencies and thus the number of components required.
The cost per dependency needs to be under control and managed at all times. Free software is and will always be free, but nevertheless, it comes with a cost.
Olle E. Johansson
