Enablers for Automated Reachability Analysis

[david-lcl-lab]

Package level code analysis with an SBOM and a CVE can confirm if vulnerable code is present, but can't determine if the vulnerable function is reachable or exploitable in production. Manual verification scales poorly.

Has there been discussion of adding vulnerable function metadata to the CVE schema to enable automated reachability analysis and better prioritize patching?

[StefanSchroeder]

Before we even get to reachability of actually present code, I would like to see machine readable information about necessary compile-time options. Perhaps the vulnerable code isn't even compiled into the binary. This is particularly relevant for highly configurable packages, like kernels or web-servers.

[ccoffin]

The current CVE Record Format schema has an optional programRoutines array under the affected product object and this may be what you are looking for. It is not commonly used today, but i found a couple of recent examples below. Let me know if this doesn't address what you were looking for.

Schema definition:
https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json#L245

Examples:
https://cveawg.mitre.org/api/cve/CVE-2026-0819
https://cveawg.mitre.org/api/cve/CVE-2026-21619

[darakian]

Would something like the formats discussed in either of these two threads be aligned with what you're looking for?
eg. Call paths
pypa/advisory-database#175
openjs-foundation/security-wg#66

[david-lcl-lab]

@darakian yes call path is part of the solution and still need additional details for preconditions like build configuration or feature flags. Getting those attributes added to package ecosystem security advisories is helpful, but does not work for things like c, c++, hw vulns, firmware vulns.

[darakian]

I feel like call paths could be useful in a c/c++ context, but also lets enumerate the information we would need for a more complete solution. Build configs and feature flags both sound like parameters on a build system to me. What else?

[david-lcl-lab]

Trying to put together a list here:

1. vulnerable code and known entry points: answering which code has the bug and how does the execution flow reach that code
2. preconditions: build flags, feature flags, runtime conditions
3. completeness property for the above two items: describes if the description is complete, partial, or unknown. This enables a consumer to reach a negative conclusion when the description is complete.
4. fix presence: a way to know if the fix is present. Version alone is insufficient in the case of backports, forks. For open source this could be a fix commit, but need some other identifier for closed source like a build or release identifier.

[StefanSchroeder]

That's a great start. While build flags and feature flags are typically well defined, I wonder what runtime conditions would include. Is it only configuration? Or does it also include operational environment and interface considerations? Configuration can also be arbitrarily complex. Even though most programs are configured with key-value pairs, some other might be configurable via scripts, e.g. in Python or Lua. So let's start with the easy case, where a program or service is configured with a TOML, INI, YAML or similar simple configuration language. What I have in mind is that the notification includes a DSL to describe which conditions must be present for the vulnerability to be effective: This can include build flags, feature flags, or configuration. My favorite example is OpenSSH's configuration option PermitRootLogin. Imagine a vulnerability is only exploitable if this configuration option is set to yes (or not no, which is different!), how would we want to communicate this condition in the notification?

[david-lcl-lab]

Thanks, programRoutines looks like a staring point.

There might be a potential research topic here to unlock automated analysis at machine speed. That would be a big value for both software producers (less customer support) and consumers (targeted patching).

With enhancements to the CVE schema, sbom, and build time sidecar describing what was compiled/used a user with a deployed system could set up automated analysis to narrow uncertainty about whether a vuln affects a deployed system.