feat(cli): add nvdDatafeedStartYear option for the NVD data feed

[liotur]

Description of Change

Adds a --nvdDatafeedStartYear option to the CLI. It sets the existing nvd.api.datafeed.startyear setting, which the NVD data feed update already uses to choose which yearly files to fetch. Until now the CLI could only set it through --propertyfile.

With it, the command from the issue only fetches the files from 2018 onwards:

dependency-check.sh --updateonly --nvdDatafeed=https://dependency-check.github.io/DependencyCheck_Builder/nvd_cache/nvdcve-{0}.json.gz --nvdDatafeedStartYear=2018

Notes:

• The year is validated like the other NVD options and must be between 2002 and the current year. The feed has no files before 2002, and such a year makes every update download the whole feed again. A future year makes the first update fail with a NullPointerException in getUpdatesNeeded.
• It only affects the data feed; updates from the NVD API are unchanged, as discussed in the issue. The arguments page notes that switching to the API afterwards does not fetch the skipped years.
• The option is added to --advancedHelp, the CLI arguments page and the bash completion script.
• Scope is the CLI, as the issue asks. The Maven plugin and Ant tasks don't expose this setting either; I can add them in a follow-up if that's wanted.

Checked by hand: --updateonly --nvdDatafeed=<hosted feed> --nvdDatafeedStartYear=2026 on an empty data directory downloaded only nvdcve-2026.json.gz and nvdcve-modified.json.gz.

Related issues

• fixes Support "NVD start year" for CLI #7569

Have test cases been added to cover the new functionality?

yes: AppTest checks that the option reaches Settings, and CliParserTest checks that years before 2002 and years in the future are rejected.

[chadlwilson]

Im not sure there is any need or demand for this.

do you actually have a use case for this?

[liotur]

Fair question. It's not a use case of my own: I picked it up from #7569, which @marcelstoer opened for --updateonly --nvdDatafeed runs, after Jeremy said it could be exposed for the data feed.

I think it's still worth keeping, for two reasons. The Gradle plugin already exposes it as nvd.datafeedStartYear (dependency-check/dependency-check-gradle#443), so removing it would be a breaking change there. And the CLI can already set it today through --propertyfile, just without any checks: a future year makes the first update fail with an NPE, and a year before 2002 makes every update re-download the whole feed. This PR validates the value, so it makes the existing setting safer rather than adding a new one.

I agree the missing-CVE risk is real, so I'm happy to make it explicit: log a warning when the start year is after 2002 that older CVEs won't be detected, and say the same in the help text. If you'd still rather drop the setting, I can do that instead.

[chadlwilson]

Yeah, when that was opened the transition to the NVD API was underway I believe and the earlier mentioned flag was removed from the Maven and Ant plugins. The gradle plugin is an outlier, partly because it is maintained in a different repo which lags this one.

Its also possible right now to set all these values with JVM system properties via -D args (and thus JAVA_TOOL_OPTIONS env var for the cli) so the question is whether it's worth adding yet another integration-specific value.

If we do this i'd prefer it was from a real user request in the CLI. @marcelstoer is a contributor so he may have been raising the earlier issue after looking at someone else's issue rather than for his own use. Not sure.

I'd also prefer it is named consistently so it is clear it only affects the data feed, not normal API usage, similar to how it is named within the Gradle plugin, so nvdDatafeedStartYear.

[liotur]

Thanks, that context helps. I've renamed it to nvdDatafeedStartYear to match Gradle and make it clear it only affects the data feed. On whether it's needed, I'll leave that to @marcelstoer since he raised it. The one thing the option adds over -D is that it shows up in --advancedHelp and the value gets validated.

[chadlwilson]

Yup, fair point if we want people to use it. Some settings are deliberately obscure as using it can have bad consequences (like this one, potentially creating false negatives and positives).

[chadlwilson]

@jeremylong perhaps you could have a look at the comments and discussion with Marcel at #7569 (comment) to decide the future of nvd.api.datafeed.startyear. Personally I think we should remove this whole underlying setting, so don't think we should start referencing it in more integrations like this PR does, but you may have a different opinion.