Whether opting for self-assessment or engaging a Notified Body, all manufacturers seeking compliance with EN 18031 must meet the requirement GEC-1. It mandates comprehensive documentation of software/hardware components, along with analyses of the vulnerabilities affecting them. Specifically, manufacturers must document the paths through the Decision Tree (DT) for each component and vulnerability. However, given the substantial number of vulnerabilities frequently found in equipment - often numbering in the thousands -, analyzing and documenting each one can be impractical.

To address this challenge efficiently, we propose below a methodology for identifying vulnerabilities and prioritizing those that require analysis. Zealience's open-source script (Zealience Script) can then be utilized to generate the GEC-1 Technical Documentation, including all necessary paths through the DT.

This article is designed to be both comprehensive and actionable, equipping IoT engineers with the knowledge and tools needed to navigate the complexities of GEC-1. By the end of this article, you will understand:

• What the GEC-1 requirement entails
• The interpretation of "publicly known exploitable vulnerabilities"
• How to utilize EPSS scores to efficiently identify exploitable vulnerabilities
• How to determine the appropriate EPSS threshold for your device
• How to use OWASP Dependency Track to identify vulnerabilities and document your analyses
• How to identify vulnerabilities that exceed the EPSS threshold using Dependency Track
• How to export SBOM and VDR from Dependency Track
• How to import the SBOM and VDR into Zealience Script to automatically convert the files into GEC-1 Technical Documentation in .xlsx format
• How Zealience Script parses SBOM and VDR files to convert their information into specific Decision Tree data
• How to continuously monitor new vulnerabilities and update your documentation to maintain compliance

Prerequisite: You should already have an SBOM (e.g., generated from your build) in CycloneDX format.

This article is the outcome of our close collaboration with our customers. A heartfelt Thank You! to those recognizing their contributions below.

Overview of GEC-1

GEC-1 requires that equipment must not contain publicly known exploitable vulnerabilities that could affect assets if exploited. However, vulnerabilities that meet one of the following conditions are exempted:

• The vulnerability does not affect assets, or
• It cannot be exploited under the specific conditions of the equipment, or
• It has been mitigated to an acceptable residual risk, or
• It has been accepted on a risk basis

To fulfill GEC-1, manufacturers are expected to assemble documentation that includes:

• The assets in the equipment (security, network, privacy and/or financial assets, depending on the standard applied)
• The software components (and their version) that affect these assets
• The hardware components that affect the assets
• The publicly known exploitable vulnerabilities in the software and hardware, including the source of vulnerability information.

Additionally, manufacturers must document the "path through the Decision Tree" for each software/hardware component and its associated vulnerabilities. As illustrated in the figure below, the DT consists of 2 parts: One for the software/hardware components and another for the vulnerabilities.

The second part is crucial for enabling manufacturers to determine whether a given vulnerability is exempt (i.e., an answer to a Decision Node leads to the DT result "NOT APPLICABLE"). Manufacturers must justify their answers by providing specific information under a designated identifier, as described below:

To fulfill GEC-1, no path through the DT should end in FAIL. This means that any identified vulnerability in the equipment must fall under one of the identifiers listed above. In other words, manufacturers must analyze all identified vulnerabilities, remediate them where necessary, and justify why each of them does not pose a risk to the equipment and its assets.

Note: In EN 18031, a FAIL is a fail (i.e., definitive). The standard does not permit justifying a FAIL and still claiming compliance.

Our interpretation of "publicly known exploitable vulnerability"

The term "publicly known exploitable vulnerability" used in EN 18031 suggests two aspects to consider:

