Application Security — Project Dependency "Version Bumps" Demystified or Modern Security Realities in .NET / NuGet Ecosystem

In this post, I want to show you how to effectively upgrade vulnerable third-party dependencies in your projects, highlight .NET industry best practices, and also clarify how DevExpress helps you mitigate security-related risks in general. For illustration purposes, I will use a System.Security.Cryptography.Xml-related security advisory, which Microsoft published in the GitHub Advisory database last week.

You probably already know about this report from NuGet, Visual Studio, or DevExpress Support Center. And if not, it's important to note that such reports impact every NuGet package, which has direct or transitive dependencies on the highlighted package version (it's not specific to DevExpress directly). Ultimately, even if such external advisories do not originate from DevExpress, they may impact DevExpress packages and DevExpress customers via a chain of system or third-party sub-dependencies. Hence, it's still our responsibility as a component vendor to inform our customers, improve transparency and awareness of the best practices, update problematic dependencies of affected DevExpress packages in our new releases.

As a result of this System.Security.Cryptography.Xml advisory, you might see warnings in your Solution Explorer, NuGet Package Manager or just build output (example for .NET 8 projects). Since we also build .NET projects and use the same development tools daily, we knew about this new report right after its publication in the GitHub Advisory database on April 13-14th 2026 (much like you, other vendors or anyone else). Fortunately for all, a general fix (upgrade to the latest package version) is also available for all affected DevExpress and other vendor packages that were released prior to publishing such advisories (for example, DevExpress v25.2.6 released on 07 Apr 2026 - a week before this particular report).

How to Fix This

General Fix Idea (Applicable to All Methods)

The beauty of such simple "version bump" vulnerabilities is that you can easily fix it yourself immediately - without awaiting anyone (vendors, new package versions, etc).

You can bump the version right in your project for affected third-party dependencies (such as Microsoft .NET System.XXX or others), as described in the "How do I fix the issue?" section of the official advisory. Anyone can apply this fix at their convenience (even "within hours" of publication of the original security advisory in the CVE / GHSA database), because in this instance it's literally one line of code in one or a few places only.

I also want to emphasize that when a vulnerability occur in a system or core .NET library, many other dependent system, .NET BCL, and vendor libraries are impacted. For example, System.Security.Cryptography.Xml is used by System.ServiceModel.Http, System.ServiceModel.Primitives, System.ServiceModel and others. They are also used directly or indirectly in a dozen more packages - all are often used in many apps of even medium complexity (I am not even talking about complex apps). You will have to update those dependencies anyway, regardless DevExpress or any other impacted package vendor/third-party.

Notwithstanding the negative effects of dealing with a vulnerability, NuGet and its best practices such as Central Package Management (CPM) exist in the development world - all to deal with such incidents quickly and to address modern realities effectively.

Method #1: You Have a Few Projects Only or Are NOT Using Central Package Management (CPM)

The standard Microsoft solution is to add a direct NuGet package reference (System.Security.Cryptography.Xml in this case, but it can be another third-party package) to your required projects (CSPROJ/VBPROJ) and set its VersionOverride property to the patched version from the advisory (for example, 8.0.3 for .NET 8):

• .NET 8: <PackageReference Include="System.Security.Cryptography.Xml" VersionOverride="8.0.3" />
• .NET 9: <PackageReference Include="System.Security.Cryptography.Xml" VersionOverride="9.0.15" />
• .NET 10: <PackageReference Include="System.Security.Cryptography.Xml" VersionOverride="10.0.6" />

As you can see, this is a one-line solution, which you can copy into required projects where problematic direct or transitive dependencies were detected. In my example, I copied it into 2 projects only (so, 2 code lines in total to maintain temporarily).

Method #2: You Have Multiple Projects or Are Using Central Package Management (CPM)

If you have too many projects so that even the one-line solution is not practical to copy/maintain, then you must seriously consider using Central Package Management (CPM). CPM is the best or recommended development practice regardless this vulnerability discussion anyway.

Once you configure CPM for your solution, you can add a global package reference to your Directory.Packages.props file:

• .NET 8: <GlobalPackageReference Include="System.Security.Cryptography.Xml" Version="8.0.3" />
• .NET 9: <GlobalPackageReference Include="System.Security.Cryptography.Xml" Version="9.0.15" />
• .NET 10: <GlobalPackageReference Include="System.Security.Cryptography.Xml" Version="10.0.6" />

Regardless how many projects you have in your .NET solution (5, 100, 200, etc.), this is always a one-line solution to maintain temporarily - that is the beauty of CPM in action.

CPM is nowadays also super-fast to add to your non-CPM solution with AI assistants. If you already maintain a Directory.Packages.props, replacing "PackageVersion" with "GlobalPackageReference" is fast too with or without AI.

