Added support of deprecation of Nuget and Npm

[pohli81]

Added support of deprecation for Nuget and Npm

Description

The component meta information is extended by the deprecation string and a boolean whether the component is deprecated or not. Currently this is implemented for Nuget and Npm. This enhancement can be used to show deprecation information in the component list as in the following example:

Addressed Issue

This PR should fix #2388.

Additional Details

Currently it is implemented only for Nuget and Npm. It has to be implemented for other package repositories as well.

Checklist

• I have read and understand the contributing guidelines
• This PR fixes a defect, and I have provided tests to verify that the fix is effective
• This PR implements an enhancement, and I have provided tests to verify that it works as intended
• This PR introduces changes to the database model, and I have added corresponding update logic
• This PR introduces new or alters existing behavior, and I have updated the documentation accordingly

[valentijnscholten]

I recently thought about doing something like this. But I realized it might be good to align any changes here with the (hopefully) upcoming OWASP Common Lifecycle Enumeration.
It's not done yet, but there are some initial events defined such as endOfSupport and endOfLife.

https://docs.google.com/document/d/1sRMS1IX0r7ZkYthDR0VY1bYyvp_6K_xw4sR1vZwla8E/edit?tab=t.0

Would it be wise to pick fieldnames for DT from those already mentioned in the document?
Should it be made clear in the docs which MetaAnalyzers do (not yet) support these fields?

[nscuro]

@pohli81 Thanks for the PR!

Are deprecations in the NuGet and NPM ecosystem on a per-package, or a per-version basis?

The limitation we have is that RepositoryMetaComponent records are tracked on the package-level. The records are "keyed" by repositoryType, namespace, and name. version is not part of the model.

So if only a subset of versions was to be deprecated, we cannot record this in RepositoryMetaComponent, as it would then erroneously flag current versions as deprecated, too.

I do agree with @valentijnscholten in that we should look towards CLE and align with it as much as possible. But in any case, we probably need a slight refactoring to support resolution of metadata on the version-level. Or even more granular, on the full PURL, so that qualifiers etc. are also considered.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for 70bf9781	✅ 79.69% (target: 70.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (70bf978)	Report Missing	Report Missing	Report Missing
Head commit (87a89b1)	23073	18330	79.44%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#4521)	64	51	79.69%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[pohli81]

Thanks for the answers. The deprecation information is on version level. My implementation sets the deprecation only in case the latest version is marked as deprecated. Unfortunately the reason for deprecation is mentioned in the message (EOL, renamed, no longer maintained, ...) so it is currently not easy to inference the reason. At least there is an enumeration in Nuget describing the reason (see https://learn.microsoft.com/en-us/nuget/api/registration-base-url-resource#package-deprecation).

I added further tests to make the limitation transparent. There was also a bug I made in the NpmAnalyzer implementation I also fixed.

You are right @nscuro that the implementation based on version level needs a larger refactoring. The current impementation allows to make it visible in the UI, that there will be no newer package and Dependency Track can show the reason of the deprecation in a message.

I read the specification but currently it is not obvious to map the specification to the information available in the repositories and the data model of Dependency Track. So perhaps there could be a versionEvent field of type enumeration with the potential members out of the specification instead of isDeprecated of type boolean.

If we find an acceptable solution I can implement the same for further repositories supporting deprecation.