This Epic collects information related to the Cyber Resilience Act (CRA) and serves as our tracking issue on our path to full compliance.
We consider ourselves a manufacturer for our product Stackable Data Platform (SDP).

It is up-to-date with the final version as published in the Official Journal of the European Union on 20 November 2024.

Motivation

At Stackable we've engaged with policy makers on the CRA since the end of 2023 via OpenForumEurope, Bitkom, Open Source Business Alliance (OSBA). We have provided input and comments and engaged with the open source community to get changes to the CRA accepted.

We have joined CEN JTC 13 WG9 via DIN: Special Working Group on Cyber Resilience Act from the european standardisation organisation CEN which has the official mandate from the European Commission to work on the standards that can help organizations with compliance with the CRA.

Additionally we are members of Ecma International TC54 working on the standardisation of the Software Bill of Materials standard CycloneDX.

And last but not least we have been nominated as members of the European Commission's Expert Group on Cybersecurity of Products with Digital Elements (also known as: CRA Expert Group).

We begun working towards CRA compliance at the beginning of 2024 and plan on being fully compliant when all obligations come into effect in 2026 and 2027 respectively.

Implementation Notes

• When implementing make sure to add links to evidence in this ticket

Applicability

According to article 69 we might consider SDP as not in scope for the CRA for now:

2. Products with digital elements that have been placed on the market before 11 December 2027 shall be subject to the requirements set out in this Regulation only if, from that date, those products are subject to a substantial modification.
3. By way of derogation from paragraph 2 of this Article, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027.

The concept of "substantial modification" is defined as

‘substantial modification’ means a change to the product with digital elements following its placing on the market, which affects the compliance of the product with digital elements with the essential cybersecurity requirements set out in Part I of Annex I or which results in a modification to the intended purpose for which the product with digital elements has been assessed;

So, by 11 December 2027 our SDP 27.11 should be released and does not need to comply with the CRA and as long as all future versions do not contain "substantial modifications" we're good. There will be guidance upcoming by the commission to refine the definition and I don't want to rely on that vagueness.

So, for all intents and purposes I do consider SDP to be fully in-scope of the CRA.

We are not an important or critical product according to articles 7 and 8 respectively.

Obligations

This epic will be updated as the relevant standards become available.

In the meantime this lists the obligations from various articles and Annexes and connects them to tasks we can tackle.
Each obligation contains the original text from the CRA, potentially a short assessment from us as well as a list of tasks.
These tasks can be found again below in the Tasks section which contains a list of all tasks in a deduplicated and categorised fashion. These will later be converted into sub-issues.

Article 13: Obligations of manufacturers

Paragraph 1: Essential Cybersecurity Requirements

Original text from the CRA

When placing a product with digital elements on the market, manufacturers shall ensure that it has been designed, developed and produced in accordance with the essential cybersecurity requirements set out in Part I of Annex I.

Analysis

As per Article 27 paragraph 1 there will be harmonised standards that allow presumption of conformity with the essential cybersecurity requirements from Annex I, Part I. But these might only be available for a subset of product categories where a vertical standard is made available.

It is unclear right now how to prove conformity for the rest of us (i.e. products from the default category without any vertical standard).

Tasks

• TODO

Paragraphs 2-4: Risk Assessment

Original text from the CRA

2. For the purpose of complying with paragraph 1, manufacturers shall undertake an assessment of the cybersecurity risks associated with a product with digital elements and take the outcome of that assessment into account during the planning, design, development, production, delivery and maintenance phases of the product with digital elements with a view to minimising cybersecurity risks, preventing incidents and minimising their impact, including in relation to the health and safety of users.

3. The cybersecurity risk assessment shall be documented and updated as appropriate during a support period to be determined in accordance with paragraph 8 of this Article. That cybersecurity risk assessment shall comprise at least an analysis of cybersecurity risks based on the intended purpose and reasonably foreseeable use, as well as the conditions of use, of the product with digital elements, such as the operational environment or the assets to be protected, taking into account the length of time the product is expected to be in use. The cybersecurity risk assessment shall indicate whether and, if so in what manner, the security requirements set out in Part I, point (2), of Annex I are applicable to the relevant product with digital elements and how those requirements are implemented as informed by the cybersecurity risk assessment. It shall also indicate how the manufacturer is to apply Part I, point (1), of Annex I and the vulnerability handling requirements set out in Part II of Annex I.

