Suggestion: addition of a `symbols` field

[jess-lowe]

We'd like to start a discussion on the addition of a somewhat standardised affected symbols field to the OSV schema. This field would allow vulnerability databases to specify the specific symbols and files that are affected by a vulnerability, predominately for reachability analysis.

Currently, data providers relay this sort of information in the ecosystem_specific field, as symbols tend to be different between ecosystems and languages. For example GO and RUSTSEC format this very differently. Outside of OSV, the CVE5 schema has the affected_files field on its affected field.

Background

Currently, many OSV entries specify an affected package but lack granularity regarding which parts of the package are actually vulnerable.

This leads to:

• High False Positive Rates: Security scanners flag every project using the package, even if the vulnerable code path is never invoked.
• Increased Triage Fatigue: Developers must manually investigate if they are actually calling the vulnerable functions.

By providing a standardized way to list the relevant symbols, tools can perform static or dynamic analysis to determine if a project is truly "reachable" and therefore at risk.

Pros

• If implemented end to end, reduces false positives for users who include a library but never touch the vulnerable code paths and allows security teams to prioritize actual exploits over theoretical risks
• Less bespoke parsers needed for different languages/ecosystems
• Alignment with industry trends like the affected_files field in CVE5.

Cons

• There’s not a lot of reachability information publicly available
• Defining a syntax that supports multiple ecosystem symbols like "Function Name" (e.g., Go) and "File Path/Line" (common in C/C++) requires careful schema design to avoid being too restrictive.
• Few tools have capabilities to actually do proper reachability analysis (likely due to the lack of data to support the analysis), so it may not be used anyway

[jess-lowe]

#516