Handle Gitlab false positive

[pombredanne]

This https://gitlab.com/gitlab-org/advisories-community/-/blob/main/maven/org.owasp.antisamy/antisamy/CVE-2023-49093.yml started as an advisory and then became a "False positive"
Gitlab updates the description and title in these cases, and there are 150+ such advisories.

The outcome is invalid data. We should support these and update accordingly

See https://public.vulnerablecode.io/packages/pkg:maven/org.owasp.antisamy/antisamy@1.7.4?search=antisamy

There https://public.vulnerablecode.io/vulnerabilities/VCID-zx5k-4m3n-aaaj does NOT apply to antisamy

See attached for a list of patterns found in GitLab advisories
fp.txt

@julianthome gentle ping... do you know if there is a list of patterns we can track? Thanks!

In the same domain, we should also find is there are other related unstructured patterns in GitLab and also:

• Handle "Disputed" markers in CVEs texts
• Handle "Awaiting Analysis" in CVEs

[pombredanne]

Some input from today's weekly call:

• I pointed that we would likely need to keep track of which advisory contributed to create a vulnerability and a package-relationship in all cases to track the changes of advisories from good to bad so we can know which relationship need to be amended
• @Hritik14 suggested we could may be put git to good use to keep track of the records' version changes, and this would help investigate the issue more efficiently.
• Using git as in FederatedCode could be a really nice thing to also help with data distribution, and we would also add advisories to get a full picture in all cases.

[Hritik14]

Adding to above,

In the git based design, the original data sources persist in our storage. The import operations do not overwrite the existing data from the same data source, instead it maintains a diff-based (call it git?) record of all the changes an advisory goes through. This shows a timeline of the advisory as it grows.

The benefits are:

1. Get to know how many times an advisory has changed and possibly flag such data sources. A change could potentially be a good thing about the data source if it slowly gets reflected over other sources for the same vulnerability over time. It could be a bad thing if only a single data source goes through the change or it goes through the change after every other possible data source has gone through it.
2. Once the cat (advisory) is out of the box, it persists for eternity on the internet. We should have a record of such advisory even if it means only to mark it as "changed" or "updated". This will help with indexing from a search engine point of view.
3. Hypothetically, an older revision of the advisory may be more accurate and there might be a need to revert back to this older version. This revert opinion can be driven by the decentralized project (FederatedCode). It gives a say to the users of FederatedCode about a change in an advisory.

The implementation of such a model needs to be discussed in detail after the idea sounds convincing enough.