Key Takeaways:

• Vulnerability scanners flag CVEs at the package level, often including vulnerabilities in code that was never compiled into your build.
• RunSafe’s reachability analysis automatically triages these out by cross-referencing CVEs against which source files were actually included in your binary.
• RunSafe’s C/C++ build-time SBOM generation captures file-level inclusion data, which makes our reachability analysis reliable in embedded environments.
• Vulnerabilities in code that was not compiled in are automatically marked Not Affected with a Code Not Present justification, following the CycloneDX VEX standard.
• The result is a more accurate vulnerability list and documented, defensible triage for CVEs that don’t apply to your specific build.

Product security teams working on embedded systems routinely deal with vulnerability lists that are longer than they should be. You run a scan, hundreds or thousands of CVEs come back, and a significant portion of them are in code that was never compiled into your product. You know they’re not relevant, but without a systematic way to document that, your team still has to work through them.

RunSafe Security’s reachability analysis feature addresses this directly. By cross-referencing CVEs against which source files were actually compiled into your build, RunSafe can automatically triage vulnerabilities where the affected code is not present—with documented, standards-compliant justification—so that what remains on your list is a more accurate picture of your actual exposure.

Listen to the Audio Overview

 

The False Positive Problem Is Worse Than It Looks

Vulnerability scanners do exactly what they’re designed to do: they match components in your software against known CVE databases. The problem is that those databases describe vulnerabilities in source packages, and source packages contain far more code than what ends up in any given compiled binary.

For example, when you build a Linux-based embedded system, you don’t include every file in the Linux source tree. You’re compiling a specific subset of drivers, modules, and subsystems that match your hardware and use case. But most vulnerability scanners have no visibility into that boundary. They see “Linux kernel” in your Software Bill of Materials (SBOM), match it against every CVE ever filed against the Linux kernel, and hand you the full list.

For a Yocto image, that can easily mean thousands or more of flagged Linux kernel vulnerabilities. Many of those can be in code that was never compiled into your image, like drivers for hardware you don’t use, subsystems your product doesn’t need, or features you explicitly disabled at build time. They’re not in your product. They can’t be exploited. But without a systematic way to prove that, your team has to treat them as real until proven otherwise.

That’s time spent on triage that doesn’t improve your security posture, and it makes it harder to prioritize the vulnerabilities that do warrant attention.

How Reachability Analysis Works in the RunSafe Security Platform

RunSafe’s reachability analysis works because our SBOM generation happens at build time.

Most SBOM tools operate by scanning binaries or package manifests after a build is complete. They can tell you what packages were declared as inputs, but they can’t tell you which files from those packages were actually compiled. For reachability analysis, that distinction matters. You need file-level data to determine whether a specific vulnerable file was included in your build.

RunSafe’s build-time SBOM generation was built for C/C++ embedded systems, where this problem is most acute. Traditional embedded builds don’t have package manifests. Dependencies are statically linked. Components are frequently mixed, modified, or vendored in ways that make post-hoc scanning imprecise.

By capturing file-level inclusion data during the build itself, RunSafe has what it needs to perform reachability analysis against CVEs. 

RunSafe instruments the build process itself. As your compiler processes each source file, RunSafe records it. By the time your build completes, RunSafe has a precise, file-level inventory of every source file included and, by extension, every file not included.

When CVEs are then matched against your components, RunSafe checks whether the files identified in the CVE’s affected code paths appear in your build inventory. If they don’t, the vulnerability is automatically triaged with appropriate VEX justification, following the CDX standard.

Reachability Analysis Example: Yocto Linux Image

Yocto-based Linux images are a good illustration of where this matters in practice. A standard scan of a Yocto image might flag thousands of Linux kernel CVEs, because the scanner sees the kernel as a component and matches it against every CVE filed against the Linux kernel source. 

But a Yocto build only compiles the drivers and subsystems configured for your specific hardware. A CVE affecting a Bluetooth driver is not relevant if your device has no Bluetooth support and that driver was never compiled in. The same applies to sound drivers, networking subsystems, or any other kernel component your build excludes. 

Reachability analysis identifies which flagged CVEs fall into this category and automatically triages them, so your team doesn’t have to work through them by hand.

What This Means for Your Team

The practical effect of reachability analysis is a more accurate vulnerability list that better reflects the code that’s actually in your build.

Rather than working through a list of thousands of kernel CVEs to determine which apply, your team gets a filtered view that shows vulnerabilities in code that was never compiled, with those vulnerabilities already triaged and documented. What remains are the vulnerabilities in code that are genuinely present in your build and more likely to warrant attention.

This has several downstream benefits:

• Faster, more defensible triage. When regulators, customers, or internal stakeholders ask how you assessed a CVE, you can point to a standards-compliant VEX assertion with a documented justification rooted in build-time data, rather than a manual determination.
• Reduced alert fatigue. When a significant portion of your vulnerability list is noise, it’s harder to focus on what needs action. A more accurate list makes it easier for your team to prioritize effectively.
• More time on what matters. Time spent triaging CVEs that don’t apply to your build is time not spent remediating ones that do. Reachability analysis automates a class of triage work, freeing your team for higher-value security tasks.
• Traceable, repeatable reporting. Because RunSafe’s reachability analysis ties directly to build-time SBOM data, the results are consistent across builds and auditable.

Get Started with Reachability Analysis

Reachability analysis is available now in the RunSafe Security Platform. If you’re already using RunSafe for SBOM generation, the capability builds directly on the file-level data you’re already collecting.

If you’re not yet using RunSafe and want to see how reachability analysis could reduce your vulnerability backlog, schedule a consultation with our team to walk through your specific build environment and what results you can expect.