EU Cyber Resilience Act

A few months ago, EU finally finalized the Cyber Resilience Act (CRA) which aims to put essential security requirements on all “products with digital elements” in order to increase security for both consumers and businesses. There are special rules for free open source software to not burden them with compliance, but there are some light requirements on “open-source software stewards”, which is defined as

“a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products”

I’m not sure the if the openHAB foundation qualifies for this, since the Eclipse license allows for commercial use, but OH is not “intended” for it.

This is not, however, the issue I wish to address. I know from this forum, however, that there are several people who use OH for commercial purposes, and they will be considered as manufacturers according to the regulation and need to comply with all the requirements. Personally, i don’t wish for them to be individually responsible for all those requirements, which for some might be overwhelming and lead to discontinuation of their business ventures.

Instead I hope that we as a community can collaborate on some of the the requirements, to ease the burden on these individuals allowing them and others to continue their businesses. I work as a cybersecurity consultant myself, and have read up on the legislation quite a bit since it affect many of our customers. There are several things I can see that we as a community could contribute with to enable people to use OH in their businesses in an easy way:

  1. Create and publish a Software Bill of Materials (SBOM) in a standard format (SPDX or CycloneDX) for every major release. Since we are using Maven for dependencies, this should be quite straight forward to do in Jenkins or a Github action.
  2. Create documentation on the architecture of OH, on a high level, to show how the different parts of the system interacts.
  3. Based on the architecture diagrams, create a threat model and risk analysis, to discover both areas of improvement in OH itself, and/or serve as a manual for those who use OH in where they need to take extra care of security.

I can gladly look into #1, but would like to get some input on if this should be done for OH Core/Addons/UI etc separately, or if it should be done on the OH distro? (I could experiment a bit to see what’s viable, but if anyone can help with reasoning it is very welcome).

I have a basic grasp of #2, but will definitely need help from the people who have better knowledge of how things fit together.

#3 would be best done in a collaborative way between people who have good knowledge of different parts of OH (mainly UI and Core) and people who know security (I know that there are others beside myself who work in this area). If we could gather a few of these people (physically or virtually) that would likely be the best and hopefully interesting to all involved, I would live to be a part of this.

Hope that we can make the best of this in the interest of all current and future OH users!

4 Likes

Hopefully this doesnt end up like a lot of EU legislation
Ignored, adopted wholesale without thought or extended(something UK often did).

It probably has to be done at each repo individually and then aggregated up to the distro repo.

It depends on how deep this needs to go and what they mean by “documentation on the architecture”. If they just want a couple of high level diagrams that’s one thing. If they want something in Zachman or TOGAF that’s a whole other kettle of fish.

I’m a professional computer security engineer can contribute some. I’m also very familiar with ATT&CK, though that’s probably a step beyond what’s needed here. But I know nothing of EU regs and this one frankly looks like another way to snuff out FOSS. :man_shrugging:

1 Like

FOSS is explicitly exempted from all requirements, so legally we don’t need to do anything, the burden falls entirely on those who use the FOSS in their commercial products.

Why I raised this is because I know there are at least a few individuals who do just that, and it may be difficult for them to interpret the regulation and provide the correct documentation.

This is something that is not very clear at the moment, but there are a three year grace period before the regulation is in effect, so will hopefully be more clear later on. (Meaning there’s no rush do do this, maybe considered if/when updating the documentation for other reasons). There will be lighter documentation requirements for small- and micro enterprises however, which is IMO what should be the target here. If any larger corporation wants to base a product on OH, they should have sufficient resources to do this on their own. My guess, the high level diagrams should be enough.

1 Like