Beyond Reachability Analysis: Does a Vulnerability Really Affect Your Firmware?

A vulnerability match is a reason to investigate, but it doesn't tell you whether your product is affected.

When you develop or maintain connected products, a vulnerability finding creates practical questions. Does the security team need to prepare a fix? Can you rule out the finding? What should you tell a customer who asks about it?

Many vulnerability findings begin with a match between a known vulnerability and a software component or its version. However, that match alone does not mean your product is affected. You need evidence about the firmware you actually ship: the code it contains, how that code is used, and the conditions required to trigger the vulnerability.

In brief: A vulnerability match does not necessarily mean your product is affected. Reachability analysis helps determine if vulnerable code can be executed, but other conditions may also influence the vulnerability's impact. ONEKEY's Automated Impact Assessment examines relevant firmware evidence to help rule out findings, focus on vulnerabilities that need attention, and communicate the results through VEX.

What reachability analysis tells you

A vulnerability often affects a particular function or section of code (vulnerable code) within a software component, rather than every function within it. Finding the component in your software bill of materials does not establish that your application can execute the vulnerable code.

Reachability analysis investigates possible execution paths to vulnerable code.

For example, an application may call a library, which then executes the vulnerable code. An investigation can examine those connections to determine if execution can reach that code. In a broader security assessment, the question is how attacker-controlled input could travel through those components and reach the vulnerable code.

That is useful information. But establishing that code is reachable does not establish that every condition needed to exploit it is present.

Why reachability alone is not enough

Imagine an application running on a device that contains code associated with a vulnerability. Even if input can reach that code, the vulnerability may trigger only when, for example,  a specific configuration setting is enabled. If that setting is disabled, the code remains reachable, but a necessary condition for exploitation is missing.

This is why reachability alone does not tell you if a vulnerability affects your product. You also need to consider the conditions required to exploit it.

Think of these requirements as links in a chain. For a vulnerability to be exploitable, all necessary conditions must be met. If you can establish that one essential link is missing, you have evidence to rule out the vulnerability for that firmware.

This is where ONEKEY's Automated Impact Assessment comes in. Rather than reconstructing every possible attack path, it looks for evidence that necessary conditions are missing, helping you identify vulnerabilities that do not affect your firmware.

Controls behind Automated Impact Assessment

ONEKEY uses vulnerability-specific assessment rules to examine evidence in your firmware. These controls cover seven areas, from code presence to applied security fixes.

They are not seven mandatory steps for every vulnerability. The applicable rules evaluate relevant conditions, and finding some conditions present does not confirm that all other requirements are satisfied. The controls are added as:

• ‍Is the vulnerable code present?
  ONEKEY checks if the code associated with a vulnerability is actually present in the firmware. Even if the affected software component exists, the vulnerable code from that component may have been removed during the build process.‍
• Is the vulnerable code reachable?
  ONEKEY checks if the vulnerable code can be called or executed by other parts of the software. This helps determine if the affected functionality is actually used.‍
• Is the required configuration enabled?
  Some vulnerabilities can only be triggered when specific settings are enabled. ONEKEY examines configuration files and startup settings to determine if these conditions are met.‍
• Is a required dependency present?
  A vulnerability may depend on another software component to be triggered. ONEKEY checks if that required dependency exists in the firmware.‍
• Are the environmental requirements met?
  Certain vulnerabilities only apply to specific hardware architectures or enabled device features. ONEKEY checks if the firmware meets these requirements.‍
• Are security protections in place?
  Security measures, such as compiler protections, runtime protections, or other mitigating controls, may prevent or reduce the possibility of exploitation. ONEKEY checks for relevant protections when assessing the vulnerability.‍
• Has a security fix already been applied?
  A vulnerability may already be fixed through a backported patch, even if the software version remains unchanged. ONEKEY checks for evidence of such fixes in the firmware.

A practical example: From firmware evidence to vulnerability assessment

Consider a device running dnsmasq, a software component that provides network services such as DNS and DHCP. Certain vulnerabilities in dnsmasq can only be exploited when IPv6 router advertisement is enabled.

Finding dnsmasq in the firmware does not automatically mean the device is affected. ONEKEY examines configuration files and startup settings to determine if the required functionality is enabled. If the setting is disabled, this provides evidence to rule out the vulnerability. If it is enabled, further investigation may still be necessary because other conditions could affect exploitability.

ONEKEY evaluates the findings from its assessment rules using a Match Score. When sufficient evidence supports a negative assessment, the vulnerability is classified as Not affected. If it cannot be ruled out, this does not automatically mean it is exploitable.

You can review the supporting evidence in the Automated Impact Assessment tab to understand the reasoning behind the result and decide which vulnerabilities need further attention.

Here’s a dnsmasq example where the score is increased by 10 because the vulnerable IPv6 router-advertisement feature is compiled in, and the score is decreased by 20 because dnsmasq is not launched with the required IPv6 configuration:

Use VEX to communicate the result

Your assessment also needs to make sense to the people receiving it. A customer asking about a vulnerability needs more than “we checked it.” They need to understand the assessed status for your product and the reason behind that conclusion.

Vulnerability Exploitability eXchange (VEX) provides a structured way to communicate vulnerability assessments. A status communicates the conclusion; a justification explains the reason where applicable. For example, a Not affected assessment can be supported by the justification that the vulnerable code is not present. ONEKEY connects its assessment findings with VEX justifications.

ONEKEY supports VEX import and export so that you can receive vulnerability assessments and share assessments with other organizations or systems.

For your team, that connects two important tasks: deciding what a vulnerability means for your firmware and communicating that decision beyond the people who performed the assessment. The assessment supplies the reasoning; VEX provides a way to exchange the conclusion and its justification.

Focus your effort where a decision is still needed

When your team faces a long vulnerability list, investigating a complete attack path for every finding is not always the most practical first step.

You need to identify which findings you can rule out, understand why, and decide how to handle the rest. For some, further investigation will be worthwhile. For others, applying a fix may be the more practical choice.

ONEKEY’s Automated Impact Assessment supports that work by examining reachability alongside code presence, configuration, dependencies, environmental requirements, security protections, and applied fixes.

The value is not simply a shorter list. It is knowing why a finding no longer needs the same investigation effort, with evidence you can review and a conclusion you can communicate.

Key Takeaways

• A vulnerability match does not confirm product impact. Finding an affected software component is only the starting point for investigation.

• Reachability alone is not enough. Even if vulnerable code can be reached, other conditions such as configuration, dependencies, security protections, and applied fixes can affect exploitability.

• Firmware evidence helps you make better decisions. ONEKEY's Automated Impact Assessment helps you rule out vulnerabilities when sufficient evidence exists. Findings that cannot be ruled out are not automatically exploitable.

• Vulnerability decisions need clear explanations. ONEKEY provides supporting assessment evidence, and VEX helps you communicate vulnerability status and justifications to customers and other stakeholders.