• The vulnerability is publicly known: It has been made known (or "disclosed") through various channels, such as security advisories (e.g., vendor's website, GitHub Security Advisory), vulnerability databases (e.g., National Vulnerability Database NVD, European Union Vulnerability Database EUVD), or security research publications.
• The vulnerability is exploitable: It can be (or is currently being) exploited by attackers to gain unauthorized access, execute malicious code, or perform other harmful actions on affected systems. Lists of exploited vulnerabilities (called Known Exploited Vulnerabilities, KEV) are created and maintained by various organizations including the US Cybersecurity & Infrastructure Security Agency (CISA) and Forescout's Vedere Labs.

Let's consider the Apache Log4j Remote Code Execution Vulnerability (CVE-2021-44228) as an (obvious) example of publicly known exploitable vulnerability: It has been disclosed (e.g., CVE-2021-44228) and is exploitable (e.g., listed on the CISA Known Exploited Vulnerabilities (KEV) Catalog).

These two aspects above are aligned with GEC-1 which mentions several factors to take into account when assessing vulnerabilities, particularly:

• "Evidence that the vulnerability has been actively exploited", and
• Evidence of exploit code/PoC (Proof Of Concept code) available online

In this context, manufacturers must investigate whether each vulnerability in their equipment is actively exploited, and whether exploit code is available. Given the vast number of vulnerabilities that can be present, this is not realistic. Fortunately, a scoring system called EPSS exists to calculate the probability of exploitation of vulnerabilities based on these aforementioned factors.

Using EPSS to efficiently meet GEC-1

Measuring the exploitability of vulnerabilities with EPSS

"The Exploit Prediction Scoring System (EPSS) is a data-driven effort for estimating the likelihood (probability) that a software vulnerability will be exploited in the wild" within the next 30 days (source: FIRST). EPSS scores range from 0 to 1, with 1 indicating the highest probability of exploitation. EPSS scores are calculated based on various factors, including:

• CVSS Metrics: Base vector from CVSS 3.x, sourced from the NVD.
• CVE Listings: Vulnerabilities discussed on various lists or websites, such as CISA's Known Exploited Vulnerabilities (KEV)
• Publicly Available Exploit Code: Resources like Exploit-DB, GitHub and Metasploit
• Offensive Security Tools and Scanners: Tools such as sn1per and nuclei.

For more details, visit FIRST.

The information used to calculate EPSS scores aligns well with the two aspects of "publicly known exploitable vulnerability" discussed earlier. We can therefore leverage these scores to prioritize the vulnerabilities for analysis and remediation to meet GEC-1.

Prioritizing vulnerability analysis based on EPSS

The core concept behind using EPSS for vulnerability analysis and remediation can be articulated as follows: Since vulnerabilities have a score estimating the likelihood of their exploitation, one can sort them and only focus on the vulnerabilities above a certain EPSS threshold. Any vulnerabilities below this threshold can be considered unlikely to be exploited and can be accepted on a risk basis.

This approach was suggested by one of our customers who highlighted the challenges posed by 1) the large number of vulnerabilities to tackle, and 2) the limitations of traditional prioritization strategies based on CVSS scores in efficiently meeting GEC-1. He referenced research conducted by the FIRST team, which compared the efficiency of remediation prioritization effort based on vulnerabilities' CVSS and EPSS scores. Their results indicate that prioritization based on EPSS is significantly more efficient, as it directs attention to vulnerabilities that are more likely to be exploited.

The FIRST team's research can be summarized as follows: They considered all the vulnerabilities in the NVD with a CVSS v3.x score at the beginning of October 2023 (total of 139,473 CVEs). Then, the team tracked exploitation activities of vulnerabilities over the next 30 days. Finally, they compared the vulnerabilities in the NVD against those that were exploited during that month, considering the CVSS score and EPSS score.

As illustrated in the figure below, prioritizing remediation effort based on EPSS is far more efficient than CVSS. Prioritizing based on CVSS score above 7 (as traditionally done) would have led to remediating 57.4% of the total CVEs, while prioritizing based on EPSS score above 0.1 would have resulted in remediating only 2.7%. Considering that 2.8% of the total CVEs were observed to be exploited within the time frame, this signifies that the efficiency of the remediation effort based on CVSS was 4%, while the efficiency based on EPSS was 65.2%.

This approach can be applied in the context of GEC-1 to help manufacturers efficiently identify which vulnerabilities to prioritize. The strategy can be summarized as follows:

• Define an EPSS threshold (more on that below)
• Analyze and remediate the vulnerabilities above the threshold (and document the path through the Decision Tree accordingly)
• Accept all vulnerabilities below the threshold as their risk of exploitation can be considered negligeable.

Note: A hybrid approach is also possible, as mentioned by another customer who uses a combination of EPSS and CVSS scores.

The next question is "Which EPSS score should be used as threshold?"

Choosing the right EPSS threshold

Prioritizing vulnerability analysis and remediation based on EPSS scores requires defining a threshold. The FIRST team highlights that the value of 0.1 is arbitrary. In the context of GEC-1, there is no universal answer: It must be identified by the manufacturers themselves and justified based on risk. This involves considering the equipment itself, its technologies, its attack surface, its intended usage and its environment of use. Therefore, what one manufacturer may consider acceptable as threshold may not be by another.

One strategy we can think of to identify the appropriate EPSS threshold is to use a divide-and-conquer strategy:

