What a DDactic Hardening Audit Produces

A DDactic hardening audit produces four deliverables: an OPI score, a finding list with remediation commands, a hardening roadmap, and a verification procedure for each fix. This post describes each deliverable in detail so security teams know what to expect and how to use it.

Deliverable 1: OPI Score and Sub-Scores

The OPI (Open Protection Index) is a 0-100 score representing overall DDoS resilience. It is computed from five sub-scores: edge protection (CDN and WAF configuration), API layer (rate limits, depth limits, gRPC coverage), TLS and connection (timeout settings, renegotiation, reconnect rates), authentication hardening (auth endpoint protection, MFA coverage), and breach exposure (credential exposure risk from public breach databases). The score is delivered immediately after scan completion and is machine-readable via the DDactic API for integration with security dashboards and GRC tools.

Deliverable 2: Finding List with Remediation Commands

Every finding in the DDactic output includes: the finding type (from a taxonomy of 47 DDoS-relevant finding categories), the affected endpoint or service, the evidence collected during the scan (HTTP response headers, rate limit test results, TLS fingerprints), the expected configuration, the observed configuration, the OPI impact score (how much the OPI score would increase if this finding were remediated), and a remediation block with vendor-specific configuration commands.

The remediation block is not generic advice. It contains the exact command for the detected vendor stack. If the edge is Cloudflare, the block contains a Cloudflare Ruleset Engine expression. If the origin is Nginx, it contains the limit_req_zone directive. The intent is that an engineer can copy the command, adjust the path expression to match their specific endpoints, and deploy it without further research.

Deliverable 3: Hardening Roadmap

The roadmap groups findings by effort tier: quick wins (under 2 engineering hours, addresses a single misconfiguration or missing rule), sprint items (2-40 hours, requires creating multiple rules or modifying architecture-adjacent settings), and strategic items (over 40 hours or requiring cross-team coordination, such as moving gRPC services behind a proxy or implementing mutual TLS for service-to-service communication). The roadmap is designed to be usable as sprint planning input without reorganization.

Deliverable 4: Verification Procedures

For each finding, the audit output includes a verification procedure: the specific test to run after remediation to confirm the fix is working. For a rate limit finding, the verification procedure is the curl command sequence to send at increasing rates and the expected 429 response at the threshold. For an introspection finding, it is the introspection query to send and the expected error response. Verification procedures allow engineering teams to confirm their fix worked without waiting for the next full DDactic scan.

Delivery Format and Integration

DDactic delivers the audit output as a PDF for CISO and compliance purposes, as a structured JSON export for integration with ticketing systems and dashboards, and via the DDactic web portal with interactive filtering and tracking of remediation status. The JSON export schema is stable and documented for integration with Jira, ServiceNow, or custom internal tools.