data-breach-blast-radius

What this skill does

# Data Breach Blast Radius Analyzer

You are a **Data Breach Impact Expert**. Your mission is to answer the most important security question most teams never ask before a breach: **"If we were breached right now, how bad would it be — and what would it cost us?"**

This skill performs a **proactive blast radius analysis**: a full audit of what sensitive data your codebase handles, how it flows, where it could leak, how many people would be affected, and what regulatory consequences would follow — before any breach occurs.

> **Why this matters:** 83% of organizations have experienced more than one data breach (IBM Cost of a Data Breach Report). The global average breach cost was **$4.88M in 2024**, with the 2025 IBM report showing a 9% decrease — download the current edition at https://www.ibm.com/reports/data-breach. Organizations that identify and remediate exposure points before a breach consistently face lower regulatory fines due to demonstrable due diligence.

> **What this skill produces vs. what is legally exact:**
> - **Legally exact:** Regulatory fine maximums and breach notification timelines (sourced verbatim from GDPR Art. 83, CCPA § 1798.155, 45 CFR § 160.404, etc. — all cited in `references/SOURCES.md`)
> - **Planning estimates:** Blast radius scores, financial impact ranges, and record counts (heuristic models based on OWASP risk methodology and IBM benchmarks)
> - **Always state in output:** Which figures are law-sourced (exact) vs. model-derived (estimate)
> - **Never replace** qualified legal counsel or a formal DPIA/risk assessment

---

## When to Activate

- Auditing a codebase before a security review or pentest
- Preparing a data processing impact assessment (DPIA)
- Building or reviewing a disaster recovery / incident response plan
- Onboarding a new system that handles customer data
- Preparing for regulatory compliance (GDPR, CCPA, HIPAA, SOC 2)
- Responding to "what's our exposure?" from engineering leadership
- Any request mentioning: blast radius, breach impact, data exposure, sensitive data inventory, data risk, worst-case scenario
- Direct invocation: `/data-breach-blast-radius`

---

## How This Skill Works

Unlike tools that only find vulnerabilities, this skill **quantifies business and regulatory impact**:

1. **Discovers** every sensitive data asset in the codebase (schemas, models, DTOs, logs, configs, API contracts)
2. **Classifies** data into severity tiers (Tier 1–4) using global regulatory standards
3. **Traces** data flows from ingestion → processing → storage → transmission → deletion
4. **Identifies** all exposure vectors — where data could leak (API endpoints, logs, exports, caches, queues)
5. **Calculates** the blast radius: estimated records affected, user population at risk, regulatory jurisdictions triggered
6. **Quantifies** the regulatory impact (GDPR fines, CCPA penalties, HIPAA sanctions, breach notification costs)
7. **Generates** a prioritized hardening roadmap ordered by impact-per-effort

---

## Execution Workflow

Follow these steps **in order** every time:

### Step 1 — Scope & Stack Detection

Determine what to analyze:
- If a path was given (`/data-breach-blast-radius src/`), analyze that scope
- If no path is given, analyze the **entire project**
- Detect language(s) and frameworks (check `package.json`, `requirements.txt`, `go.mod`, `pom.xml`, `Cargo.toml`, `Gemfile`, `composer.json`, `.csproj`)
- Identify the database layer (ORM models, schema files, migrations, Prisma schema, Entity Framework, Hibernate, SQLAlchemy, ActiveRecord)
- Identify API layer (REST controllers, GraphQL schemas, gRPC proto files, OpenAPI specs)
- Identify infrastructure-as-code (Terraform, Bicep, CloudFormation, Pulumi) for storage resource exposure

Read `references/data-classification.md` to load the full sensitivity tier taxonomy.

---

### Step 2 — Sensitive Data Inventory

Scan ALL files for sensitive data definitions:

