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

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

Note

Automated Impact Assessment cannot run on components sourced exclusively from an imported SBOM, since there are no binary files to analyze.

1. Positive score: the vulnerability is relevant to your firmware.
2. Negative score: the vulnerability is 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.

Click on a vulnerability in the CVE table to open its details, then see the Automated Impact Assessment tab for how the match score was calculated and 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, ONEKEY adds 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.

Independently of how they were created, rules fall into four categories based on the type of component they target:

• General component rules
• Linux kernel-specific rules
• Android firmware-specific rules
• RTOS-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.

match score match score

• The firmware contains files, strings, function imports, or binary usage tied to the vulnerable code.
• The firmware's target architecture matches an architecture mentioned in the vulnerability's description.

• None of the expected files, strings, or function imports are found in the analyzed binaries.
• The firmware's target architecture does not match the one(s) affected by the vulnerability.
• The vulnerability is already listed as fixed in the component's Debian package changelog.

Linux kernel rules

On top of running the same checks as with general components, the platform determines whether a vulnerability affects Linux kernels by:

1. Extracting all kernels and their associated modules from the firmware and identifying their symbols.
2. Mapping each kernel symbol (version-specific) to its corresponding source files in the database.
3. Analyzing kernel modules, specifically examining ELF files to identify the symbols.

match score match score

• A kernel symbol or function known to be affected by the vulnerability is found among the symbols extracted from the firmware's kernel image or its modules.
• A source file known to contain the vulnerable code is identified, either directly or by mapping a matched symbol to its source file.

• None of the kernel symbols or functions associated with the vulnerability are found in the extracted kernel image or its modules.
• None of the source files associated with the vulnerability, whether matched directly or through symbol mapping, are found in the firmware.
• The vulnerability is already listed as fixed in the component's Debian package changelog.

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 (Version field), patch level (Update field), and the installed applications. (1)

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

match score match score

• The firmware is confirmed to run Android, and the vulnerability affects Android or AOSP in general.
• The detected OS version or security patch level is older than the version in which the vulnerability was fixed (according to the Android Security Bulletin).
• The application affected by the vulnerability is present in the firmware.
• The device manufacturer matches the one described in the vulnerability.

• The firmware does not run Android, but the vulnerability affects Android or AOSP specifically.
• The detected OS version and security patch level are both already recent enough to include the fix (according to the Android Security Bulletin).
• 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.

Note

For some Qualcomm-specific vulnerabilities, ONEKEY records whether the firmware is manufactured by Qualcomm as supporting evidence, but it does not affect the match score.

RTOS rules

For firmware built on a real-time operating system (RTOS), ONEKEY runs checks tailored to the packages and modules the RTOS provides.

QNX

For QNX-based firmware, ONEKEY checks whether the specific QNX package affected by a vulnerability is installed, and whether the installed version has already received the fix.

match score match score

• The affected QNX package is present in the firmware, and its installed version has not yet been patched.

• The affected QNX package is not present in the firmware.
• The affected QNX package is present, but its installed version has already been patched.

Zephyr

For Zephyr-based firmware, ONEKEY checks whether the specific module affected by a vulnerability was compiled into the firmware, based on the presence of that module's logging strings.

match score match score

• The affected module's logging string is found in the firmware's binaries, indicating that the module was compiled in.

• The affected module's logging string is not found, while Zephyr's logging subsystem is otherwise enabled in the firmware.

Note

If Zephyr's logging subsystem itself appears disabled in the firmware, ONEKEY cannot determine whether the affected module was compiled in, and does not score the vulnerability either way.

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 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.
Rule categories	General component, Linux kernel, Android, and RTOS rules.
Viewing filtered vulnerabilities	Uncheck Show only CVEs with open status and filter for the Not affected status.
SBOM-only components	Not available for components sourced exclusively from an imported SBOM (no binary evidence to analyze).