• Select an initial EPSS threshold arbitrarily (e.g., 0.1)
• Select a few vulnerabilities which fall below but are close to that threshold.
• For each of them, analyze it by searching for exploit code and trying to exploit the vulnerability. If successful, pick a lower threshold and repeat the process. Continue this until you reach a threshold where vulnerabilities are not exploitable (e.g., no exploit code is available, the exploit fails in the equipment's configuration, or other mitigating measures are in place in the targeted operational environment.)

This procedure can greatly reduce the effort required to analyze vulnerabilities for GEC-1. However, keep in mind that the EPSS score is an estimation "of the probability of exploitation activity being observed over the next 30 days." (FIRST). This means that EPSS scores can change over time. In fact, a newly disclosed vulnerability may not be immediately observed as being exploited (e.g., no exploit available at first), but exploitation activities can increase later. Therefore, a continuous process for monitoring and managing vulnerabilities is necessary to meet GEC-1.

Identification and documentation of software components and vulnerabilities

Recommended tool: Dependency Track

Meeting GEC-1 requires a vulnerability manager. While numerous tools are available, you can get started quickly with free and open-source software OWASP Dependency Track. We focus below on this tool. Consult its documentation for more information.

Dependency Track allows you to upload SBOMs for your equipment and identify vulnerabilities. It mirrors the NVD and all its vulnerabilities, so that the identification of vulnerabilities can be done locally. You can configure Dependency Track to include other vulnerability sources, including GitHub Advisories and Google OSV Advisories (see Administration menu).

Identifying softwared components with Dependency Track

Open Dependency Track and create a project by providing a name and a classifier. Depending on your equipment and its software, you can create multiple projects if you have dedicated SBOMs. For example, you may have one SBOM for the equipment's firmware , one for a frontend application and another for a backend application.

Click on the project's name, go to the tab "Components" and click on "Upload BOM". Select the SBOM file for that project, click "Upload" and refresh the page. Dependency Track will parse the file and identify the software components present. As an example, we created a project "OpenWRT" and uploaded the SBOM of version 24.10.1. If no components are displayed, try refreshing the page again.

Depending on the information available in your SBOM, extra data may be shown. In particular, if your SBOM contains Package URL (PURL) for the software components, Dependency Track will highlight outdated versions with a warning sign in the Version column.

Identifying and prioritizing vulnerabilities with Dependency Track

After uploading an SBOM, Dependency Track will check for known vulnerabilities affecting the identified components based on the selected vulnerability sources in the previous step. You can see the vulnerabilities by going to the "Audit Vulnerabilities" tab.

In our OpenWRT example above, we see that 2,180 vulnerabilities were identified. We can access their EPSS score by clicking on "Exploit Predictions". This tab displays a graph representing vulnerabilities based on their EPSS and CVSS values.

In the table below the graph, all the vulnerabilities and the software components they affect are displayed. We can sort the vulnerabilities by EPSS and CVSS. In the context of our example with OpenWRT, we compare below the number of vulnerabilities to be analyzed based on EPSS and CVSS at various arbitrary thresholds. Even an EPSS score of 0.01 as threshold leads to 10 times fewer vulnerabilities to analyzed compared to CVSS score of 7.

Once a threshold is defined, we can proceed to analyzing vulnerabilities in Dependency Track.

Analyzing and documenting vulnerabilities in Dependency Track

For each vulnerability, assess whether it affects the related software component. To document your analysis in Dependency Track, follow these steps:

• In the table in Exploit Predictions, click on the vulnerability.
• Click on "Affected Projects" and click on the listed project.
  • You will now be in the "Audit Vulnerabilities" tab, where you can see the software affected component(s)
• For each software component listed, click on the caret icon next to the component's name. This will reveal a description of the vulnerability and an area for documenting your analysis (see figure below).

For GEC-1, the important fields to document are "Analysis", "Justification" and "Details". These fields are defined in the CycloneDX standard and are used to document vulnerability analysis in a machine-readable format. They are defined as follows:

• "Analysis" (called "state" in CycloneDX): "Declares the current state of an occurrence of a vulnerability, after automated or manual analysis" (CycloneDX). It can have one of the following values:

• "Justification": This field provides "the rationale of why the impact analysis state was asserted" (CycloneDX). It can only be set in Dependency Track when you select "Not affected" for the analysis. "Justification" can have one of the following values:

⚠️This term should not be mixed with the justification for GEC-1, [E.Just.DT.GEC-1].

• "Detail": This field provides a "detailed description of the impact including methods used during assessment. If a vulnerability is not exploitable, this field should include specific details on why the component or service is not impacted by this vulnerability" (CycloneDX).

Fill in these three fields for each vulnerability you analyze. In the next section, we will explain how to use this information to automatically create the Technical Documentation for GEC-1.

Generating VDR and SBOM with Dependency Track

After completing your analyses in Dependency Track, you can export the vulnerabilities and software components by generating a Vulnerability Disclosure Report (VDR) and an SBOM in CycloneDX format. The VDR contains two sets of information:

• The software components affected by vulnerabilities
• The vulnerabilities and their details (e.g., CVSS score, description), including your analyses, where available

The software components and vulnerabilities are linked together through references (i.e., bom-ref) provided by Dependency Track. To generate the VDR, head to the tab Audit Vulnerabilities and click "Export VDR".

The SBOM generated by Dependency Track differs slightly from the initial SBOM used, as it includes references (bom-ref) for each component. They will be used in the next section to generate the GEC-1 Technical Document, as they enable matching the components in the SBOM with the vulnerable ones listed in the VDR. To generate the SBOM, go to the tab Components, click "Download BOM", and select "Inventory".

Generating the GEC-1 Technical Documentation with Zealience Script

We have released an open-source script designed to process the SBOM and VDR files and generate the GEC-1 Technical documentation efficiently. By executing the script and providing these files as input, you can create CSV files that contain the following information:

• DT Nodes
• DT Justification
• DT Results
• Identifiers for the software components ([E.Info.GEC-1.SoftwareDocumentation]) and vulnerabilities ([E.Info.GEC-1.ListOfVulnerabilities]).

For the software components, the script will parse the SBOM and VDR to determine whether a given component is affected by vulnerabilities. Components that are not affected will have their DT Result set to "PASS", while those affected will have their DT Result set to "PROCEED TO DN2". As depicted in the figure below, The DT instructs us to then pursue further analysis for each vulnerability affecting the software component.

For the vulnerabilities, the script will process the VDR and, where available, retrieve the analyses documented in Dependency Track.

• When an analysis is provided: The script will use the fields "Analysis" and "Justification" to derive the path through the DT as described in the figure below. It will utilize the information provided in "Detail" to document the information expected for the identifier. For example, if the path through the DT leads to the identifier "Mitigated", the information in Detail will be used to provide description for [E.Info.GEC-1.ListOfVulnerabilities.Mitigated].
• When an analysis is not provided, you can set default values at the beginning of the script execution. Assuming that the vulnerabilities without analysis fall below the EPSS threshold, the following default values can be set to indicate that they are "accepted on a risk basis":
  • DN2=Yes
  • DN3=Yes
  • DN4=No
  • DN5=Yes

You can provide details/rationale for selecting a specific EPSS threshold. The script will then assign this information to all vulnerabilities without analysis, ensuring a complete Technical Documentation is created effortlessly.

Continuous vulnerability management for GEC-1

Why IoT manufacturers must manage vulnerabilities continuously

Meeting GEC-1 necessitates the establishment of a robust vulnerability management process. Manufacturers applying EN 18031 must continuously monitor the vulnerabilities in their equipment and address any newly disclosed vulnerabilities or changes in EPSS scores to ensure their equipment's compliance when placed on the EU market. As stated by the EU Blue Guide:

(The term "placing on the market" is critical to understand. Please refer to Section 2.3 and 2.2 to the Blue Guide for details.)

Simply put, this means that any equipment (as single unit) claimed to be compliant with EN 18031 must meet all applicable requirements of the standard(s) when sold on the EU market. Therefore, any new unit of equipment produced and sold over the equipment's lifecycle must have "up-to-date software and hardware with no publicly known exploitable vulnerabilities" (GEC-1).

The consequence for manufacturers is that any time a new vulnerability or a change of EPSS score is identified, they must assess whether the related software or hardware component is indeed impacted and reflect this information in the Technical Documentation. Given the differences in managing software and hardware vulnerabilities, we propose below two different approaches.

How to manage vulnerabilities continuously

Manufacturers need to continuously monitor the software components and vulnerabilities to ensure the compliance of their equipment sold. As discussed previously, new vulnerabilities affecting software components will be disclosed, and existing vulnerabilities may witness fluctuations in their EPSS scores. Any of such changes will require to analyze those vulnerabilities and document them accordingly to maintain the GEC-1 Technical Documentation up-to-date. We elaborate below on how to use Dependency Track to monitor changes that could impact compliance.

The idea consists in using the "Suppress" toggle feature of Dependency Track to hide vulnerabilities that have already been analyzed, so that we can spot new ones. There are some steps to follow:

• In the tab "Audit Vulnerabilities", toggle "Suppress" after you analyzed a vulnerability (see Figure above)
  • Note that you can only use this toggle after setting the "Analysis" field to one of the proposed values.
• Refresh the page and toggle "Show suppressed findings" (see figure below). You should see a tick icon in the column Suppressed.
  • If you do not see this column, click on the Column menu on the top right and select "Suppressed"

Once you are done analyzing all the vulnerabilities as described above and they are all suppressed, navigate back to the tab Exploit Predictions. The graph and the table should display only the vulnerabilities below your threshold (i.e., those not suppressed). As example, we suppressed all vulnerabilities with an EPSS score above 0.1. If you want to see all suppressed vulnerabilities, click on the toggle above the table on the left.

From now on, you can monitor the vulnerabilities, and you can quickly identify any vulnerabilities requiring attention: Any vulnerability with EPSS score above the threshold will be displayed on top of the list. In such cases, perform the analysis as before, suppress it and regenerate the GEC-1 Technical Documentation.

Identification and documentation of hardware components and vulnerabilities

Managing the vulnerabilities in your hardware may require a different strategy. Due to the limitation of tools to support the identification of hardware vulnerabilities, our customers tend to rely on manual processes. You can follow the approach below:

• Start by listing the hardware component that can affect assets.
  • For example, CPU and connectivity modules will certainly be listed while voltage regulator modules will likely be omitted.
• For each hardware component:
  • Write down the following information:
    • Manufacturer
    • Reference number
    • Firmware version
  • Search for security advisories. Start by going to the manufacturer's website and expand your search by consulting other sources. Document all the known vulnerabilities identified.
  • Similarly to the software components, analyze whether the vulnerabilities affect the component, and document the path through the DT accordingly. In case there are multiple vulnerabilities identified, see whether you can group them and answer a single path. Otherwise, document as many paths as needed. For each path, provide the necessary justification and DT Result.

Relevance to the CRA

The requirement GEC-1 and the methodology proposed above can serve as a foundation to prepare for the CRA. GEC-1 is aligned with the first product requirement of the CRA. As stated in Part I (2) of Annex I of the CRA:

Additionally, the methodology presented in this article supports some of the vulnerability handling requirements of the CRA (process requirements). As stated in Part II of the Annex I of the CRA:

Conclusion

In this article, we explained the need for IoT manufacturers to fulfill the requirement GEC-1 to demonstrate compliance with EN 18031 standards. Yet, meeting it can be arduous, as it requires not only the documentation of potentially thousands of components and vulnerabilities, but also to keep that documentation up-to-date by ongoingly monitoring vulnerabilities.

We detailed some strategies to efficiently meet GEC-1. In particular, we explained:

• How to use OWASP Dependency Track to identify vulnerabilities in your equipment
• How to efficiently prioritize the vulnerabilities to analyze by leveraging their EPSS scores
• How to generate SBOM and VDR files and use them to create your GEC-1 Technical documentation
• How to continuously monitor new vulnerabilities and update your documentation to maintain compliance

This process will ensure a complete and up-to-date GEC-1 Technical Documentation throughout the equipment lifecycle, mandatory for selling equipment in the EU market.

GEC-1 is only a subset of the whole EN 18031 Technical Documentation that is required to demonstrate compliance with the standard(s). Check out our software Z-CMS to guide you to complete your entire EN 18031 Technical Documentation in a structured and logical way. Many of our customers reported finishing their Technical Documentation between 1 week to 2 months, and some have successfully obtained their EU Type Examination Certificate from Notified Bodies. Contact us for a demo!

Acknowledgement 🙏

Thank you for reading, we hope you find this article helpful! This article is the fruit of months of collaboration with our customers. We truly enjoy working alongside IoT manufacturers, as we learn so much from each other. We would like to thank all of you who recognize your contributions in the text.

We believe that collaboration, knowledge sharing, and mutual support are essential for EN 18031 compliance. For those who would like to share your insights, feedback and experiences, you are more than welcome to contact us.

A little bit about us 😊

Zealience is a German startup pioneering software that automates the generation of technical documentation for hEN 18031. Many of our customers have successfully utilized our solution to prepare their technical Documentation. If you're interested in learning more about our software, please reach out for a demo! Visit us at zealience.com.

Dr. Guillaume Dupont is a co-founder of Zealience. He holds a PhD in IoT cybersecurity. As a former Senior Security Expert at UL Solutions, he helped IoT manufacturers prepare for the RED DA by performing evaluations against product security standards such as ETSI EN 303 645 and IEC 62443-4-2. He has contributed to the drafting of EN 18031 and also trained a Notified Body for RED DA assessments. He previously worked at Forescout on automotive security and developed intrusion detection systems for in-vehicle networks. He is also a seasoned IoT vulnerability researcher and disclosed CVEs found in medical devices to Siemens Healthineers. His research on IoT security led him to obtain a US patent: He invented novel machine learning algorithms to enhance the accuracy of IoT device classification (US20220353153).