4. When placing a product with digital elements on the market, the manufacturer shall include the cybersecurity risk assessment referred to in paragraph 3 of this Article in the technical documentation required pursuant to Article 31 and Annex VII. For products with digital elements as referred to in Article 12, which are also subject to other Union legal acts, the cybersecurity risk assessment may be part of the risk assessment required by those Union legal acts. Where certain essential cybersecurity requirements are not applicable to the product with digital elements, the manufacturer shall include a clear justification to that effect in that technical documentation.

Analysis

There will be a standard on this but it will not offer presumption of conformity.

Tasks

• CRA-002
• CRA-003
• CRA-004
• CRA-005
• CRA-006
• CRA-007
• CRA-008

Open Questions

• It is not yet entirely clear to me how we can prove conformity

Paragraph 5: Due dilligence when integrating third-party components

Original text from the CRA

For the purpose of complying with paragraph 1, manufacturers shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements, including when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity.

Analysis

The horizontal standard "Cybersecurity requirements for products with digital elements - General principles for cyber resilience" might cover parts of this.

Some possible things which can be included in this policy/process are:

• Ensure authenticity & integrity of integrated components
• Ensure Licence compliance
• Include third-party components in the vulnerability management
• If possible consider lifecycle policies (e.g. support period) of third-party components
  • TODO: Find out if there is a machine-readable standard already to declare some of this (e.g. OpenEoX, OWASP CLE)

Tasks

• CRA-009

Open Questions

• How is "due dilligence" defined?

Paragraph 6: Upstream vulnerabilities

Original text from the CRA

Manufacturers shall, upon identifying a vulnerability in a component, including in an open source-component, which is integrated in the product with digital elements report the vulnerability to the person or entity manufacturing or maintaining the component, and address and remediate the vulnerability in accordance with the vulnerability handling requirements set out in Part II of Annex I. Where manufacturers have developed a software or hardware modification to address the vulnerability in that component, they shall share the relevant code or documentation with the person or entity manufacturing or maintaining the component, where appropriate in a machine-readable format.

Tasks

• CRA-009

Paragraph 7: Document Cybersecurity Aspects

Original text from the CRA

The manufacturers shall systematically document, in a manner that is proportionate to the nature and the cybersecurity risks, relevant cybersecurity aspects concerning the products with digital elements, including vulnerabilities of which they become aware and any relevant information provided by third parties, and shall, where applicable, update the cybersecurity risk assessment of the products.

Tasks

• CRA-010
• TODO: Document vulnerabilities -> we have that, do we need to make this public? Not that we're afraid to, it's all public anyway but we haven't planned a single page to list all vulnerabilities. This
• TODO: Document information provided by third parties

Open Questions

• It is still unclear to me who the audience for this documentation is, customers, internal only, or market surveillance authorities?
• Does this documentation need to be public?
• It is still unclear to me whether vulnerabilities in third-party components need to be listed or whether it's only first-party vulnerabilities
• It is unclear to me what "information provided by third parties" refers to

Paragraph 8: Support Period

Original text from the CRA

Manufacturers shall ensure, when placing a product with digital elements on the market, and for the support period, that vulnerabilities of that product, including its components, are handled effectively and in accordance with the essential cybersecurity requirements set out in Part II of Annex I.

Manufacturers shall determine the support period so that it reflects the length of time during which the product is expected to be in use, taking into account, in particular, reasonable user expectations, the nature of the product, including its intended purpose, as well as relevant Union law determining the lifetime of products with digital elements. When determining the support period, manufacturers may also take into account the support periods of products with digital elements offering a similar functionality placed on the market by other manufacturers, the availability of the operating environment, the support periods of integrated components that provide core functions and are sourced from third parties as well as relevant guidance provided by the dedicated administrative cooperation group (ADCO) established pursuant to Article 52(15) and the Commission. The matters to be taken into account in order to determine the support period shall be considered in a manner that ensures proportionality.

Without prejudice to the second subparagraph, the support period shall be at least five years. Where the product with digital elements is expected to be in use for less than five years, the support period shall correspond to the expected use time.

Taking into account ADCO recommendations as referred to in Article 52(16), the Commission may adopt delegated acts in accordance with Article 61 to supplement this Regulation by specifying the minimum support period for specific product categories where the market surveillance data suggests inadequate support periods.

Manufacturers shall include the information that was taken into account to determine the support period of a product with digital elements in the technical documentation as set out in Annex VII.

Manufacturers shall have appropriate policies and procedures, including coordinated vulnerability disclosure policies, referred to in Part II, point (5), of Annex I to process and remediate potential vulnerabilities in the product with digital elements reported from internal or external sources.

Analysis

