AboutCode project: tools and data to uncover things about code: the provenance, origin, license, and more (packages, security, quality, etc.) of FOSS code
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.