SAST · C# / .NET

Static application security testing for C# and .NET

Offensive360 SAST follows untrusted data through ASP.NET Core controllers, Razor and Blazor views, Entity Framework and ADO.NET, and reports the exact flow with a secure fix. It runs in Visual Studio, in your pipeline and on-premise, so source code never leaves your network.

Scan a .NET repository in a demo Free for open-source .NET projects

Last updated: 8 September 2026

What it finds in .NET code

Findings map to OWASP Top 10, CWE and SANS Top 25. Each one carries the source-to-sink trace across files and a fix in idiomatic C#.

SQL injection through EF Core and ADO.NET

Tracks request input into FromSqlRaw, ExecuteSqlRaw, SqlCommand.CommandText and Dapper query strings; parameterized calls are recognized as safe, so you are not flooded with noise.

Cross-site scripting in Razor, MVC and Blazor

Html.Raw, MarkupString, unencoded JavaScript blocks and JSON written into views; encoded output through the Razor pipeline is understood and not reported.

Insecure deserialization

BinaryFormatter, NetDataContractSerializer, SoapFormatter, LosFormatter and JSON.NET TypeNameHandling.All on untrusted input.

XML external entities and XPath injection

XmlDocument and XmlTextReader with resolvers enabled, XmlReaderSettings that allow DTD processing, and user input inside XPath expressions.

Path traversal and file handling

Path.Combine and File.* calls fed by route or form values, unrestricted uploads and content-type trust.

Hardcoded secrets and connection strings

Credentials, API keys and connection strings in appsettings.json, web.config, launchSettings.json and source, with a fix that moves them to user secrets or a vault.

Broken authentication and authorization

Missing [Authorize], AllowAnonymous on sensitive actions, insecure cookie options, missing anti-forgery validation on state-changing POSTs and weak Identity password options.

Weak cryptography and randomness

MD5, SHA1, DES, RC2, ECB mode, static IVs, System.Random for tokens and TLS certificate validation callbacks that return true.

Mass assignment and open redirects

Over-posting into entity models bound directly from requests, and Redirect() with unvalidated returnUrl parameters.

A finding, as the developer sees it

SQL injection (CWE-89), high severity. Source: the q query parameter. Sink: an interpolated string passed to FromSqlRaw. The suggested fix keeps the query in LINQ so Entity Framework parameterizes it.

Vulnerable

[HttpGet("search")]
public IActionResult Search(string q)
{
    var rows = _db.Products
        .FromSqlRaw($"SELECT * FROM Products WHERE Name LIKE '%{q}%'")
        .ToList();
    return View(rows);
}

Secure fix

[HttpGet("search")]
public IActionResult Search(string q)
{
    var rows = _db.Products
        .Where(p => EF.Functions.Like(p.Name, $"%{q}%"))
        .ToList();
    return View(rows);
}

Where it runs

Visual Studio and VS Code

Findings appear inline as you code with the taint path and the secure fix. Works with .NET Framework 4.x and .NET 6 to .NET 10 solutions.

Azure DevOps, GitHub Actions, GitLab CI

Scan on pull request, fail the build on new high findings and publish SARIF to the GitHub code scanning tab.

NuGet dependency analysis

The same scan lists vulnerable NuGet packages and license risks, so a .NET project gets SAST and SCA from a single run.

On-premise or air-gapped

Deploy as an OVA appliance, an Azure image inside your own subscription, or fully offline. Source never leaves your network.

Questions from .NET teams

Which .NET versions and project types are supported?

C# and VB.NET on .NET Framework 4.x, .NET Core and .NET 6 through .NET 10: ASP.NET Core MVC, Razor Pages, Web API, minimal APIs, Blazor Server and WebAssembly, Windows services, Azure Functions, console tools and class libraries. Solutions with mixed C# and JavaScript/TypeScript front ends are scanned as one project.

Does it need a build to analyze the code?

No. Offensive360 SAST parses the source directly, so you can scan a repository without restoring packages or compiling. That also means scans work in CI without the full toolchain and on air-gapped machines.

How is this different from Roslyn security analyzers?

Roslyn analyzers check a single method or file for known patterns. Offensive360 follows data across controllers, services, repositories and views (interprocedural taint analysis), understands sanitizers and framework encoders, and ships a fix for each finding. See our guide to Roslyn security analyzer rules for a side-by-side view.

What about code written by AI assistants?

Generated C# tends to use raw SQL strings, disable certificate validation and hardcode credentials. The scan runs in the IDE and on every pull request, so those patterns are caught before merge. An MCP server lets AI coding assistants query findings and apply fixes.

Can I try it on our own solution?

Yes. A scoped demo scans a repository you choose, on-premise or in our cloud, and walks through the findings with your team. Public open-source .NET projects can request a free scan token.

Guides for .NET security

See the findings on your own solution

A 30-minute scoped demo: we scan a C# repository you choose and review the traces and fixes together.

Book a demo SAST for Java All 60+ languages