Our support period is either ~1 year or 5-10 years depending on the definition.
We reasonably expect users to update at least once a year to a new version.
Our underlying platform (Kubernetes) itself releases three (or more) times a year and only provides support for about a year which is what leads us to the expectation that users will update at least once a year.
We fully expect some organisations to delay updates for reasons out of our control for a while but we do not expect anyone to run a version that is older than two years.

Once the Stackable Data Platform is in use we expect a (regularly updated) version of it to be in use for at least 5 - 10 years.

This leads us to a support period of 1 year but there are open questions on the support period for continuously updated products.

Tasks

• CRA-011
• CRA-012
• CRA-013

Open Questions

• It is still an open question for me how the support period is determined for continuously updated products
• The essential cybersecurity requirements are still a bit unclear but also tracked elsewhere

Paragraph 9: Update Availability

Original text from the CRA

Manufacturers shall ensure that each security update, as referred to in Part II, point (8), of Annex I, which has been made available to users during the support period, remains available after it has been issued for a minimum of 10 years or for the remainder of the support period, whichever is longer.

Part II, point(8), Annex I:

ensure that, where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements, free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken.

Tasks

• CRA-014

Open Questions

• What is considered a security update?
  • If we release a new version of our software every four month and they include security updates: Are they considered security updates and need to be kept? Or are these "just" new versions
    • Later paragraphs seem to distinguish between updates and "historical versions"

Paragraph 10: Support latest version only

Original text from the CRA

Where a manufacturer has placed subsequent substantially modified versions of a software product on the market, that manufacturer may ensure compliance with the essential cybersecurity requirement set out in Part II, point (2), of Annex I only for the version that it has last placed on the market, provided that the users of the versions that were previously placed on the market have access to the version last placed on the market free of charge and do not incur additional costs to adjust the hardware and software environment in which they use the original version of that product.

Annex I, Part II, point (2):

in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates;

Analysis

Should we be required to support 5 year old versions (depends on support period) then we should absolutely make this a paid feature as it will be very expensive for us to do and will distract from building the actual product and making the current one safer.

Tasks

• None?

Open Questions

• What is a "substantial modification"?
  • There is a definition for this in the CRA but we need to make our minds up what that means for our product or find external guidance.
  • Relates to "intended purpose"
• What are "additional" costs? We do not want to encourage customers to stay on old Kubernetes versions, this would be a cybersecurity risk in itself but forcing customers to newer Kubernetes versions might incur costs "additional" costs.

Paragraph 11: Software Archive / Historical Versions

Original text from the CRA

Manufacturers may maintain public software archives enhancing user access to historical versions. In those cases, users shall be clearly informed in an easily accessible manner about risks associated with using unsupported software.

Tasks

• CRA-015

Paragraph 12: Conformity Assessment / Technical Documentation / CE marking

Original text from the CRA

Before placing a product with digital elements on the market, manufacturers shall draw up the technical documentation referred to in Article 31.

They shall carry out the chosen conformity assessment procedures as referred to in Article 32 or have them carried out.

Where compliance of the product with digital elements with the essential cybersecurity requirements set out in Part I of Annex I and of the processes put in place by the manufacturer with the essential cybersecurity requirements set out in Part II of Annex I has been demonstrated by that conformity assessment procedure, manufacturers shall draw up the EU declaration of conformity in accordance with Article 28 and affix the CE marking in accordance with Article 30.

Tasks

• TODO: Link tasks created for Articles 30-32 below

Paragraph 13: Retain declaration of conformity

Original text from the CRA

Manufacturers shall keep the technical documentation and the EU declaration of conformity at the disposal of the market surveillance authorities for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer.

Tasks

• CRA-016

Paragraph 14: Series of Production

Original text from the CRA

Manufacturers shall ensure that procedures are in place for products with digital elements that are part of a series of production to remain in conformity with this Regulation. Manufacturers shall adequately take into account changes in the development and production process or in the design or characteristics of the product with digital elements and changes in the harmonised standards, European cybersecurity certification schemes or common specifications as referred to in Article 27 by reference to which the conformity of the product with digital elements is declared or by application of which its conformity is verified.

Analysis

I believe we are unaffected by this paragraph.

Paragraph 15: Identification

Original text from the CRA

Manufacturers shall ensure that their products with digital elements bear a type, batch or serial number or other element allowing their identification, or, where that is not possible, that that information is provided on their packaging or in a document accompanying the product with digital elements.

Analysis

Our product consists of a bunch of Docker/OCI images.
Each image already contains a tag uniquely identifying it.
All our images also contain a common set of labels allowing them to be identified easily.

I can't think of anything else to do here.

Paragraph 16: Affix contact information

Original text from the CRA

