feat: introduce package UIDs for improved vulnerability mapping

[knqyf263]

Description

Currently, Trivy outputs Packages and Vulnerabilities separately in JSON format, with detected vulnerabilities including a subset of package metadata such as name and version. However, identifying the original package from this limited metadata can be challenging in certain scenarios:

• When multiple lock files use the exact same package name and version (but have different dependencies or line numbers)
• When the same package is installed in multiple paths

To accurately associate detected vulnerabilities with their corresponding packages in these cases, this PR introduces the concept of package UIDs. These UIDs are calculated from the Package struct and serve as unique identifiers for each package. It's important to note that these values (hashes) are not the same as digests used for ensuring integrity; they are solely intended for uniquely identifying packages within Trivy.
One advantage of using hashes instead of UUIDs is that the same hash value will be generated across multiple runs for the same package.

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[knqyf263]

@DmitriyLewen Please let me know if you have a better idea.

[DmitriyLewen]

My first thought about this was "Why can't we just use the file path" (another reason to get rid of the two file paths).
But after thinking a little, I realized that this was a bad decision.
Even if we can update our logic - it will not help the users because the lock file may contain many dependencies and the user has to check all the packages of the lock file to find the required package.

So your solution is good. This will make it easier to detect the vulnerable package in Packages.
Also after these changes we will be able to remove some duplicate fields because searching for packages will be easier.

But I was worried about the hash. It is inconvenient to use manually - this value means nothing to the user.
I thought about purl + filePath qualifier (we did this for CycloneDX BomRef).
But I realized that this doesn't make sense - you can see the name/version/etc. in the vulnerability fields, but for searching it makes no difference what value to paste in Ctrl+F.

So I think this is a good idea and should be implemented as you suggested.
Tell me if I can help you with this PR.

[knqyf263]

Thanks for your input.

I thought about purl + filePath qualifier (we did this for CycloneDX BomRef).

PURLs are not IDs that uniquely identify installed packages, so we used to use PURLs + file paths, but that was not suitable for the PURL specification. Then, we have now changed the logic of the CycloneDX output and use UUIDs when PURLs conflict.

[knqyf263]

@DmitriyLewen I didn't come up with a good idea of where we should calculate the UID. Please let me know if you have a better one.

[DmitriyLewen]

I think you chose a good place. we create identifiers (purl, uid) in one place.

[knqyf263]

@DmitriyLewen It's finally ready for review! The tests passed in my env, but failed on GitHub Actions because some tests run only on Linux.

[DmitriyLewen]

LGTM