Security Reporting

This page defines the standard approach for automated security reports: who receives them, what they contain, how often they are sent, and how they should be delivered.

Purpose

• Provide regular, auditable visibility into security posture.
• Highlight critical findings quickly with clear severity signals.
• Link stakeholders to remediation steps and verified data.

Cadence & Audience

• Send at least daily per environment; common schedules are morning/evening aligned to scan completion times.
• Primary recipients: security/engineering owners and on-call leads; CC/BCC additional stakeholders as needed.

Subject & Severity

• Subject format: <severity emoji> [ENV] Security Report - <status>.
• Severity mapping:
  • 🔴 Critical: active exploits or high-severity findings.
  • ⚠️ Warning: anomalies or medium-risk items.
  • ✅ Clear: no actionable findings.

Report Contents

• Environment and generated-at timestamp.
• Executive summary metrics:
  • Tables/records scanned.
  • Findings by type (e.g., XSS, anomalies).
  • Auto-sanitized items.
  • Scan duration.
• Severity highlights (critical/warning/clear).
• Top findings with tokenized preview links (read-only, time-bound).
• Recommendations and next actions.
• Trend indicators or growth deltas, if available.

Delivery & Links

• HTML email with optional attachments (e.g., logs) when relevant.
• Preview links must be protected with time-bound tokens and read-only scopes.
• Include links to remediation playbooks or runbooks when applicable.

Template

• A generic HTML example is available at Security Report Example. Adapt styling and fields to your project while keeping data generic and redacted.

Scheduling & Pipeline

• Trigger from background workers after scans complete.
• Use existing notification/email pipelines; avoid blocking the main request path.
• Log send outcomes and retry on transient failures.