Manufacturers shall indicate the name, registered trade name or registered trademark of the manufacturer, and the postal address, email address or other digital contact details, as well as, where applicable, the website where the manufacturer can be contacted, on the product with digital elements, on its packaging or in a document accompanying the product with digital elements. That information shall also be included in the information and instructions to the user set out in Annex II. The contact details shall be in a language which can be easily understood by users and market surveillance authorities.

Analysis

See paragraph 15.
All of our images already contain the required contact information in the common labels.

Paragraph 17: Single Point of Contact

Original text from the CRA

For the purposes of this Regulation, manufacturers shall designate a single point of contact to enable users to communicate directly and rapidly with them, including in order to facilitate reporting on vulnerabilities of the product with digital elements.

Manufacturers shall ensure that the single point of contact is easily identifiable by the users. They shall also include the single point of contact in the information and instructions to the user set out in Annex II.

The single point of contact shall allow users to choose their preferred means of communication and shall not limit such means to automated tools.

Tasks

• CRA-017
• CRA-018

Paragraph 18: Documentation

Original text from the CRA

Manufacturers shall ensure that products with digital elements are accompanied by the information and instructions to the user set out in Annex II, in paper or electronic form. Such information and instructions shall be provided in a language which can be easily understood by users and market surveillance authorities. They shall be clear, understandable, intelligible and legible. They shall allow for the secure installation, operation and use of products with digital elements. Manufacturers shall keep the information and instructions to the user set out in Annex II at the disposal of users and market surveillance authorities for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer. Where such information and instructions are provided online, manufacturers shall ensure that they are accessible, user-friendly and available online for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer.

Tasks

• CRA-016
• CRA-019
• TODO Have documentation according to Annex II

Paragraph 19: Document End of Life data

Original text from the CRA

Manufacturers shall ensure that the end date of the support period referred to in paragraph 8, including at least the month and the year, is clearly and understandably specified at the time of purchase in an easily accessible manner and, where applicable, on the product with digital elements, its packaging or by digital means.

Where technically feasible in light of the nature of the product with digital elements, manufacturers shall display a notification to users informing them that their product with digital elements has reached the end of its support period.

Tasks

• CRA-020: End-of-Support warning for products and operators #733
• CRA-021
• CRA-022

Paragraph 20: Declaration of Conformity

Original text from the CRA

Manufacturers shall either provide a copy of the EU declaration of conformity or a simplified EU declaration of conformity with the product with digital elements. Where a simplified EU declaration of conformity is provided, it shall contain the exact internet address at which the full EU declaration of conformity can be accessed.

Tasks

• CRA-023

Paragraph 21: Stay Conformant

Original text from the CRA

From the placing on the market and for the support period, manufacturers who know or have reason to believe that the product with digital elements or the processes put in place by the manufacturer are not in conformity with the essential cybersecurity requirements set out in Annex I shall immediately take the corrective measures necessary to bring that product with digital elements or the manufacturer’s processes into conformity, or to withdraw or recall the product, as appropriate.

Tasks

• CRA-024

Paragraph 22: Market Surveillance Authority Cooperation

Original text from the CRA

Manufacturers shall, upon a reasoned request from a market surveillance authority, provide that authority, in a language which can be easily understood by that authority, with all the information and documentation, in paper or electronic form, necessary to demonstrate the conformity of the product with digital elements and of the processes put in place by the manufacturer with the essential cybersecurity requirements set out in Annex I. Manufacturers shall cooperate with that authority, at its request, on any measures taken to eliminate the cybersecurity risks posed by the product with digital elements which they have placed on the market.

Analysis

This should be trivial for us once we've done all the other things.

Tasks

• CRA-001

Paragraph 23: Ceasing of operation

Original text from the CRA

A manufacturer that ceases its operations and, as a result, is not able to comply with this Regulation shall inform, before the cessation of operations takes effect, the relevant market surveillance authorities as well as, by any means available and to the extent possible, the users of the relevant products with digital elements placed on the market, of the impending cessation of operations.

Tasks

• CRA-025

Paragraph 24: SBOM Format

Original text from the CRA

The Commission may, by means of implementing acts taking into account European or international standards and best practices, specify the format and elements of the software bill of materials referred to in Part II, point (1), of Annex I. Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 62(2).

Analysis

No obligations in this for us other than keeping up-to-date with implementing acts which is already part of the bigger risk management policy we have/need.

Paragraph 25: ADCO dependency assessment

Original text from the CRA

