Shouldn't only stable versions be considered as latest verion by Dependency Track?

[walterdeboer]

Our compagny has a policy that every used component should be stable and should be the latest major version, or one major version before (warn). Older versions are not allowed (fail). Besides that we also look at component age. Component age is well covered in Dependency-Track, although the age isn't always known. Component versions are also covered, but the latest version column in the component overview currently has two issues (imho):

1. Unstable versions are being reported as the latest versions
2. Sometimes lower versions are being reported as the latest version

Unstable versions
Although an unstable version might technicaly be the latest version, and one would sometimes choose to use it. I don't think Dependency Track should recommend using them. Only when no stable versions exist these should be considered.

Lower versions
In most repositories the last published date is the date the last artifact was uploaded to the repo. This might be a patch version for an older component, suddenly making it the "latest version". Latest version should intuitively mean the version with the highest number, even if the upload date is not the latest. Only when the "latest version" equals the "highest version" the published date is correct for the "highest version". Cargo and Go are the only repository that distinguishes a highest stable version naturally.

Solution
To solve both issues I have submitted #2501 It uses regex expressions to check for unstable versions and distinquishes semver, non-semver and Linux versions, using epoch. Worst case scenario the regex failes and the same "incorrect" result is returned as in the current version. It also tries to sort the versions semanticaly for all kinds of version numbers to resolve the highest version number.

If requested the new behaviour could be made optional with an admin switch, but honestly I think this should be the default

Before:

After:

I'm interested to hear how the community thinks about this

[syalioune]

Hello @walterdeboer

That's a very interesting improvement on component metadata search.

I personally feel like the requested behaviour depend highly on your use case and on how you want to use DT. To some extent, being notified that there are newer versions (unstable or stable) of a given component could be of virtue (e.g. internal components).
That being said, I think there's a safe separation of concern in DT :

• Component Meta analyzer give information about the latest known artifact (unstable or stable) for a component regardless of your use case and company policy
• Policy engine give you the ability enforce your company policy base on your use cases

I appreciate that in your case, having warning in the dashboard if you only consider stable versions could be troublesome. The new behaviour could be opt-in in the administrative panel so that user are given the choice.

No comments on the second issue (lowest version) : Good spot !

[walterdeboer]

Thanks for your thoughts Syaloune! I'm guessing most DT users are expecting stable versions only, see issues #513 and #1049 for example. I could even imagine unstable versions posing a more of a security risk than stable ones... But let's not assume. An admin switch will satisfy both use cases.

[walterdeboer]

P.S. when using a latest beta or snapshot version for example, it will be higher than the latest stable version, so no warnings there. I't will just not reccommend latest beta versions when you're on the latest stable...

[walterdeboer]

Still feels very uncomfortable getting a warning from a security tool telling me i'm not on the latest beta... Maybe it feels better if there wouldn't be an orange warning sign, but a more friendly notificatiion sign

[walterdeboer]

Ok, how about we let the Component Meta analyzer give information about the latest known unstable AND stable artifact? Two columns could be shown in the components overview, one for stable, one for unstable latest version. For software in active development one would probably consider the latest unstable version. For production software one could consider stable only. This would then be something to deside differently for each project

[syalioune]

I like this idea ! Giving choice is most of the times the best answer when dealing with such a wide audience.
Two colums could be shown or just one based on the admin switch