When a package is modified locally in a codebase, we should be able track these modifications and how to identify them.
Why? Because a package may have been:
- patched for a regular bug
- patched for a security vulnerability
- patched for a new or altered feature
- updated for corrected metadata (such as origin, license, dependencies)
- renamed or its version changed (or not :] )
In all these cases, we may have some problems if we do not known about this:
- we may report it as vulnerable when this is not the case
- we may not report it as vulnerable when this is the case
- we may match it it incorrectly to an upstream version or an altered version
Tracking could be done in ABOUT files, in DejaCode and the PurlDB and be used by downstream processes to avoid false negative and false positive lookups. This is especially important when we have renamed packages that are patched but where the original unpatched package and the patched version could be both vulnerable.
When a package is modified locally in a codebase, we should be able track these modifications and how to identify them.
Why? Because a package may have been:
In all these cases, we may have some problems if we do not known about this:
Tracking could be done in ABOUT files, in DejaCode and the PurlDB and be used by downstream processes to avoid false negative and false positive lookups. This is especially important when we have renamed packages that are patched but where the original unpatched package and the patched version could be both vulnerable.