Novee Meets You Where You Are: Fixes Written for the Stack You Already Run

Most security tools hand you the same generic advice no matter what you’re running; some version of “deploy a WAF” or “add rate limiting,” and then leave the translation to you. Knowing you need a WAF rule and having the exact rule for your platform are two different problems, and the second one is where teams lose days.

Novee writes the mitigation for the infrastructure you actually run: Cloudflare at the edge gets a Cloudflare rule expression, an AWS setup gets an AWS WAFv2 rule written against it, and that same logic holds down to the nginx directive.

We went through every finding on the platform to see how often that’s true. The numbers are below.

Proven first, then mitigated

Every number in this post describes findings that Novee has already validated. Nothing here is a scanner signature or a theoretical weakness carried forward from a template. A finding earns a mitigation only after Novee’s agents have established that it is reachable and exploitable in the customer’s environment.

What follows measures the shape of the fix, not the severity of the finding. A validated access-control flaw and a missing transport header can both close with a configuration change; that says something about where the fix lands in the stack, not about how serious the underlying issue is.

A deployable mitigation for most findings

We analyzed 4,348 findings across our customer environments. Of those, 2,474 (57%) ship with at least one deployable mitigation — a fix a team can push at the edge or in configuration without waiting on an engineering sprint. 704 findings, 16% of the total, recommend a WAF rule specifically.

The impact: more than half of everything Novee proves arrives with a fix your team can deploy now. That turns a validated finding into a stack-specific mitigation, instead of a report you have to translate yourself.

This is what closing the loop looks like in practice.

Written for your stack

Across these findings, the guidance spans more than a dozen distinct vendors: 

Cloudflare, AWS WAF, CloudFront, Azure Front Door and Application Gateway, Akamai, ModSecurity and others at the edge. 

AWS API Gateway and Kong at the API layer.

nginx, Apache and Istio/Envoy at the proxy and mesh layer.

The guidance follows whatever the customer runs, not a house preference.

Novee writes the actual rule

“Meets you where you are” is literal output. For hundreds of findings, Novee doesn’t stop at telling you to add a WAF rule; it writes the rule for that platform. Here’s an example from a rate-limiting finding, with the customer’s endpoint redacted:

RateBasedStatement:
    Limit: 100  # requests per 5 minutes
    AggregateKeyType: IP
    ScopeDownStatement:
      ByteMatchStatement:
        SearchString: "/api/v1/<endpoint>"
        FieldToMatch:
          UriPath: {}

The same holds across nginx directives, Apache mod_headers config, ModSecurity SecRules, Cloudflare rule expressions and Terraform aws_wafv2 resources — concrete, vendor-specific syntax, written for the platform the finding lives on.

Generated rule syntax is produced by Novee’s agents and is meant to be reviewed against your own traffic patterns before it goes live. A rate limit or a blocking rule is a production change, and it should be treated as one.

What counts as a deployable mitigation

We classified findings by reading the actual recommendation text and sorting it into seven categories, working from what the fix says rather than from a stored label. Counts are per finding and they overlap, since a single finding often carries several of these.

Detective controls like logging and alerting sit outside this count, along with code-level remediations. Those are real fixes — often the right permanent one — they just aren’t the deploy-it-now kind this analysis is measuring.

Coverage tracks the vulnerability

How often a finding comes with a deployable mitigation, and how often that mitigation is a WAF rule, moves the way you’d expect with the class of finding.

• Injection and access-control classes are different: roughly half carry an edge-level mitigation, and where they do, it is far more likely to be a WAF rule — 47% for SQL injection, 61% for brute-force exposure.
• Configuration and header-class findings almost always come with a deployable fix.

Those edge mitigations are deliberately framed as containment, not closure. A WAF rule in front of a SQL injection buys time and shrinks the exposure window; the parameterized query is still the fix. Novee marks the distinction rather than blurring it, so the team pushing the rule knows what remains open.

Examples: Five findings, five fixes

Below are five real examples of fix recommendations from across our customer environments.

1. SQL injection, contained with a WAF virtual patch while the query is fixed. “Update WAF rules to detect SQL keywords split by inline comments (o/**/r, un/**/ion) as evasion attempts.”
2. SSRF, contained with a WAF rule. “Deploy a WAF rule to block requests containing @ symbols in the hostname parameter.”
3. Missing brute-force protection, met with a rate limit and CAPTCHA. “CAPTCHA after repeated failed attempts and IP-based rate limiting at the web-server level.”
4. Clickjacking, met with a security header. “Set Content-Security-Policy: frame-ancestors ‘self’ at the reverse-proxy level.”
5. Missing HSTS, met with a transport header. “Add Strict-Transport-Security: max-age=31536000; includeSubDomains, and submit the domain to the HSTS preload list.”

See it on your stack

Everything above is aggregated across our customer base. The value is clearest once it’s your infrastructure in the picture.

Novee runs against your systems, proves what’s actually exploitable, and hands back the exact mitigations written for the infrastructure you already run. Book a demo and watch Novee agents generate the right fixes for your systems.

Methodology

Population. All 4,348 findings on the platform as of August 2026, excluding deleted records. Aggregated and anonymized.

How the percentages work. Summary and mitigation-type figures are percentages of the full 4,348-finding population; vulnerability-class figures are percentages of findings within that class. Every class shown carries at least 50 findings. Mitigation categories overlap, since one finding often carries several.

Classification. We classified each finding by reading its actual recommendation text, matching against patterns for each category. The 57% figure is the union of the seven preventive categories above; detective controls and code-level remediations are excluded. The 16% WAF figure counts a WAF rule named anywhere in the fix guidance.

Validation. Because classification is pattern-based, we hand-reviewed 77 findings to check the classifier against what each recommendation actually said. Precision was roughly 90% overall and close to 100% for WAF-rule classification.