In order to assess the dependence of Member States and of the Union as a whole on software components and in particular on components qualifying as free and open-source software, ADCO may decide to conduct a Union wide dependency assessment for specific categories of products with digital elements. For that purpose, market surveillance authorities may request manufacturers of such categories of products with digital elements to provide the relevant software bills of materials as referred to in Part II, point (1), of Annex I. On the basis of such information, the market surveillance authorities may provide ADCO with anonymised and aggregated information about software dependencies. ADCO shall submit a report on the results of the dependency assessment to the Cooperation Group established pursuant to Article 14 of Directive (EU) 2022/2555.

Tasks

• CRA-001

Article 14: Reporting obligations of manufacturers

Analysis

There will be a standard that helps with parts of this article but here are some things we will need to do (this list is not exhaustive) either way. A lot of the standard will be based on ISO/IEC 29147 for vulnerability disclosure and on ISO/IEC 30111 both of which we'll have to evaluate in depth as well as the newly written standard.

Tasks

• TODO: This is incomplete and waits for the finalised standard
• CRA-013
• CRA-017
• CRA-026

Article 28: EU declaration of conformity

Original text from the CRA

These are only the relevant paragraphs. There are more paragraphs in this article.

1. The EU declaration of conformity shall be drawn up by manufacturers in accordance with Article 13(12) and state that the fulfilment of the applicable essential cybersecurity requirements set out in Annex I has been demonstrated.

2. The EU declaration of conformity shall have the model structure set out in Annex V and shall contain the elements specified in the relevant conformity assessment procedures set out in Annex VIII. Such a declaration shall be updated as appropriate. It shall be made available in the languages required by the Member State in which the product with digital elements is placed on the market or made available on the market.

The simplified EU declaration of conformity referred to in Article 13(20) shall have the model structure set out in Annex VI. It shall be made available in the languages required by the Member State in which the product with digital elements is placed on the market or made available on the market.

Tasks

• CRA-027

Article 31: Tecnical documentation

Original text from the CRA

These are only the relevant paragraphs. There are more paragraphs in this article.

1. The technical documentation shall contain all relevant data or details of the means used by the manufacturer to ensure that the product with digital elements and the processes put in place by the manufacturer comply with the essential cybersecurity requirements set out in Annex I. It shall at least contain the elements set out in Annex VII.

2. The technical documentation shall be drawn up before the product with digital elements is placed on the market and shall be continuously updated, where appropriate, at least during the support period.

Tasks

• TODO: Copy over the tasks from Annex VII

Annex I: Essential Cybersecurity Requirements

Part I: Cybersecurity requirements relating to the properties of products with digital elements

Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.

Analysis
A standard is being written which serves as a framework for vertical standards.
It contains generic information about risk assessments for the CRA but it will not apply for our product and does not provide presumption of conformity. It will also not mandate any specific risk assessment techniques.

Tasks

• CRA-002
• CRA-003
• CRA-004
• CRA-005
• CRA-006
• CRA-007
• CRA-008

shall be made available on the market without known exploitable vulnerabilities

Tasks

• CRA-012
• CRA-028

shall be made available on the market with a secure by default configuration, unless otherwise agreed between manufacturer and business user in relation to a tailor-made product with digital elements, including the possibility to reset the product to its original state

Tasks

• CRA-029

ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them

Tasks

• CRA-030

ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access

• CRA-031
• CRA-032

protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means

Tasks

• CRA-029

protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions

Tasks

• CRA-033

Open questions

• What is a "command?

process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation)

We do not store or process personal or other data of our customers as part of our product. This is not an issue for us.

protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks

Waiting for guidance/standard

minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks

Analysis

I do not think there is much we can do here but I'll add a task so we can brainstorm a bit.
One example would be that our tools should minimise outbound connections e.g. to avoid DDoS attacks from our tools. But as we ship mostly general purpose tools there's little we can do.

Tasks

• CRA-034

be designed, developed and produced to limit attack surfaces, including external interfaces

Waiting for guidance/standard

be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques

Waiting for guidance/standard

provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user

Tasks

• CRA-029
• CRA-032

provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner.

Tasks

• CRA-035

Part II: Vulnerability handling requirements

identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products;

We already produce SBOMs for our entire product and publish them as well.

in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates;

Tasks

• CRA-012
• CRA-036

apply effective and regular tests and reviews of the security of the product with digital elements;

Not sure yet what to do here. I'm hoping for guidance/standard.
We do run our integration tests...

once a security update has been made available, share and publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and clear and accessible information helping users to remediate the vulnerabilities; in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security benefits, they may delay making public information regarding a fixed vulnerability until after users have been given the possibility to apply the relevant patch;

Tasks

• CRA-012
• CRA-037

put in place and enforce a policy on coordinated vulnerability disclosure;

Tasks

