[FEATURE]: Include function as a component type

[anthonyharrison]

Describe the feature

Currently there is no way to describe the functions used within a library. When using a SBOM for vulnerability management, it would be useful to have a finer level of granularity than a library component and identify the actual functions used. Vulnerabilities in a library are typically associated with a vulnerable function and by including the functions actually used, this will aid the vulnerabity management process.

Possible solutions

Make functions as a component type. A function can then be associated with a library (or other component) to show the relationship.

Alternatives

It is possible to use the callstack within evidence object (as this has function as one of the attributes) but it is abusing the original intent of the object

Additional context

When constructing SBOMs from a binary artafect (e.g. ELF binary), the function names used within each dynamic libraries can easily be extracted. By capturing this information in an SBOM, it will improve the efficiency of the vulnerability management triage process.

[ppkarwasz]

Currently there is no way to describe the functions used within a library. When using a SBOM for vulnerability management, it would be useful to have a finer level of granularity than a library component and identify the actual functions used. Vulnerabilities in a library are typically associated with a vulnerable function and by including the functions actually used, this will aid the vulnerabity management process.

I second the idea of increasing the granularity of SBOMs, but I am not sure if listing functions is not an overkill. If a vulnerability happens in a basic function, the number of functions that calls it can be quite large.

What about a more coarse loosely defined "feature" type? Many libraries have tons of features, but applications only use some of them. For example the Python standard library could be split into (hundreds?) of "features" and applications could say which ones they are using.

[jkowalleck]

When using a SBOM for vulnerability management, it would be useful to have a finer level of granularity [...]

When constructing SBOMs from a binary artafect (e.g. ELF binary), the function names used within each dynamic libraries can easily be extracted.

For example the Python standard library could be split into (hundreds?) of "features" and applications could say which ones they are using.

have you looked at component evidence? This allows to describe call stacks, frames and functions ....
https://cyclonedx.org/docs/1.6/json/#components_items_evidence_callstack_frames

[anthonyharrison]

@jkowalleck Yes that was my original idea but it clearly isn't the intended use case. Maybe some of the call stack structure could be reused outside of the evidence object?