Method #3: Await & Install a New/Fixed DevExpress Build

Affected DevExpress packages are typically updated in the next minor release according to our Security Advisories and Product Update Process. This usually takes a few weeks or so.

If you wish, you can request a hot-fix/intermediate build as well. For example, for this particular System.Security.Cryptography.Xml vulnerability we updated our packages and published a fixed night build at https://downloads.devexpress.com/HotFixes/DXP/v25.2. NOTE: review our hot-fix policy first before applying.

Frequently Asked Questions (FAQ)

Does DevExpress release builds when it already "knows" about a vulnerability such as System.Security.Cryptography.Xml 8.0.2?

No. In this instance, DevExpress v25.2.6 was released on 07 Apr 2026, many days before the aforementioned vulnerability was even published/known to the world.

DevExpress uses a multi-layered scanning strategy for every PR (code repositories and container images are continuously and automatically scanned for vulnerabilities during the CI/CD process) prior to release. This includes Static Application Security Testing (SAST) for product source code, Software Composition Analysis (SCA) for vulnerable third-party libraries/license compliance, antiviral software installation and artifact scanning. High-risk vulnerabilities trigger an automatic 'Build Fail'. DevExpress employs a combination of commercial and internally managed security tools (including, but not limited to Veracode, Dependabot, CodeQL, NuGet Audit, VirusTotal, etc).

For more information, please review Information Security and Security - What You Need to Know.

How often similar security advisories for system/core or popular 3rd-party packages are reported?

Quite many every day - it's best to estimate it for yourself at https://github.com/advisories (filter by NuGet, NPM, or other keywords). This is also not the first and not the last vulnerability in a system/core library. For example, 3 security advisories were published for System.Security.Cryptography.Xml alone in less than 2 years. And I am not even referring to others in popular SQL Client, JSON, OData, and other libraries with even more dependencies.

To better understand the situation, let's make a thought experiment: imagine that a vendor started publishing new official builds in response to each and every security advisory immediately. For this (in theory), one would need the previous official build, bump the affected NuGet package version (such as System.Security.Cryptography.Xml), re-build, re-run automatic tests and security checks, and publish a new official build. As a result of this experiment, customers would need to deal with 3-5 new minors a week. That rough number is only considering the current CVE/GHSA update rate for .NET - for JS/NPM it would be even more frequent. As you may understand, not many customers or businesses would want such an update carousel.

How often DevExpress "bumps versions" of their .NET packages internally in response to security advisories for external NuGet packages?

Multiple times every month or so. To give you a full picture, DevExpress v25.2 .NET packages depend on over 150+ system/core .NET packages (based on our "c:\Program Files\DevExpress 25.2\Components\Sources\Directory.Packages.props" file or our public SBOM artifacts, which you can check for yourself). Our .NET packages often include our JS packages as assets, these JS packages depend on external JS/NPM packages, and so on - you got the idea or the high chances of a "version bump" at such a scale.

Good news is that we heavily rely on CPM, so this "version bumping" itself is now a mechanical routine - it just takes time and discipline from our product teams. This is basically what every developer of any serious or complex application/solution is doing nowadays, because security matters.

Why does not DevExpress release a new/fixed build within hours after a security advisory is published?

As noted in Method #3, we follow our Security Advisories and Product Update Process and update affected DevExpress packages in the next minor release (in a few weeks or so on purpose). All our builds must pass standard testing procedures. We do our best to test our software and it takes time (for example, we intentionally did not release v25.2.7 "within hours"). We simply do not want our customers rely on poorly tested software (and potentially experience bigger issues with the upgrade).

Fortunately, the current release cadence suits the majority of our customers and proved itself over the years well. In urgent cases, customers can either apply a one-line solution in their projects or request a hot-fix/intermediate build. That is also why Microsoft has Patch Tuesday monthly and NOT "hourly", and many other vendors follow similar security and testing protocols. Otherwise, it would be a mess for all vendors and customers in the .NET ecosystem, for JS ecosystem it would be even worse due to a different NPM package update strategies and the number of updated packages. In other words, the solution should never be worse than the original problem.

See Also

Microsoft clarified this general pattern in their blogs and docs, because this version upgrade is needed regularly:

• NuGetAudit 2.0: Elevating Security and Trust in Package Management (see the "How to upgrade transitive packages" section)
• Overriding Package Versions

We also described how to fix this and similar customer issues at .NET — About NuGet Package Audit and "False-Positive" Security Warnings.

Please let me know if you have any DevExpress-related questions or suggestions.

Thanks,
Dennis Garavsky
Principal Product Manager
dennis@devexpress.com

Free DevExpress Products - Get Your Copy Today