• CRA-013
• CRA-017

take measures to facilitate the sharing of information about potential vulnerabilities in their product with digital elements as well as in third-party components contained in that product, including by providing a contact address for the reporting of the vulnerabilities discovered in the product with digital elements;

Tasks

• CRA-009
• CRA-013
• CRA-017

provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner;

Tasks

• CRA-036

ensure that, where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements, free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken.

This is covered by the previous points.

Annex II: Information And Instructions To The User

This is about the documentation we need to have for the users

the name, registered trade name or registered trademark of the manufacturer, and the postal address, the email address or other digital contact as well as, where available, the website at which the manufacturer can be contacted

Tasks

• CRA-018

the single point of contact where information about vulnerabilities of the product with digital elements can be reported and received, and where the manufacturer’s policy on coordinated vulnerability disclosure can be found;

Tasks

• CRA-017

name and type and any additional information enabling the unique identification of the product with digital elements

Each image already contains a tag uniquely identifying it.
All our images also contain a common set of labels allowing them to be identified easily.

I can't think of anything else to do here.

the intended purpose of the product with digital elements, including the security environment provided by the manufacturer, as well as the product’s essential functionalities and information about the security properties

This is important!

Relevant definitions:

‘intended purpose’ means the use for which a product with digital elements is intended by the manufacturer, including the specific context and conditions of use, as specified in the information supplied by the manufacturer in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation

‘reasonably foreseeable use’ means use that is not necessarily the intended purpose supplied by the manufacturer in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation, but which is likely to result from reasonably foreseeable human behaviour or technical operations or interactions;

‘reasonably foreseeable misuse’ means the use of a product with digital elements in a way that is not in accordance with its intended purpose, but which may result from reasonably foreseeable human behaviour or interaction with other systems;

Most other obligations in the entire CRA only apply if/when

they are properly installed, maintained, used for their intended purpose or under conditions which can reasonably be foreseen, and, where applicable, the necessary security updates have been installed

Source: Article 6: Requirements for products with digital elements

Tasks

• CRA-005
• CRA-038
• CRA-039

any known or foreseeable circumstance, related to the use of the product with digital elements in accordance with its intended purpose or under conditions of reasonably foreseeable misuse, which may lead to significant cybersecurity risks

Tasks

• CRA-040

where applicable, the internet address at which the EU declaration of conformity can be accessed

Tasks

• CRA-027

the type of technical security support offered by the manufacturer and the end-date of the support period during which users can expect vulnerabilities to be handled and to receive security updates

Tasks

• CRA-041
• CRA-042

detailed instructions or an internet address referring to such detailed instructions and information on:
(a) the necessary measures during initial commissioning and throughout the lifetime of the product with digital elements to ensure its secure use;

Tasks

• CRA-019

(b) how changes to the product with digital elements can affect the security of data;

Tasks

• CRA-040

TODO: Not entirely sure what's really needed here. Could be stuff like "if you disable authentication then..."

(c) how security-relevant updates can be installed;

Tasks

• CRA-043

(d) the secure decommissioning of the product with digital elements, including information on how user data can be securely removed;

Tasks

• CRA-035

(e) how the default setting enabling the automatic installation of security updates, as required by Part I, point (2)(c), of Annex I, can be turned off;

Tasks

• CRA-030

(f) where the product with digital elements is intended for integration into other products with digital elements, the information necessary for the integrator to comply with the essential cybersecurity requirements set out in Annex I and the documentation requirements set out in Annex VII.

I'd argue that this does not apply to us.

If the manufacturer decides to make available the software bill of materials to the user, information on where the software bill of materials can be accessed.

Tasks

• CRA-044

Annex VII: Content Of The Technical Documentation

Original text from the CRA

a general description of the product with digital elements, including:
(a) its intended purpose;
(b) versions of software affecting compliance with essential cybersecurity requirements;
(c) where the product with digital elements is a hardware product, photographs or illustrations showing external features, marking and internal layout;
(d) user information and instructions as set out in Annex II;

Tasks

• CRA-011

Original text from the CRA

a description of the design, development and production of the product with digital elements and vulnerability handling processes, including:
(a) necessary information on the design and development of the product with digital elements, including, where applicable, drawings and schemes and a description of the system architecture explaining how software components build on or feed into each other and integrate into the overall processing;
(b) necessary information and specifications of the vulnerability handling processes put in place by the manufacturer, including the software bill of materials, the coordinated vulnerability disclosure policy, evidence of the provision of a contact address for the reporting of the vulnerabilities and a description of the technical solutions chosen for the secure distribution of updates;
(c) necessary information and specifications of the production and monitoring processes of the product with digital elements and the validation of those processes;

