From AWS Security Hub to Client-Ready HTML: A Private AI Reporting Pipeline
The article explains a two‑stage pipeline for generating client‑ready security reports from AWS Security Hub data. A Lambda function first ranks findings deterministically and uses Amazon Bedrock to add concise narratives. A second, isolated EC2 host then transforms the markdown into polished, offl…
When an organization owns or operates AWS accounts, Security Hub aggregates findings from GuardDuty, Inspector, and other services into the AWS Security Finding Format (ASFF). Although this consolidated view is valuable for internal triage, it is not a ready‑to‑share client report. The article presents a repeatable, auditable workflow that turns raw findings into a clean, offline HTML document while keeping all AI inference inside the AWS account.
Why the Two‑Stage Approach Matters
The first stage runs in Lambda and produces a markdown snapshot that preserves every piece of evidence from Security Hub. This artifact is useful for auditors and engineers who need to trace back to the original finding. However, it is cluttered with long ARNs, internal IDs, and duplicated technical details that executives find hard to digest. The second stage, executed on a tightly controlled ARM64 EC2 instance, post‑processes the markdown into a visually‑structured HTML report. This report highlights executive metrics, severity filters, top affected resources, and a shortlist of remediation candidates, making it suitable for client hand‑offs.
Setting Up the Reporting Boundary
All components run in the Singapore region (ap‑southeast‑1) to avoid cross‑region data movement. Security Hub, GuardDuty, and Inspector must be enabled in the same account and region, and the Security Hub CSPM integration should be activated for the aggregation region. A dedicated S3 bucket, such as example-security-reporting-ap-southeast-1, stores raw findings, the markdown snapshot, the evidence‑HTML, and the final client‑ready HTML. Bucket policies enforce block public access, server‑side encryption with a KMS key, and versioning. Separate prefixes keep source artifacts isolated from the final report.
Lambda: Deterministic Ranking and Bedrock Narratives
The Lambda function runs on a weekly EventBridge schedule. It pulls findings via SecurityHub.GetFindings, removes duplicates using a stable provider ID plus resource context, and calculates a priority score based on severity, asset criticality, and exposure modifiers. The top six findings become remediation candidates for the next week. A previous‑week manifest stored in S3 lets the Lambda classify each finding as new, persistent, resolved, changed, or not observed, ensuring that the report does not falsely claim a finding is fixed.
After ranking, the Lambda sends a compact, redacted payload to Amazon Bedrock’s Claude Sonnet 4.6. The model generates a JSON response containing an executive summary, a rationale for each remediation candidate, and data‑quality notes. The Lambda validates the JSON, falls back to a deterministic summary if Bedrock fails, and writes the markdown and evidence‑HTML to S3.
Local EC2 Post‑Processing
The EC2 instance runs a hardened ARM64 Kali Linux image (or an Ubuntu ARM64 image if Kali is not required). It has an instance profile that grants read access to the markdown snapshot and write access only to the final client‑ready HTML prefix. The instance runs a lightweight, quantised model (e.g., Qwen2.5‑7B‑Instruct‑Q4_K_M) compiled locally with llama‑cpp‑python, eliminating the need for x86 binaries. After downloading the model, the instance disables outbound internet access to keep inference inside the AWS boundary.
The local transformer package reads the markdown, applies the model’s narrative, and outputs a polished HTML file with executive dashboards, sortable tables, and downloadable CSVs. The final artifact is stored in S3 and can be delivered to the client via a secure, time‑limited pre‑signed URL.
Security Controls and Trust Boundaries
Two key controls keep the pipeline secure. First, deterministic logic in Lambda decides which findings are high priority; the Bedrock model can only provide explanation, not decision. Second, the local EC2 host receives only redacted data and has no permissions to query Security Hub, GuardDuty, or Inspector, preventing accidental data leakage. The instance’s IAM role is narrowly scoped, and network egress is disabled after the model download. Typical AWS workload risks—IAM misuse, instance compromise, or log leakage—remain the only residual concerns.
What Happens Next?
Once the pipeline is in place, the organization can run weekly reports that are both audit‑ready and client‑friendly. The deterministic ranking ensures reproducibility, while the local post‑processing stage guarantees that sensitive data never leaves the AWS account. Future enhancements could include automated remediation via Systems Manager or integration with a ticketing system, but the core architecture remains the same: a clear separation between evidence preservation and client presentation.
Why it matters
By keeping AI inference inside the AWS boundary and separating evidence from executive summaries, the pipeline balances transparency, auditability, and client‑readiness without compromising security.
Key points
- 1. Lambda ranks findings deterministically and uses Bedrock for concise narratives.
- 2. A second, isolated EC2 host transforms markdown into polished offline HTML.
- 3. All data stays within the AWS account; no external AI services are used.
- 4. The pipeline preserves audit trails while delivering executive‑ready reports.
Frequently asked questions
Do I need to use Bedrock for the narrative part?
No, the Lambda can fall back to a deterministic summary if Bedrock is unavailable. Bedrock is only used for bounded narrative assistance.
Can I run the EC2 host in a different region?
It is best to keep the EC2 host in the same region as the source data to avoid cross‑region data movement and simplify compliance.
