AutoGineer
Generated banner for Data Breach Blast Radius
Generated logo for Data Breach Blast Radius

Data Breach Blast Radius

GitHubOfficialFirst committed by sjiyaniDistributed by GitHub

  • Skill
  • Review and audit
  • Security
  • MIT
  • No issues found
Download ZIP

From the author

Pre-breach impact analysis: inventories sensitive data (PII, PHI, PCI-DSS, credentials), traces data flows, scores exposure vectors, and produces a regulatory blast radius report with fine ranges sourced verbatim from GDPR Art. 83, CCPA § 1798.155(a), and HIPAA 45 CFR § 160.404. Cost benchmarks from IBM Cost of a Data Breach Report (annually updated). All citations in references/SOURCES.md for verification. Use when asked: "assess breach impact", "what data could be exposed", "calculate blast radius", "data exposure analysis", "how bad would a breach be", "quantify data risk", "sensitive data inventory", "data flow security audit", "pre-breach assessment", "worst-case breach scenario", "breach readiness", "data risk report", "/data-breach-blast-radius". For any stack handling user data, health records, or financial information. Output labels law-sourced figures (exact) vs heuristic estimates (planning only). Does not replace legal counsel.
— the description by sjiyani

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Data Breach Blast Radius is a specialized security analysis tool designed to help engineering teams understand the potential consequences of a data breach before it happens. By auditing codebases for sensitive data, mapping data flows, and applying regulatory frameworks like GDPR, CCPA, and HIPAA, it provides a quantitative assessment of risk. It bridges the gap between technical vulnerabilities and business impact by estimating potential regulatory fines, breach notification costs, and the overall blast radius of exposed data assets.

What it does

  • Inventories sensitive data assets across code, databases, and configuration files.
  • Traces data flows from ingestion to storage and transmission.
  • Calculates a blast radius score based on data sensitivity and exposure likelihood.
  • Estimates regulatory fine exposure using verbatim legal formulas.
  • Generates a prioritized hardening roadmap to reduce identified risks.
  • Visualizes data flow paths using automated diagrams.

When to use it

  • Before security reviews or penetration testing.
  • When preparing data processing impact assessments (DPIA).
  • During the design of disaster recovery and incident response plans.
  • When onboarding new systems that handle sensitive customer or financial data.
  • To answer leadership questions about system exposure and risk.

Advantages

  • Provides actionable, prioritized hardening steps based on impact-per-effort.
  • Uses verifiable, cited regulatory sources for fine calculations.
  • Quantifies risk in financial terms to facilitate better decision-making.
  • Identifies hidden exposure points like logs, caches, and CI/CD configurations.
  • Standardizes risk assessment across different tech stacks.

Usage examples

“/data-breach-blast-radius”
The agent performs a full audit of the entire project, identifying sensitive data, mapping flows, and generating a comprehensive risk report with financial estimates.
“assess breach impact for the user-service module”
The agent scopes the analysis to the specified module, identifying PII exposure in API contracts and logging, and calculates the potential regulatory blast radius.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/github/data-breach-blast-radius/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip data-breach-blast-radius.zip -d .agents/skills

Documentation by sjiyani

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 phone formats / .eu domains / EU datacenter regions found → GDPR applies

  • If California residents mentioned / US .com / Stripe US / state-specific tax logic → CCPA applies

  • If health record fields (diagnosis, medication, ICD codes, FHIR resources) → HIPAA applies

  • If Brazilian users / BRL currency / CPF fields → LGPD applies

  • If Singapore / Thailand / Malaysia / Philippines data patterns → PDPA applies

  • Apply ALL jurisdictions that match — the most restrictive governs notification timeline

Read references/regulatory-impact.md for fine calculation formulas and notification requirements.

Step 5 — Regulatory Impact Estimation

For each triggered jurisdiction:

  • Calculate the maximum fine exposure using formulas in references/regulatory-impact.md

  • Calculate the minimum fine exposure (realistic for first offense with cooperation)

  • Estimate the breach notification cost (legal, communications, credit monitoring)

  • Estimate the reputational multiplier (public-facing breach vs. internal tool)

Generate a Financial Impact Summary Table:

| Regulation | Max Fine | Realistic Fine | Notification Cost | Timeline |

Note: These are estimates for risk planning purposes only. Always consult legal counsel for actual regulatory guidance.

Step 6 — Blast Radius Report Generation

Read references/report-format.md and generate the full report.

The report MUST include:

  1. Executive Summary (2–3 paragraphs, no jargon)

  2. Sensitive Data Inventory (table: all PII/PHI/financial/credential fields found)

  3. Data Flow Map (Mermaid diagram of data moving through the system)

    • After building the Mermaid markup, call renderMermaidDiagram with the markup and a short title so the diagram renders visually — do not output it as a fenced code block

    • Use style directives: fill:#ff4444 (red) for critical findings, fill:#ff8800 (orange) for high-severity exposure points

  4. Top 5 Exposure Vectors (ranked by blast radius score)

  5. Regulatory Blast Radius Table (per-jurisdiction)

  6. Financial Impact Estimate (realistic range)

  7. Hardening Roadmap (from references/hardening-playbook.md)

Step 7 — Hardening Roadmap

Read references/hardening-playbook.md and generate a prioritized action plan:

For each critical or high-severity exposure vector:

  • What to fix: specific code/config change

  • Why: regulatory risk and user impact

  • Effort: Low / Medium / High

  • Impact: blast radius reduction percentage (estimated)

  • Quick win flag: mark items fixable in < 1 day

Sort by: (Impact × Severity) / Effort — highest value first.

Output Rules

  • Always start with the Executive Summary — leadership reads this first

  • Always include the Sensitive Data Inventory table — this is the foundation

  • Always produce the Financial Impact Estimate — this drives organizational change

  • Always call renderMermaidDiagram for the Data Flow Map — never output raw Mermaid code blocks; the tool renders it as a visual diagram automatically

  • Never auto-apply any code changes — present the hardening roadmap for human review

  • Be specific — cite file paths, field names, and line numbers for every finding

  • State assumptions — if record count is estimated, say so explicitly

  • Be calibrated — distinguish "this is definitely exposed" from "this could be exposed under conditions X"

  • If the codebase has minimal sensitive data and strong controls, say so clearly and explain what was scanned

Severity Tiers for Blast Radius

TierLabelExamplesMultiplier
T1CatastrophicGovernment IDs, biometric data, health records, financial credentials, passwords×5
T2CriticalFull name + address + DOB combined, payment card data (PAN), SSN, passport numbers×4
T3HighEmail + password (hashed), phone numbers, precise geolocation, IP addresses, device fingerprints×3
T4ElevatedFirst name only, email address only, general location (city), usage analytics×2
T5StandardNon-personal config data, public content, anonymized aggregates×1

Reference Files

Load on-demand as needed:

FileUse WhenContent
references/data-classification.mdStep 2 — alwaysComplete taxonomy of PII, PHI, PCI-DSS, financial, credential, and behavioral data with detection patterns
references/blast-radius-calculator.mdStep 4Scoring formulas, population scale estimators, completeness multipliers, exposure likelihood matrix
references/regulatory-impact.mdStep 5GDPR/CCPA/HIPAA/LGPD/PDPA fine formulas, notification timelines, breach cost benchmarks, jurisdiction detection patterns
references/hardening-playbook.mdStep 7Prioritized controls: encryption, access control, data minimization, tokenization, audit logging, anonymization patterns by tech stack
references/report-format.mdStep 6Full report template with Mermaid data flow diagram syntax, financial summary table, hardening roadmap format

Files

references/data-classification.md

Data Classification Taxonomy

A comprehensive taxonomy for identifying sensitive data in codebases. Every field, column, model property, or variable matching these patterns should be inventoried and assigned the appropriate sensitivity tier.

Tier 1 — Catastrophic (Irreversible harm if exposed)

Biometric Data

Detection patterns (field names / column names):

  • fingerprint, thumbprint, retina_scan, iris_scan, face_id, facial_recognition

  • voice_print, voice_biometric, gait_analysis, dna_profile, genetic_data

  • biometric_template, biometric_hash, faceEmbedding, face_vector

Detection patterns (data values / format):

  • Base64-encoded blobs > 512 bytes in biometric-named fields

  • Binary columns in tables named biometric_*, face_*, fingerprint_*