Tasks

• CRA-012
• CRA-017
• CRA-045

TODO: Not entirely sure how to handle a) and c)

Original text from the CRA

an assessment of the cybersecurity risks against which the product with digital elements is designed, developed, produced, delivered and maintained pursuant to Article 13, including how the essential cybersecurity requirements set out in Part I of Annex I are applicable;

Tasks

• CRA-008
• CRA-003

Original text from the CRA

relevant information that was taken into account to determine the support period pursuant to Article 13(8) of the product with digital elements;

Tasks

• CRA-042

Original text from the CRA

a list of the harmonised standards applied in full or in part the references of which have been published in the Official Journal of the European Union, common specifications as set out in Article 27 of this Regulation or European cybersecurity certification schemes adopted pursuant to Regulation (EU) 2019/881 pursuant to Article 27(8) of this Regulation, and, where those harmonised standards, common specifications or European cybersecurity certification schemes have not been applied, descriptions of the solutions adopted to meet the essential cybersecurity requirements set out in Parts I and II of Annex I, including a list of other relevant technical specifications applied. In the event of partly applied harmonised standards, common specifications or European cybersecurity certification schemes, the technical documentation shall specify the parts which have been applied;

Tasks

• CRA-008

Original text from the CRA

reports of the tests carried out to verify the conformity of the product with digital elements and of the vulnerability handling processes with the applicable essential cybersecurity requirements as set out in Parts I and II of Annex I;

Tasks

• CRA-012
• CRA-028
• CRA-046

Original text from the CRA

a copy of the EU declaration of conformity;

Tasks

• CRA-027

Original text from the CRA

where applicable, the software bill of materials, further to a reasoned request from a market surveillance authority provided that it is necessary in order for that authority to be able to check compliance with the essential cybersecurity requirements set out in Annex I

Tasks

• CRA-044

Tasks

This extracts unique tasks out of the obligations mentioned above as some of the obligations are mentioned in multiple places.

• ✔️ CRA-001 Establish a "CRA Hub" in our docs to serve as an entrance point for all interested parties (customers, market surveillance, security researchers etc.)
  • Mention this article 13 paragraph 25 and the term "ADCO" on the documentation page for searchability
• CRA-002 Establish a Risk Assessment process
  • This needs to include provisions to regularly review and update the Risk Assessment
  • Content:
    • Determine the product context (see also CRA-004)
    • Determine the product assets
    • Identify threats to these assets and extrapolate the erisks
    • Based on intended purpose and reasonably forseeable use but NOT based on the reasonably forseeable misuse
• CRA-003 Publish the Risk Assessment process in our docs (link to CRA Hub)
• CRA-004 Come up with the "intended purpose", "reasonably forseeable use", "reasonably forseeable misuse" and "conditions of use" for SDP
  • Also see the Blue Guide 2.8
• CRA-005 Publish the intended purpose" in our docs
• CRA-006 Conduct Risk Assessment
• CRA-007 Analyze and document results of the Risk Assessment and take create tasks for actions needed during planning, design, development, production, delivery and maintenance of SDP
• CRA-008 Prepare Statement of Applicability (SoA) for the requirements from Annex I Part I and publish it in the docs
  • For each requirement justify why we are not following it and if we do document which standards, specifications or other ways we use to fulfill them
• CRA-009 Create a "Third-Party component policy", adapt an existing one or verify that it's fully covered by an existing policy
• CRA-010 Create a "Security" documentation page and link it in the CRA Hub
  • This tasks is WIP - not entirely sure yet if we want/need it
• CRA-011 Determine and document support period
  • Documentation needs to include the information that was taken into account when determining the support period
• CRA-012 Vulnerability Handling policy needs to be in place
  • Including monitoring for new vulnerabilities and a process to act on them (see ISO/IEC 30111)
  • It needs to prioritize known exploitable vulnerabilities as these are blocking a release
  • It needs to cover when and how to publish a CVE record
• CRA-013 Policy for coordinated vulnerability disclosure needs to be in place
  • Needs to be linked from our "CRA Hub" as well as the homepage
  • To me this is slightly different from CRA-017 as one talks about how vulnerabilities are disclosed to us and the other how vulnerabilities are made public in a coordinated fashion. This might be a misunderstanding on my part and both might be merged
• CRA-014 Ensure that a data retention policy is in place and implemented that ensures that old versions of our product are available for as long as needed
  • The timeframe depends on the support period
  • We can decide whether we want to keep all old versions public or make them available only for paying customers
    ers only
