Automated Impact Assessment

Summary

Enabled by default for all uploaded firmware, Automated Impact Assessment assigns each vulnerability a match score based on whether it's likely to affect your specific firmware build. Vulnerabilities that score below a threshold are automatically hidden and marked Not affected.

A firmware analysis typically surfaces hundreds or thousands of vulnerability matches, but not all of them are relevant to a specific firmware build. A vulnerability may target a version range that does not include the exact firmware version, a kernel module that is not present, or a feature that was never compiled in. Without a way to filter these out, vulnerability triage is dominated by matches that do not apply.

Automated Impact Assessment analyzes extracted firmware files to identify and hide non-exploitable vulnerabilities. Essentially, this feature acts as a filter that allows you to focus on relevant vulnerabilities, streamlining the triage process.

A vulnerability is deemed "non-exploitable" if:

1. The affected version is different from the one in your firmware.
2. The vulnerability affects a feature or module that was not compiled in.
3. The vulnerability affects a feature that is not explicitly used by the firmware.

For example, if a vulnerability is only exploitable over Bluetooth, but your firmware runs on a Linux kernel without a Bluetooth submodule, the platform automatically filters this out.

How to use it

Automated Impact Assessment is enabled by default for all uploaded firmware. It assigns each vulnerability a match score:

1. Positive score: the vulnerability is relevant to your firmware.
2. Negative score: the vulnerability is considered non-exploitable.

A higher absolute score, whether positive or negative, indicates greater confidence in the assessment.

A match score of 0 means either that the negative and positive scores cancel each other out, or that the platform is unsure about the particular vulnerability and therefore cannot give it a score. Only vulnerabilities with a score of -2 or higher are displayed in the CVE tables. Vulnerabilities with a score below -2 are automatically hidden and assigned the closed status Not affected. This ensures that potentially relevant vulnerabilities are not lost, while those least likely to apply are filtered out.

Note

Compliance checkers ignore vulnerabilities with a negative score when calculating whether a compliance provision has been violated or not.

See the Automated Impact Assessment tab for details on how the match score was calculated and for the evidence behind the score and the decision.

Filtered vulnerabilities are not deleted – they are still accessible. To view them, uncheck Show only CVEs with open status in the CVE table and filter for the Not affected status.

How it works

Automated Impact Assessment uses a rule-based system to evaluate vulnerabilities. If a rule applies to a vulnerability, we add a positive match score. If a rule does not apply to the vulnerability, or the rule is designed in such a way that it leads to a negative result, the vulnerability gets a negative score.

You can check the total score of all rules applied in the Match score column under Automated Impact Assessment.

A CVE rule can either be:

1. Automatically generated based on the vulnerability's description.
2. Manually created by ONEKEY security analysts.

The platform further distinguishes between three types of rules:

• General component rules.
• Android firmware-specific rules
• Linux kernel-specific rules

General component rules

For general components, ONEKEY identifies and analyzes:

• The file names, strings, function imports, and binary usage within the firmware files.
• The target architecture (for example, x86, ARM).
• The vulnerability's summary.

For vulnerabilities with manually created rules, the platform runs 2-5 different checks to ensure accurate detection.

Note

To make sure that the vulnerability databases are up-to-date, we perform database updates every few hours. That is why if you have Monitoring enabled, you may notice some vulnerabilities come and go with each run.

Android rules

For Android-based firmware, vulnerabilities can affect the operating system, kernel, or individual applications.

ONEKEY applies checks based mainly on the OS version, patch level (listed in the Version and Update fields, respectively), and the installed applications.

Note

To view the installed applications, filter for "Android" in the Tags column of the Components table.

Automated Impact Assessment assigns vulnerabilities a negative match score if:

• The application affected by the vulnerability is not present in the firmware.
• The manufacturer or vendor does not match the one described in the vulnerability.
• The vulnerability has already been fixed through backports.
• The detected patch level is not affected (according to the Android Security Bulletin).

Linux kernel rules

Why does the Linux kernel have special rules?

The Linux kernel is extensive and has numerous versions, making it responsible for most of the vulnerabilities in a firmware.

The platform uses a special approach to assess vulnerability relevance in Linux kernels on top of running the same check as with general components:

1. It extracts all kernels and their associated modules from the firmware and identifies the Symbols.
2. It then maps each kernel symbol (version-specific) to its corresponding source files in our database.
3. Finally, it analyzes kernel modules, specifically examining ELF files to identify the symbols.

ONEKEY compares the extracted data with the rules, and if there is a match, it gives the vulnerability a positive score.

Examples

CVE impacting a firmware

CVE-2022-48839 has a positive match score of 100, indicating a high likelihood that this vulnerability affects the uploaded firmware:

To understand how ONEKEY arrived at this conclusion, click on the vulnerability and navigate to the Automated Impact Assessment tab:

• Match on symbols: there is a match with a specific symbol or function within the kernel.
• Match on source files: the identified vulnerability is located in a source file within the kernel.
• Match on source files by symbol: the vulnerability is identified in a source file (by mapping the vulnerable function to the source file) within the kernel.

Based on the combination of these three match types, there is a strong case that the vulnerability is present in the firmware.

CVE not impacting a firmware

CVE-2022-48845 has a negative score of -147, indicating a low likelihood that this vulnerability affects the uploaded firmware: (1)

1. To view automatically filtered vulnerabilities, uncheck "Show only CVEs with open status" and filter for the Not affected status.

This vulnerability displays the following information on the Automated Impact Assessment tab:

• No match on architecture: the vulnerability is not relevant as it does not affect the specific architecture of the firmware.
• No match on source files: the identified vulnerability is not found within the specific source files, so the particular file is not affected by this vulnerability.
• No match on symbols: the specific symbols within the codebase are not associated with the identified vulnerability.
• Match on source files by symbol: there is a match with specific symbols within particular source files.

Based on the combination of these four match types, both positive and negative, there is a strong case that this vulnerability does not affect the uploaded firmware.

Quick reference

Feature	Details
Enabled by default	Automated Impact Assessment is on for all uploaded firmware; no configuration required.
Match score	Positive = vulnerability is relevant; negative = vulnerability is considered non-exploitable. Higher absolute value indicates greater confidence. Vulnerabilities with a score of -2 or higher are shown. Vulnerabilities below -2 are hidden and marked Not affected.
Viewing filtered vulnerabilities	Uncheck Show only CVEs with open status and filter for the Not affected status.
Vulnerability databases	Updated every few hours; vulnerabilities may appear or disappear between Monitoring runs.
SBOM-only components	Not available for components sourced exclusively from an imported SBOM (no binary evidence to analyze).