Government-Issued Identifiers

Detection patterns:

  • ssn, social_security_number, social_security, sin (Canada), nino (UK), tfn (Australia)

  • passport_number, passport_no, passport_id

  • drivers_license, drivers_licence, dl_number, license_number

  • national_id, national_identification, id_number, id_card_number

  • tax_id, tin, ein, itin, vat_number, fiscal_code

  • aadhaar, pan_number (India), cpf, cnpj (Brazil), rut (Chile/Colombia)

  • nric, fin (Singapore), my_kad (Malaysia), nik (Indonesia)

Regex patterns for values:

SSN:          \b\d{3}-\d{2}-\d{4}\b
UK NINO:      \b[A-CEGHJ-PR-TW-Z]{2}\d{6}[A-D]\b
CPF (Brazil): \b\d{3}\.\d{3}\.\d{3}-\d{2}\b
Aadhaar:      \b\d{4}\s\d{4}\s\d{4}\b
Health & Medical Data (PHI under HIPAA)

Detection patterns:

  • diagnosis, icd_code, icd10, icd11, snomed, loinc_code

  • medication, prescription, drug_name, dosage, treatment

  • medical_record_number, mrn, patient_id, encounter_id

  • lab_result, test_result, pathology, radiology

  • mental_health, psychiatric, therapy_notes, counseling

  • hiv_status, std_status, substance_abuse, addiction

  • insurance_id, insurance_member_id, health_plan_id, claim_number

  • fhir_resource, hl7_message, dicom_data

  • disability, handicap, chronic_condition

  • pregnancy, reproductive_health, fertility

Authentication Credentials

Detection patterns:

  • password, passwd, pwd, hashed_password, password_hash, password_digest

  • private_key, secret_key, api_key, api_secret, api_token

  • access_token, refresh_token, bearer_token, id_token, jwt_token

  • oauth_token, oauth_secret, oauth_access_token

  • mfa_secret, totp_secret, otp_secret, backup_codes

  • session_token, session_id, auth_token

  • client_secret, client_credential

  • private_key_pem, rsa_private, ecdsa_private

Tier 2 — Critical (High regulatory exposure)

Payment Card Data (PCI-DSS)

Detection patterns:

  • card_number, pan, primary_account_number, credit_card, debit_card

  • cvv, cvc, cvv2, card_verification, security_code

  • card_expiry, expiration_date, exp_date, expiry_month, expiry_year

  • cardholder_name, card_holder

  • iban, bic, swift_code, routing_number, account_number, sort_code

  • bank_account, bank_details, wire_transfer

Regex patterns for values:

Visa:            \b4[0-9]{12}(?:[0-9]{3})?\b
Mastercard:      \b5[1-5][0-9]{14}\b
Amex:            \b3[47][0-9]{13}\b
Generic PAN:     \b[0-9]{13,19}\b (in a PAN-named field)
CVV:             \b[0-9]{3,4}\b (in a cvv-named field)
IBAN:            \b[A-Z]{2}\d{2}[A-Z0-9]{4}\d{7}([A-Z0-9]?){0,16}\b
Identity Combinations (High re-identification risk when combined)

Combinations that together constitute Tier 2:

  • Full name + date of birth

  • Full name + address (street level)

  • Email + date of birth + gender

  • Phone number + address

Detection patterns:

  • full_name, first_name + last_name (as separate fields — note both present)

  • date_of_birth, dob, birth_date, birthdate, birthday

  • home_address, street_address, address_line1, postal_address

  • gender, sex, pronoun (when combined with other identifiers)

Tier 3 — High (Regulatory notification triggers)

Contact Information

Detection patterns:

  • email, email_address, user_email, contact_email, primary_email

  • phone, phone_number, mobile, mobile_number, cell_phone, telephone

  • whatsapp_number, signal_number

Regex patterns:

Email:  \b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b
Phone:  \+?[0-9\s\-\(\)]{7,20}  (in a phone-named field)
Precise Location Data

Detection patterns:

  • latitude, longitude, lat, lng, lat_lng, coordinates, geo_point

  • gps_location, precise_location, real_time_location

  • home_location, work_location