• CRA-015 Add an article/snippet to the documentation urging customers not to use our old product versions and clearly state the risks of using unsupported software
• CRA-016 Ensure that a data retention policy is in place and implemented to keep the old documentation around for as long as needed (depends on support period)
• CRA-017 Ensure a public Vulnerability Disclosure Policy as well as a security.txt file (which is kept up-to-date) are in place and linked from the docs
  • Ensure the link always leads to the latest version
• CRA-018 Ensure contact information (non-security) is easily and readily available from the documentation
  • This contact can't only be an automated tool, we'll probably just use an E-Mail address for now
• CRA-019 Documentation must make it very clear how to install, operate and use the SDP in a secure way
  • The installation docs must clearly show how to set up the platform in a secure way if there are any manual steps that need to be done
• ✔️ CRA-020 Extend our operators so that they warn if they are being used past their EoS date
  • I'm not clear yet on whether this is only for operators or whether we should also warn on e.g. deprecated products
  • That said: If we are running on an outdated operator then, by extension, we'll also be running an outdated product
• CRA-021 Create a page clearly documenting our supported versions per SDP release
  • This needs to list the SDP versions that are supported
  • Within each SDP version it should list the product versions as well as supported Kubernetes & OpenShift versions
  • This needs to be linked from the docs but can be an external site generated from a database
• CRA-022 Evaluate whether we can use a machine-readable standard for EoS information (OWASP CLE or OpenEoX are two candidates)
• CRA-023 Add a label to our docker images with a link to the declaration of conformity in the documentation
• CRA-024 Have a policy to regularly review whether we are still in compliance with the CRA and other regulations
  • This might be part of the Risk management policy as it is a risk for us to not be compliant
• CRA-025 Establish a "Company shutdown"/Company decomissioning policy
  • It should probably also take effect when we "just" shutdown our SDP product
• CRA-026 Have the infrastructure and policies in place to fulfill the reporting obligations
  • This might mean changes to SecObserve
  • Registering(?) with the Single Reporting platform of the EC (yet to be published)
• CRA-027 Add declaration of conformity to the documentation with the model set out in Annex V and the contents of the conformity assessment procedure set out in Annex VIII, Part I, paragraph 4.2
  • Do not use the simplified form from Annex VI
• CRA-028 Our release process must include a check for known exploitable vulnerabilities and flag these as release blockers
• CRA-029 Go through our entire product and enable all security features by default where technically possible
  • Clearly document where it's not possible and why
  • TLS/transport security
  • Authentication
  • Authorisation
  • Auditing
  • Encryption at rest
• CRA-030 Decide whether we want to / can introduce an auto-update functionality for operators or products (I don't think so) or if we can/should at least have a way to display new versions in e.g. the status (see also CRA-020)
• CRA-031 Ensure that all of our products have a documented way to enable authentication and authorisation
• CRA-032 Ensure that all our products have audit functionality (where applicable) at least for authentication and authorisation requests
• CRA-033 Investigate & implement methods to protect the integrity of data, programs, configuration and "commands" (open question)
• CRA-034 Brainstorming session on whether or how we can limit the negative impact of OUR products on others in a network
• CRA-035 Document how to entirely uninstall our products leaving no data or configuration data behind
• CRA-036 Have a way to release security updates for our releases on a regular basis (e.g. updated base images and potentially fixed product images)
• CRA-037 Have infrastructure and policies in place to publish vulnerability assessments (VEX) statements publicly as well as privately
• CRA-038 Research what "security environment" means, define and document it
• CRA-039 Define and document the product's essential functionalities and the security properties
  • This is part fo the first horizontal standard and should be part of the risk assessment
• CRA-040 Assess which circumstances could lead to significant cybersecurity risks (e.g. disabling of all security measures) and document the findings
• CRA-041 Add a section in our documentation that details the type of support we offer, link to our commercial offerings
• CRA-042 Review & revamp our lifecycle policies and link them from the "CRA hub"
  • On the lifecycle page describe exactly how and why our support periods were chosen
• CRA-043 Ensure our documentation has a dedicated site that gives pointers at where updates can be found and how they are installed or where documentation can be found on how they are installed
• CRA-044 Link to our SBOMs and the SBOM help page from the CRA hub
• CRA-045 Have a document describing how our update distribution mechanism works - this can probably link to preexisting documentation and add to CRA hub
• CRA-046 Ensure that our release tickets have a section verifying conformity with the CRA prior to release
  • This needs to clearly document the steps we took to verify this (based on the SoA)
  • Potentially also record the integration tests being done

TODO

• Potentially add a task to keep results of tests we run for each release. I thought I had something on it but I can't find it now.