Technical Report

The Technical Report is Ethiack's technical deliverable — the counterpart to the Executive Report. Where the Executive Report targets management, the Technical Report targets the security and engineering teams responsible for actually fixing the issues.

It contains everything the Executive Report does (the same summary, scope, and context sections) plus the complete, per-finding technical detail: exact URLs, raw HTTP requests and responses, evidence screenshots, CWE classification, CVSS score, and step-by-step reproduction instructions.

It is classified TLP:AMBER and should be treated as sensitive operational intelligence — it contains live exploit payloads and confirmed evidence of working vulnerabilities.

How it differs from the Executive Report

The Technical Report is a strict superset of the Executive Report. Sections 1 and 2 are virtually identical. The critical difference is Section 3, which expands each finding from a one-line summary into a complete vulnerability disclosure entry. It also adds appendices breaking down findings by asset, which are absent from the Executive Report.

Report structure

1. Executive Summary

Identical in purpose and content to the Executive Report. It provides the aggregate finding count, severity breakdown, and vulnerability-by-status charts. The Technical Report adds one extra visual: bar charts of findings per asset by severity and by status, giving developers an immediate sense of which asset carries the most risk before they dive into the findings.

The Business Impact and Methodology subsections are the same — business-language risk narratives and the OWASP-aligned test coverage list.

2. Scope Summary

Same as the Executive Report: in-scope assets, out-of-scope assets, constraints, coverage ratio, and limitations. The Technical Report repeats this because it is a standalone document — security teams reading only the Technical Report need this context to understand the boundaries of what was tested.

3. Findings (asset-by-asset)

This is what makes the Technical Report the primary working document for remediation. Findings are organized by asset, then by finding within each asset. Each finding entry follows a consistent structure:

Finding header — the finding title, a unique hex identifier (e.g., 0x57c9) that links directly to the finding in the Ethiack platform, severity label and CVSS score, current status, affected asset, and CWE classification.

Description — a plain-language explanation of the vulnerability class, how it manifests in this specific application, and why it is dangerous. Descriptions are written to be educational — a developer who has never encountered the vulnerability class before should be able to understand it from this section alone.

Steps to Reproduce — an exact, numbered sequence of steps to trigger the vulnerability. For web vulnerabilities this includes the raw HTTP request (headers and body) that can be copied directly into a tool like Burp Suite or Caido. This is the highest-value section for developers trying to verify a fix.

Evidence — the raw server response that confirms exploitation. This establishes that the finding is confirmed exploitable, not theoretical.

Impact — what an attacker could actually achieve by exploiting this finding in the context of the specific application and customer. More specific than the Executive Report's business impact narrative.

Suggested Mitigations — concrete technical remediation steps. Where a vendor patch exists for a specific CVE, it is cited explicitly.

4. Service Breakdown

A table of network services discovered across in-scope assets. Operationally useful for confirming no unexpected ports or services are exposed.

5. Final Remarks

A synthesizing narrative that draws cross-cutting conclusions across all assets. It calls out patterns — recurring input validation failures, missing authentication, configuration drift — and recommends systemic programme-level interventions rather than just per-finding fixes.

Appendices

Appendix 1 — Asset Vulnerabilities by Severity — a matrix showing each asset against severity tiers with counts and totals, giving an at-a-glance view of which assets carry the most risk.

Appendix 2 — Asset Vulnerabilities by Status — the same matrix by workflow status (Fixed, Open, Triaged, Informative, etc.). This is the table teams use to track remediation progress as they work through fixes.

Appendix B — Out-of-Scope Assets — the full list of excluded assets for traceability and audit purposes.

Value this report delivers

The Technical Report is the primary artifact for the remediation workflow. It enables:

• Developers to reproduce findings themselves before investing in a fix, using the exact HTTP requests provided
• Security engineers to verify fixes by re-running the reproduction steps after a patch is deployed
• Compliance teams to evidence due diligence with a finding-level audit trail including CWE classifications and CVSS scores
• Architects to identify systemic weaknesses — patterns across findings that point to process gaps rather than isolated bugs
• Incident response teams to assess blast radius if a finding is later found to have been exploited — the evidence section documents exactly what data was accessible

The hex-linked finding IDs connect directly to the Ethiack platform, meaning teams can use the report offline and then return to the platform to update finding status, add comments, or mark findings as fixed for re-testing.