From Lab Measurement to Scan Module: The DDactic R&D Pipeline

New scan capabilities in DDactic are not built from vendor documentation. They are built from measurements made against real infrastructure, using DDactic's own systems as the first target. The process goes from observation (something interesting is happening in this protocol) through controlled lab measurement (what exactly is the behavior, and under what conditions?) to production scan logic (a reliable probe that can be executed against any customer environment and interpreted consistently).

This pipeline matters because it constrains what DDactic claims to find. Every check in the scan engine has a corresponding lab measurement proving that the behavior it probes actually affects resilience in a detectable, reproducible way. Checks without measurement foundations are removed from the engine. This is why the DDactic checklist is shorter than generic security checklists -- it contains only what has been proven to matter.

Stage 1: Observation

Observations come from three sources: reviewing vendor security advisories and CVE disclosures for new vulnerability classes, analyzing traffic patterns captured during active research on DDactic's own lab infrastructure (Hetzner VM at 138.199.223.24 used as the instrumented victim), and reviewing findings from the assessment population to identify patterns that appear repeatedly across customers. When a pattern is seen in three or more unrelated organizations, it graduates from anecdote to research candidate.

The gRPC WAF gap -- the observation that most WAFs do not inspect gRPC HTTP/2 traffic and apply rate limits only to HTTP/1.1 paths -- originated from repeated assessment findings showing unprotected port 50051 exposure. It was observed before it was measured.

Stage 2: Controlled Lab Measurement

Lab measurement runs the candidate behavior against DDactic's own instrumented infrastructure. The measurement protocol specifies: what is the baseline behavior, what input produces the observed behavior, at what threshold does the behavior affect service availability, how reproducible is the effect across different server configurations, and what configurations mitigate the effect. This produces concrete numbers: "gRPC flooding at 10,000 requests per second causes P99 latency to exceed 5 seconds within 45 seconds on a 4-core server running grpc-go 1.62 without connection limits configured."

Stage 3: Generalization and Scope Definition

A lab measurement on one server configuration must generalize before it becomes a scan module. The generalization stage tests whether the behavior appears across different infrastructure configurations: different server software versions, different cloud providers, different WAF configurations. If the behavior is highly configuration-specific (for example, only affects a specific version of a library), it becomes an advisory rather than a scan module -- it is reported when that specific version is detected, not as a general check. If the behavior appears broadly (most grpc-go servers without explicit connection limits show the same saturation pattern), it becomes a general scan module.

Stage 4: Probe Implementation

The scan probe is the specific sequence of requests or measurements that reliably detects the vulnerability in production environments. It must be safe to run against customer systems without causing service degradation (DDactic probes are calibrated to stay well below saturation thresholds during detection), interpretable (the probe output unambiguously indicates vulnerable vs. not-vulnerable), and fast (DDactic's full six-stage pipeline completes in under an hour for most environments). The probe is reviewed against test cases before deployment: known-vulnerable and known-protected environments should produce correct classifications.