EU Cyber Resilience Act: What does it mean for open source?

>>ahuber+(OP)
It appears that targeted exceptions have been added for specific situations lobbied by current FOSS and commercial stakeholders. Hopefully there will be an ongoing process to address the need for new exclusions, as the vast scope of the CRA becomes clear to societies eaten by software.

New OSS governance and runtime binary attestation (aka DRM) layers are being defined by the CRA, e.g. only specific attested binaries from open-source trees that follow specific development practices would be allowed to run in critical systems:

  Open-source software stewards shall put in place and document in a verifiable manner a cybersecurity policy to foster the development of a secure product with digital elements as well as an effective handling of vulnerabilities by the developers of that product.

  … Open-source software stewards shall cooperate with the market surveillance authorities, at their request, with a view to mitigating the cybersecurity risks posed by a product with digital elements qualifying as free and open-source software.

  … security attestation programmes should be conceived in such a way that … third-parties, such as manufacturers that integrate such products into their own products, users, or European and national public administrations [can initiate or finance an attestation].

Legal liability and certification for commercial sale of binaries built from FOSS software will alter business models and incentives for FOSS development.

>>transp+K6
> New OSS governance and runtime binary attestation (aka DRM) layers are being defined by the CRA, e.g. only specific attested binaries from open-source trees that follow specific development practices would be allowed to run in critical systems

That doesn't seem like what the CRA stipulates. I think it's more about manual attestation in its most traditional meaning, i.e, an organization attests that X software is secure.

>>EMIREL+Ra
> That doesn't seem like what the CRA stipulates. I think it's more about manual attestation in its most traditional meaning, i.e, an organization attests that X software is secure.

CRA can require EU-wide recall of "products with digital elements" which are found to be non-compliant by national market surveillance. While we may analogize this requirement to the recall of slow-moving physical products with rare market withdrawal, software developers and attackers iterate more quickly.

Centralized software distribution like mobile app stores would have the ability to implement a kill switch (recall) on non-compliant products. Products which depend on centralized cloud services could have binaries verified before they are allowed to connect to an API. This would give regulators the tools to rapidly implement software "recalls".

  (58) … significant cybersecurity risk or pose a risk to the health or safety of persons … market surveillance authorities should take measures to require the economic operator to ensure that the product no longer presents that risk, to recall it or to withdraw it …

  (60) … market surveillance authorities should be able to carry out joint activities with other authorities, with a view to verifying compliance and identifying cybersecurity risks of products with digital elements. 

  (61) Simultaneous coordinated control actions (‘sweeps') are specific enforcement actions by market surveillance authorities that can further enhance product security.

>>transp+Sd
So what would you propose for recalling physical products that have insecure software that can cause physical trouble? What framework would have sufficed?

zlacker