Replace `grype db diff` with `grype db search --since DATE`

[wagoodman]

As currently written the DB diff command will be cumbersome to keep as a feature while working on v6. We could leave DB diff in tact for v1-5 schemas, but this would be confusing for users attempting to use this diff feature for the latest (v6) DBs.

V6 currently is going to have a blobs table where digests for content could be recomputed and used as a foundation for a diff, however that is out of scope for v6 unless there is a convincing argument / need to keep this feature and add to the v6 scope further.

[TimBrown1611]

hi! @wagoodman diff is important since we want to track changes of the DB. how can it be done on v6 schema? will v6 contain update date for each record? thanks!

[wagoodman]

As eluded to in https://github.com/anchore/grype/issues/2128#issuecomment-2375114119 there is a way to compute the records that differ.

Is this an important use case to you? If so, can you tell us more about why so?

We dropped figuring this out in v6 to cut scope, but if we have enough users that really depend on this then that would be good reason to keep it in scope (in which case I'd close this issue and make a new one on how to implement the diff command).

[TimBrown1611]

I use this command to handle states of last-modified CVEs. I have to do it separately since the DB is stateless, and some sources don't provide modified date or create date.

[willmurphyscode]

@TimBrown1611 when you say some sources don't provide modified or created date, do you mean in the upstream data? Like, are there specific data sources that grype db consumes that are missing this data? If so, which ones?

If grype had a date added and date updated date for most issues in each database, would you still need grype db diff?

[willmurphyscode]

From discussion on our livestream on 10 October 2024, we had the idea:

Can we add grype db search --since DATE to print information about CVEs that were added or changed since DATE. Schema v6 would support that, and it seems like this is a simpler, more flexible way of comparing two databases. @TimBrown1611 would that meet your needs?

Things to consider:

1. What if data is deleted between db versions?
2. How to handle differences between what dates are available from different providers?

[TimBrown1611]

Hi,

1. If a CVE was deleted its ok since it will not appear in the results.
2. Namespace field will be removed in v6?

[wagoodman]

1. If a CVE was deleted its ok since it will not appear in the results.

That's correct -- this is one difference between how db diff works today and what db search can surface.

2. Namespace field will be removed in v6?

The Namespace field will be removed from the D, however, grype output will continue to surface Namespace as it has in the past. This field will most likely be removed in grype v1, but that has not been finalized yet. The idea when implementing v6 was to not perturb the user-facing facade any more than we need to in order to upgrade the DB schema -- so while some breaking changes were made (such as removing the diff command) the JSON output should be the same.

[kzantow]

I believe this has been implemented for v6, using the --modified-after flag; this works:

$ grype db search --modified-after 2025-02-20
VULNERABILITY        PACKAGE                                                                                                                    ECOSYSTEM     NAMESPACE                   VERSION CONSTRAINT
CVE-2015-2973        cpe:2.3:a:welcart:welcart_e-commerce:*:*:*:*:wordpress:*                                                                   wordpress     nvd:cpe                     <= 1.4.17
...