The hard reference to specific package versions has lead to diminishing returns.
By that argument, every package we depend on should have a floating version. But...
Floating versions breaks the concept of reproduceable builds. This could complicate our ability (and our customer's ability) to troubleshoot issues that come from non-deterministic package versions.
The latest version isn't always safe - it could also have a vulnerability. If you deploy your app and a vulnerability is found in a package that has a floating version do you know which version you deployed?
The reason we have a specific version is because that's the version we tested the product with and can reproduce bugs with, if a customer has an issue.
In general, floating dependency versions are an anti-pattern for libraries and products that others take a dependency on. If you want floating versions for your direct dependencies, you can definitely go that path.
I think nearly all of the vulnerabilities are actually in Image Magick itself, not even the .NET wrapper NuGet package.
They're also not new vulnerabilities, but thanks to increased interest in the library and analysis of the C codebase, the library is becoming more secure. This is a good thing!
You can specify your own package version explicitly in your project so only that version is used by your app. I believe this is a better approach than a floating version number.
To reduce the workload for your team, I would recommend having your AI agent check for vulnerability reports from dotnet CLI output, identify if there are newer package versions, and update the packages.
Additionally, we have official guidance in our documentation on how to manage vulnerabilities in transitive dependencies, including how we resolve these issues when we identify them in Xperience by Kentico.