Note: City-level location is Tier 4; street-level or GPS coordinates are Tier 3.

Network Identifiers

Detection patterns:

  • ip_address, ip, client_ip, remote_addr, x_forwarded_for

  • mac_address, device_mac, hardware_id

  • imei, imsi, device_id, advertising_id, idfa, gaid

Authentication Artifacts

Detection patterns:

  • session_id, cookie_value, csrf_token (if long-lived and user-identifying)

  • remember_me_token, persistent_session

Tier 4 — Elevated (Privacy relevant)

Partial Personal Identifiers

Detection patterns:

  • first_name, last_name, display_name, username (when alone)

  • profile_picture, avatar_url

  • city, state, country, region, zip_code, postal_code

  • time_zone, locale, language_preference

Behavioral & Analytics Data

Detection patterns:

  • user_agent, browser, device_type, os

  • search_query, search_history, browsing_history

  • purchase_history, order_history, transaction_history

  • click_event, page_view, session_duration

  • preferences, interests, tags, segments

Financial Context (non-card)

Detection patterns:

  • salary, income, net_worth, credit_score, credit_rating

  • account_balance, wallet_balance, subscription_tier

Tier 5 — Standard (No direct privacy impact)

  • System configuration values (non-secret)

  • Public user-facing content (blog posts, public profiles)

  • Anonymized aggregated statistics

  • Non-personal reference data (product catalog, country codes)

  • Internal system identifiers with no external exposure

Detection Guidance for AI Analysis

Framework-Specific Patterns

Django / Python:

# Sensitive fields typically appear in models.py
class User(models.Model):
    email = models.EmailField()           # Tier 3
    date_of_birth = models.DateField()    # Tier 2 (combined with name)
    ssn = models.CharField(max_length=11) # Tier 1

TypeScript / Prisma:

model User {
  email       String    // Tier 3
  phoneNumber String?   // Tier 3
  dateOfBirth DateTime? // Tier 2 (when combined)
  cardNumber  String?   // Tier 2 PCI-DSS
}

Java / Spring / JPA:

@Entity
public class Patient {
    @Column(name = "diagnosis")  // Tier 1 PHI
    private String diagnosis;
    
    @Column(name = "ssn")        // Tier 1
    private String ssn;
}

C# / EF Core:

public class UserProfile {
    public string Email { get; set; }        // Tier 3
    public string PassportNumber { get; set; } // Tier 1
    public DateTime DateOfBirth { get; set; }  // Tier 2
}
Log Statement Patterns (High Risk — often overlooked)
# BAD — logs PII
logger.info(f"User {user.email} logged in from {request.remote_addr}")
logger.debug(f"Payment for card {card_number}")

# Look for these in logging calls:
# .info(), .debug(), .warn(), .error(), console.log(), System.out.println()
API Response Leakage (Serializer/DTO patterns)
// Check if these fields are included in response objects
// even if not requested — over-fetching is a common exposure vector
{
  "id": "...",
  "email": "...",          // Tier 3
  "phone": "...",          // Tier 3 
  "dateOfBirth": "...",    // Tier 2 — should this be returned?
  "passwordHash": "...",   // Tier 1 — should NEVER be returned
  "ssn": "...",            // Tier 1 — should NEVER be returned
}

Aggregation Risk Assessment

Combination attacks — data that becomes more sensitive when combined:

AloneCombined WithCombined TierRisk
Email (T3)Password hash (T1)T1Account takeover
Name (T4)DOB (T2) + Address (T2)T2Full identity reconstruction
IP address (T3)Timestamps + User IDT2Behavioral profiling
City (T4)Purchase history (T4)T3De-anonymization risk
Health category (T4)Name + EmailT1HIPAA triggering

Rule: Always assess fields in combination, not just in isolation.

Requirements and compatibility

Written for: GitHub Copilot

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

First committed by
GitHub avatar of sjiyanisjiyani
Publisher
GitHub (Official)
Distributed by
GitHub
Source
github/awesome-copilot · skills/data-breach-blast-radius · commit 797337f
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Contributors
sjiyani

AutoGineer is not affiliated with or endorsed by sjiyani or GitHub.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download data-breach-blast-radius.zip