Anatomy of a Systematic Security Finding

A finding that says "rate limit is missing on the search endpoint" is not a finding -- it is an observation. A finding specifies what is missing, why it matters in measurable terms, what an attacker would do with it, and what the specific remediation action is. The difference between an observation and a finding is the work between them: the measurement of impact, the attacker's perspective, and the concrete remediation step.

DDactic structures every finding to answer the question the engineer picking up the ticket will ask: "What exactly do I need to change, and what happens if I don't?" This structure is not about presentation aesthetics -- it is about whether the finding gets acted on. Findings without concrete remediation steps are filed and forgotten. Findings with a specific WAF rule to add are implemented in the next sprint.

Component 1: Asset Identification

The finding begins with the exact asset affected: the full URL path, the HTTP method, and the host. Not "the search API" but POST https://api.example.com/v2/search. This specificity matters because a development team may have multiple search endpoints, some protected and some not. The finding must be unambiguous about which endpoint is affected so that the engineer implementing the fix does not accidentally address the wrong one.

Component 2: Measured Condition

The condition is what was observed, expressed as a measurement: "The endpoint returns HTTP 200 at 500 requests per second with P99 response time under 200ms. No rate limit header is present in responses at any tested request rate. Response time begins degrading above 80 requests per second." This is not a configuration assertion ("rate limiting is not configured") -- it is a measurement with specific numbers. The measurement is reproducible: an engineer who wants to verify the finding can send requests to the endpoint and observe the same behavior.

Component 3: Impact

The impact section translates the measured condition into a business consequence: "A sustained request rate of 100 rps to this endpoint would saturate the backend database connection pool within 60 seconds, causing all endpoint requests (including legitimate ones) to time out and return 503. Recovery requires the request rate to drop below 80 rps for at least 30 seconds. During an attack, this endpoint can be taken offline with a bandwidth cost to the attacker of under 1 Mbps." Numbers. Not "significant degradation" or "serious risk" -- specific thresholds and consequences.

Component 4: Attack Path

The attack path section describes the simplest feasible attack that exploits the finding: "Using a single server with a 100 Mbps network connection, an attacker can flood this endpoint at sufficient rate to saturate the backend. No authentication is required. The attack can be conducted from a single IP address, requiring no botnet infrastructure." This section gives the CISO a threat model to evaluate the finding against their risk tolerance. A finding that requires nation-state resources to exploit has a different priority than one that requires a single cloud VM.

Component 5: Remediation

The remediation section contains the specific configuration change, in the organization's WAF vendor's syntax, that closes the gap. Not "add a rate limit" but the exact rule definition, with parameters derived from the measured saturation threshold. For a Cloudflare customer: the WAF Custom Rules expression, the rate limit action configuration, and the recommended threshold. The remediation also includes the verification step: how to confirm the rule is working after it is applied.