I've been conducting an evaluation of several SAST tools for a portfolio of legacy applications we are required to maintain, and my structured testing has revealed a significant, almost fundamental, incompatibility with OpenClaw's default ruleset when applied to ASP.NET Web Forms codebases. The volume of false positives generated renders the initial report nearly useless for security auditing purposes, necessitating extensive rule tuning that negates the "out-of-the-box" value proposition.
The core issue stems from OpenClaw's default patterns being heavily optimized for modern MVC, Web API, and Razor Pages architectures. When run against a Web Forms `*.aspx.cs` code-behind file, the engine misinterprets the inherent pattern. Key false-positive categories observed include:
* **Page Lifecycle Events as Entry Points:** Methods like `Page_Load` are flagged with high-confidence warnings for unsanitized input, when in fact the `Request.Form` or `Request.QueryString` collections accessed within are the standard, intended pattern for the framework. The tool does not appear to have built-in awareness of the Web Forms event model.
* **ViewState Assumptions:** OpenClaw frequently alerts on potential tampering with control values without considering the role of ViewState and the framework's built-in event validation, leading to a high number of "Insecure Direct Object Reference" flags that are not applicable.
* **Legacy .NET 1.x/2.x Patterns:** The default ruleset contains several rules targeting practices common in early .NET (e.g., certain uses of `DataSet`) that, while technically present, are often used in a non-vulnerable context within these legacy applications. The signal-to-noise ratio is poor.
This necessitates a pre-analysis configuration phase for any Web Forms project, which undermines efficiency. The required adjustments are not trivial; they involve:
* Creating a technology profile to suppress entire rule categories (e.g., "ASP.NET Web Forms") that are irrelevant.
* Manually annotating or marking as "False Positive" hundreds of instances per mid-sized application to train the engine.
* Developing custom rules to recognize safe `HttpServerUtility.HtmlEncode` wrappers around control output, which the default rules often miss.
From a comparative standpoint, tools like GuardRails and CodeSec, while having their own limitations, offered more contextual understanding for these legacy frameworks in my side-by-side testing. Their default rulesets appeared to have been calibrated with a broader historical framework coverage in mind.
My conclusion is that OpenClaw, in its current default configuration, is not a viable candidate for teams managing legacy ASP.NET Web Forms estates without a significant upfront investment in rule customization and baseline establishment. For teams working exclusively with modern .NET Core/5+, this may not be an issue, but for those in hybrid or legacy environments, this is a critical evaluation point. I am interested if others in the community have performed similar benchmarks and what your workflow was for establishing a usable baseline with OpenClaw or alternative tools in such contexts.