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 upgrade vulnerable third-party dependencies in your projects, highlight .NET industry best practices, and clarify how DevExpress helps you mitigate security-related risks. For illustration purposes, I will use a System.Security.Cryptography.Xml-related security advisory, which Microsoft published in the GitHub Advisory database on 14 April 2026.

You are probably aware of this report from NuGet, Visual Studio, or the DevExpress Support Center. If not, it's important to note that such reports impact every NuGet package, which has direct or transitive dependencies on a 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/awareness, and update dependencies for 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/9/10 projects). Since we also build .NET projects and use the same development tools daily, we knew about this new report immediately after its publication in the GitHub Advisory database on 14 Apr 2026 (much like you 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

Evaluate Vulnerability Risks First

If you ask security specialists or CSOs, you will hear that for any specific case/project, it's necessary to analyze Reachability/Exposure/Exploitability, the three critical pillars in modern Risk-Based Vulnerability Management (RBVM) and Exposure Management. In short, get started with these questions:

Notwithstanding the negative effects associated with a vulnerability, your actions and timing may differ based on the answers above. Fortunately, .NET/NuGet best practices also exist in the development world - all to deal with incidents quickly and to address modern realities effectively. For example, in our experience, the dotnet nuget why tool and AI can be quite helpful for the early analysis. Some incidents can be resolved locally while awaiting an "official" fix from a vendor. Also, Central Package Management (CPM) can reduce long-term maintenance costs and make full control easier even with hundreds of 3rd-party dependencies.

General Fix Idea for Simple Minor/Patch Version Bumps (Applicable to All Methods)

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

You can bump the minor/patch 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 occurred in a system or core .NET library, many more 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. In their turn, 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.

Method #1: You Have a Few Projects 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 recommended development practice regardless of this vulnerability discussion.

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. The downside of global package reference above is that a package will be used by every project in a repository (this is fine for many situations, while you await an "official" fix).

CPM is 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 also fast - with or without AI.

Method #3: Await and 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 (clarified below).

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 v25.2 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 consider 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 thought 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 will agree, 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 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 yourself). Our .NET packages often include our JS packages as assets, these JS packages depend on external JS/NPM packages, etc - you get 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 DevExpress choose not to 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). We partially clarified this release cadence in the section "Evaluate Vulnerability Risks First" and also our thought experiment above. In addition, 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 has proven itself over the years. 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...and yes, for JS ecosystem it would be even worse due to 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.

Your Feedback Matters

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

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