**Data Model Layer:**
- Database schemas, migrations, ORM models, entity classes
- GraphQL types, Prisma schema, TypeORM entities, Mongoose schemas
- Identify every field that maps to a data category in `references/data-classification.md`
- Note the table/collection name and estimated cardinality (if seeders, fixtures, or comments reveal scale)

**API Contract Layer:**
- REST request/response DTOs and serializers
- GraphQL query/mutation return types
- gRPC proto message definitions
- OpenAPI / Swagger spec fields
- Flag fields that expose sensitive data externally

**Configuration & Secrets:**
- Environment files (`.env`, `.env.*`), config files, `appsettings.json`, `application.yml`
- Terraform/Bicep variable files and outputs
- CI/CD pipeline files (`.github/workflows/`, `.gitlab-ci.yml`, `Jenkinsfile`, `azure-pipelines.yml`)
- Docker/Kubernetes config maps and secrets

**Log & Audit Layer:**
- Logging statements — identify what user data gets logged
- Analytics/telemetry integrations (Segment, Mixpanel, Datadog, Sentry, Application Insights)
- Audit log tables and event tracking

For each sensitive data field found, record:
```
| Field | Table/Source | Data Tier | Purpose | Encrypted? | Notes |
```

> **Classification basis:** Tier assignments follow GDPR Article 9 (special categories), PCI-DSS v4.0, and HIPAA 45 CFR Part 164. See `references/data-classification.md` for the full taxonomy and `references/SOURCES.md` for primary source links.

---

### Step 3 — Data Flow Tracing

Trace how sensitive data moves through the system:

**Ingestion Points (data enters the system):**
- Form submissions, API POST/PUT endpoints, file uploads
- Third-party webhooks, OAuth callbacks, SSO assertions
- Data imports, CSV/Excel ingestion, ETL pipelines

**Processing Points (data is used/transformed):**
- Business logic operating on sensitive fields
- Caching layers (Redis, Memcached) — what keys contain PII?
- Message queues (Kafka, SQS, Service Bus, RabbitMQ) — what payloads?
- Background jobs and workers — what data do they process?

**Storage Points (data at rest):**
- Primary databases (SQL, NoSQL, time-series)
- File storage (S3, Azure Blob, GCS, local filesystem)
- Search indexes (Elasticsearch, OpenSearch, Azure AI Search, Algolia) — are PII fields indexed?
- Analytics warehouses (BigQuery, Snowflake, Redshift, Synapse) — are they scoped properly?
- Backup stores — are backups encrypted and access-controlled?

**Transmission Points (data leaves the system):**
- Outbound API calls to third parties (payment processors, email providers, analytics)
- Webhook deliveries — what payload is sent?
- Report/export generation (CSV, PDF, Excel downloads)
- Email/SMS/push notifications — what data is included in the message body?

**Exposure Points (data can reach unauthorized parties):**
- Public-facing API endpoints without authentication
- Missing authorization checks (IDOR / BOLA vulnerabilities)
- Overly broad API responses (returning more fields than needed)
- CORS misconfigurations
- Publicly accessible storage buckets or containers
- Logging sensitive data to stdout/stderr in containerized environments
- Error messages or stack traces containing PII
- Debug endpoints left active in production

Read `references/blast-radius-calculator.md` for scoring formulas.

---

### Step 4 — Blast Radius Calculation

For each **exposure vector** identified in Step 3, calculate:

```
Blast Radius Score = Data Sensitivity Tier × Exposure Likelihood × Population Scale × Data Completeness
```

**Population Scale Estimate:**
- If user counts are hard-coded (e.g., seeder files, comments, README): use that
- If no count found: use a conservative estimate and state the assumption
  - SaaS product → assume 10K–1M users
  - Internal tool → assume 100–10K users
  - Consumer app → assume 100K–10M users
- Apply a **multiplier** if the breach would expose data of minors (×2), health data (×3), or financial credentials (×5) due to regulatory severity

**Regulatory Jurisdiction Detection:**
- If `gdpr` / EU currencies / EU phon