Introducing .NET Support in Socket

We’re excited to announce Socket’s public beta support for .NET, bringing our security insights and supply chain protection to the millions of developers building with C# and the .NET ecosystem.

Whether you’re building Windows desktop applications, web APIs, automation scripts in PowerShell, or even games with Unity, .NET is a powerful and versatile framework — and it’s everywhere. In fact, C# ranks among the top 10 most popular languages in Stack Overflow’s 2024 Developer Survey, and .NET is widely used across industries from finance to game development.

What many developers may not realize is that .NET and many of its associated tools are now fully open source on GitHub, and the modern .NET runtime runs cross-platform on Windows, macOS, and Linux, making it a compelling alternative to more traditional language ecosystems.

At the center of the .NET developer experience is NuGet, the official package manager for .NET projects. First introduced in 2010, NuGet today hosts nearly 450,000 packages covering everything from JSON parsing and web servers to robotics and 3D printing.

Modern supply chain security for enterprise .NET teams#

Many large enterprises rely on .NET and are investing heavily in secure software supply chain practices. While many .NET security tools focus on static analysis or runtime vulnerabilities, Socket fills a critical gap by proactively detecting package-level threats, including dependency confusion, typosquatting, and malicious updates, directly in your NuGet dependencies.

With Socket, .NET developers get:

• Deep package inspection for suspicious behavior, even before install.
• Automatic detection of risky updates or new transitive dependencies.
• Improved SBOM accuracy with lock file awareness and build context.
• Real-time monitoring for emerging threats in your supply chain.

Socket integrates seamlessly with your workflow to help secure your .NET applications from the ground up, without slowing you down.

Why .NET dependency resolution is tricky#

While it’s convenient to have a single build system that handles both compiling your project and installing dependencies, it also introduces complexity. In MSBuild, dependency resolution isn’t just a single step—it can happen during both the evaluation and execution phases of a build.

A few ways dependencies can be introduced:

• Dependencies vary based on target frameworks
• *.props files (imported during evaluation) and *.targets files (imported during execution) can each introduce dependencies
• Project files (.csproj, .vbproj, etc.) can:
  • Import each other—sometimes cyclically!
  • Define or override properties that affect which dependencies get restored
• Projects can import other projects, which are built independently and may have different target frameworks applied at import time

All of this means that your full dependency graph may only be known after the entire MSBuild process is evaluated.

Why lock files matter for .NET developers#

Dependency management in .NET has come a long way. While NuGet was once bolted onto projects using external config files, it’s now deeply integrated into MSBuild. Simply running dotnet build will automatically install your declared dependencies — no extra tooling required.

But this convenience can also hide complexity. Because MSBuild and NuGet rely on conditionals, environment variables, and dynamically evaluated properties, determining exactly what packages are used in a build (and generating accurate SBOMs) can be tricky.

That’s where lock files come in.

.NET introduced lock file support back in 2018, and they remain the best way to ensure consistent, reproducible builds across teams and CI environments. Lock files:

• Help make builds deterministic across machines and environments
• Improve Software Bill of Materials (SBOM) accuracy
• Reduce the risk of hidden or unexpected dependencies

To enable lock files, just add the following to a PropertyGroup in your project file:

<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>

Or, if you're using Central Package Management, add it to your Directory.Packages.props.

Calling all .NET developers#

We’re thrilled to bring Socket’s protection to the .NET ecosystem — and we’re just getting started. We’d love to hear from .NET developers: Do you find yourself editing *.csproj, *.props, or *.targets XML files by hand? Or does your tooling handle everything for you? Let us know! Your feedback helps shape how we support .NET going forward.

Install the free Socket app and start securing your .NET dependencies today — and if you’re curious how Socket can help your team, book a demo with us.