Tool should recommend the start year based on the oldest vulnerability

[prabhu]

Currently, NVD_START_YEAR is configurable with a default value of 2018. The tool should recommend a start year based on the oldest CVE found. If a CVE belonging to the year 2018 is found then the scan should recommend a re-scan with start year of 2017 (Previous year)

This can be implemented in the analysis module.

Docs should be updated based on the recommendation.

[timmyteo]

@prabhu Is this feature still desired? I am looking at how to implement this and here are my thoughts:

• In the prepare_vex method, this loop is iterating over the findings. In this loop, each finding should have its year inspected and a variable will keep track of the oldest year. An INFO message will be printed to console after the loop completes, assuming that the recommended year (previous year) != NVD_START_YEAR.
• The message printed out shall read like the following example, where the year values are variables and not hardcoded: "The oldest CVE discovered in this scan is associated to the year 2018. It is recommended that you re-scan, setting the environment variable NVD_START_YEAR to the previous year (2017). For more information on the NVD_START_YEAR environment variable, please see: https://github.com/owasp-dep-scan/dep-scan#customization-through-environment-variables"
• Please let me know if there is a better way than the following to determine the year of the CVE. The vid variable will have the CVE ID value, which will look like CVE-2023-46255 (CVE-YYYY-NNNNN) for NVD items. The year of the CVE can easily be extracted from the CVE ID from the YYYY portion. This works great for CVE from the NVD. But as for the CVE that come from Github, I believe that the vid value will look like GHSA-jg7w-cxjv-98c2, which isn't helpful for determining the date. Please let me know your thoughts on GitHub vulnerability year determination.

Please provide any feedback regarding this overall approach if this feature is still desired. Also, what would you want to see updated in the docs for this?

[prabhu]

@timmyteo, Thank you for looking into this. It is a very clever idea to use the CVE ID to infer the year, which could usually be enough—I'm looking forward to seeing this feature!