Data Breach Blast Radius

GitHubOfficialFirst committed by sjiyaniDistributed by GitHub

Skill
Review and audit
Security
MIT
No issues found

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

Download the skill as a ZIP:
https://autogineer.com/agent-skills/github/data-breach-blast-radius/download

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:

Discovers every sensitive data asset in the codebase (schemas, models, DTOs, logs, configs, API contracts)
Classifies data into severity tiers (Tier 1–4) using global regulatory standards
Traces data flows from ingestion → processing → storage → transmission → deletion
Identifies all exposure vectors — where data could leak (API endpoints, logs, exports, caches, queues)
Calculates the blast radius: estimated records affected, user population at risk, regulatory jurisdictions triggered
Quantifies the regulatory impact (GDPR fines, CCPA penalties, HIPAA sanctions, breach notification costs)
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:

Executive Summary (2–3 paragraphs, no jargon)
Sensitive Data Inventory (table: all PII/PHI/financial/credential fields found)
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
Top 5 Exposure Vectors (ranked by blast radius score)
Regulatory Blast Radius Table (per-jurisdiction)
Financial Impact Estimate (realistic range)
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

Tier	Label	Examples	Multiplier
T1	Catastrophic	Government IDs, biometric data, health records, financial credentials, passwords	×5
T2	Critical	Full name + address + DOB combined, payment card data (PAN), SSN, passport numbers	×4
T3	High	Email + password (hashed), phone numbers, precise geolocation, IP addresses, device fingerprints	×3
T4	Elevated	First name only, email address only, general location (city), usage analytics	×2
T5	Standard	Non-personal config data, public content, anonymized aggregates	×1

Reference Files

Load on-demand as needed:

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

Files

ATTRIBUTION.mdAdded by AutoGineer879 B
LICENSELicence file added by AutoGineer1.0 KiB
SKILL.md14.0 KiB
references/SOURCES.md11.7 KiB
references/blast-radius-calculator.md10.3 KiB
references/data-classification.md8.7 KiB
references/hardening-playbook.md14.0 KiB
references/regulatory-impact.md14.8 KiB
references/report-format.md10.4 KiB

references/hardening-playbook.md

Hardening Playbook

Prioritized controls to reduce data breach blast radius. Controls are organized by impact category and include tech-stack-specific implementation patterns. Each control includes a blast radius reduction estimate.

How to use: After identifying exposure vectors, match each to a control below. Sort your hardening roadmap by (Blast_Radius_Reduction × Severity) / Effort.

Control Priority Matrix

Priority	Control	Blast Radius Reduction	Effort	Category
P0	Fix IDOR/BOLA — add ownership checks	90% for affected vector	Low	Authorization
P0	Remove sensitive fields from API responses	85% for affected fields	Low	Data Minimization
P0	Revoke publicly accessible storage (S3/Blob)	100% for affected store	Low	Access Control
P0	Remove plaintext credentials from code/logs	100% for affected secret	Low	Secrets
P1	Add field-level encryption for T1 data	80% for encrypted fields	Medium	Encryption
P1	Mask/tokenize PCI card data	95% for card exposure	Medium	Tokenization
P1	Remove PII from log statements	70% for log exposure	Medium	Logging
P1	Add authentication to unauthenticated endpoints	95% for exposed endpoints	Low	Authentication
P2	Implement data access audit logging	-50% detection time	Medium	Monitoring
P2	Enable database activity monitoring	-60% detection time	Medium	Monitoring
P2	Add rate limiting to sensitive endpoints	60% reduction in data harvesting	Low	Rate Limiting
P2	Column-level encryption for T2 sensitive data	70% for encrypted columns	Medium	Encryption
P3	Implement data retention + auto-deletion	40% reduction in stale data exposure	High	Data Lifecycle
P3	Separate analytics store from production PII	60% for analytics breach	High	Architecture
P3	Pseudonymize behavioral tracking data	70% for behavioral data	Medium	Pseudonymization

P0 — Fix Immediately (< 1 day)

1. Fix Authorization: IDOR / BOLA

What it fixes: Broken Object Level Authorization — users can access other users' data by changing an ID.

Detection pattern in code:

# VULNERABLE — no ownership check
@app.get("/api/orders/{order_id}")
def get_order(order_id: int):
    return db.query(Order).filter(Order.id == order_id).first()

# SECURE — ownership check
@app.get("/api/orders/{order_id}")
def get_order(order_id: int, current_user: User = Depends(get_current_user)):
    order = db.query(Order).filter(
        Order.id == order_id,
        Order.user_id == current_user.id  # ownership check
    ).first()
    if not order:
        raise HTTPException(status_code=404)
    return order

// VULNERABLE
app.get('/api/users/:id/profile', authenticate, async (req, res) => {
  const user = await User.findById(req.params.id);
  res.json(user);
});

// SECURE
app.get('/api/users/:id/profile', authenticate, async (req, res) => {
  if (req.params.id !== req.user.id && !req.user.isAdmin) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  const user = await User.findById(req.params.id);
  res.json(user);
});

// VULNERABLE
[HttpGet("orders/{orderId}")]
public async Task<IActionResult> GetOrder(int orderId)
{
    var order = await _db.Orders.FindAsync(orderId);
    return Ok(order);
}

// SECURE
[HttpGet("orders/{orderId}")]
[Authorize]
public async Task<IActionResult> GetOrder(int orderId)
{
    var userId = User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
    var order = await _db.Orders
        .Where(o => o.Id == orderId && o.UserId == userId)
        .FirstOrDefaultAsync();
    if (order == null) return NotFound();
    return Ok(order);
}

2. Remove Sensitive Fields from API Responses

What it fixes: Over-fetching — APIs return more data than the client needs.

Pattern:

// VULNERABLE — returns all fields including passwordHash, ssn
const user = await User.findById(id);
res.json(user);

// SECURE — explicit projection
const user = await User.findById(id).select('id name email createdAt');
res.json(user);

# SECURE — Pydantic response model (FastAPI)
class UserPublicResponse(BaseModel):
    id: int
    name: str
    email: str
    # NOTE: password_hash, ssn, date_of_birth NOT included

@app.get("/api/users/{id}", response_model=UserPublicResponse)
def get_user(id: int):
    return db.query(User).filter(User.id == id).first()

// SECURE — DTO with @JsonIgnore
public class UserResponse {
    public String id;
    public String name;
    public String email;
    // passwordHash, ssn not included in DTO
}

3. Remove Plaintext Credentials from Code

Detection patterns:

# Patterns to search for in all files:
password\s*=\s*["'][^"']+["']
api_key\s*=\s*["'][^"']+["']
secret\s*=\s*["'][^"']+["']
token\s*=\s*["'][^"']+["']
connectionString\s*=\s*["'][^"']+["']

Fix pattern:

# VULNERABLE
DATABASE_URL = "postgresql://user:p@[email protected]/mydb"

# SECURE
import os
DATABASE_URL = os.environ.get("DATABASE_URL")
# In production: use Azure Key Vault, AWS Secrets Manager, or GCP Secret Manager

P1 — Fix This Week

4. Field-Level Encryption for Tier 1 Data

Encrypt sensitive fields before storing them. The encryption key lives in a KMS, not in the database.

Python / SQLAlchemy + Azure Key Vault:

from azure.keyvault.secrets import SecretClient
from cryptography.fernet import Fernet

# Encrypt at write time
def encrypt_field(value: str, key: bytes) -> str:
    f = Fernet(key)
    return f.encrypt(value.encode()).decode()

# Decrypt at read time (only when authorized)
def decrypt_field(encrypted_value: str, key: bytes) -> str:
    f = Fernet(key)
    return f.decrypt(encrypted_value.encode()).decode()

Node.js / Prisma + AWS KMS:

import { KMSClient, EncryptCommand, DecryptCommand } from "@aws-sdk/client-kms";

const kms = new KMSClient({ region: "us-east-1" });

async function encryptField(plaintext: string): Promise<string> {
  const { CiphertextBlob } = await kms.send(new EncryptCommand({
    KeyId: process.env.KMS_KEY_ARN,
    Plaintext: Buffer.from(plaintext),
  }));
  return Buffer.from(CiphertextBlob!).toString('base64');
}

C# / EF Core + Azure Key Vault:

// Use Always Encrypted for SQL Server / Azure SQL
// Or manually encrypt with Azure Key Vault
services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString, sqlOptions =>
        sqlOptions.EnableSensitiveDataLogging(false)));

// In entity:
[Column(TypeName = "nvarchar(500)")]
public string EncryptedSsn { get; set; } // store Base64 ciphertext

Fields that MUST be field-encrypted (Tier 1):

SSN / national ID numbers
Passport numbers
Full payment card numbers (better: use tokenization, see below)
Medical record data / diagnoses
Biometric templates

5. Tokenize Payment Card Data

Never store full card numbers. Use a PCI-compliant vault instead.

Recommended providers:

Stripe (tokenizes via Elements/PaymentIntents — you never touch card numbers)
Braintree / PayPal
Adyen
Square

Pattern:

// CORRECT — use Stripe's tokenization
const paymentMethod = await stripe.paymentMethods.create({
  type: 'card',
  card: { token: cardToken }, // token from client-side Stripe.js
});
// Store: paymentMethod.id (token) — never the card number

// WRONG — never do this
const cardNumber = req.body.cardNumber; // Tier 2 PCI-DSS violation
await db.save({ userId, cardNumber });   // DO NOT store raw card data

6. Remove PII from Log Statements

Pattern to search for and fix:

# VULNERABLE
logger.info(f"User {user.email} logged in")
logger.debug(f"Payment by {user.full_name}, card ending {card_last4}")

# SECURE — log opaque identifiers, not PII
logger.info(f"User {user.id} authenticated", extra={"user_id": user.id})
logger.debug(f"Payment processed", extra={"user_id": user.id, "payment_id": payment_id})

// VULNERABLE
console.log(`Processing order for ${user.email} at ${user.address}`);

// SECURE
logger.info('Processing order', { userId: user.id, orderId: order.id });

Structured logging fields that are SAFE to log:

Internal user ID (UUID/opaque)
Session ID (if short-lived and not externally shared)
Transaction/correlation IDs
Error codes and error types
Timestamps
HTTP status codes
Duration/latency

Structured logging fields that are UNSAFE:

Email addresses
IP addresses (must be masked — last octet)
Full names
Phone numbers
Any Tier 1–3 sensitive fields

P2 — Fix This Sprint

7. Implement Data Access Audit Logging

Every read/write of Tier 1 and Tier 2 data must be logged to an immutable audit log.

What to log:

{
  timestamp: ISO8601,
  actor_id: "user UUID",
  actor_role: "admin|user|service",
  action: "READ|WRITE|DELETE|EXPORT",
  resource_type: "User|HealthRecord|PaymentMethod",
  resource_id: "UUID of accessed record",
  fields_accessed: ["email", "phone"],  // NOT the values
  ip_address: "masked IP",
  result: "success|denied",
  correlation_id: "request trace ID"
}

Do NOT log the actual sensitive field values in the audit log.

Separation: Store audit logs in a separate database/storage account with stricter access controls than the application database.

8. Rate Limit Sensitive Endpoints

Prevents automated bulk data harvesting even if an auth vulnerability exists.

// Express + express-rate-limit
import rateLimit from 'express-rate-limit';

// Aggressive limit for data export endpoint
const exportLimiter = rateLimit({
  windowMs: 60 * 60 * 1000, // 1 hour
  max: 5, // max 5 exports per hour per IP
  message: 'Too many export requests'
});

// Standard limit for data lookup
const lookupLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100
});

app.get('/api/export', exportLimiter, authMiddleware, exportController);
app.get('/api/users/:id', lookupLimiter, authMiddleware, userController);

P3 — Fix This Quarter

9. Implement Data Retention and Auto-Deletion

Every table with personal data must have a defined retention policy.

-- Add retention column to all PII tables
ALTER TABLE users ADD COLUMN retention_expires_at TIMESTAMP;
ALTER TABLE health_records ADD COLUMN retention_expires_at TIMESTAMP;

-- Set retention at insert time
INSERT INTO users (email, retention_expires_at) 
VALUES ($1, NOW() + INTERVAL '7 years');

-- Scheduled job to hard-delete expired records (or anonymize)
DELETE FROM users 
WHERE retention_expires_at < NOW() 
AND deletion_notified_at IS NOT NULL; -- ensure user was notified

Python scheduled cleanup:

from apscheduler.schedulers.asyncio import AsyncIOScheduler

async def purge_expired_records():
    await db.execute(
        "DELETE FROM user_sessions WHERE expires_at < NOW()"
    )
    # Anonymize users (don't delete if financial records must be retained)
    await db.execute("""
        UPDATE users SET 
            email = CONCAT('deleted_', id, '@redacted.invalid'),
            phone = NULL,
            address = NULL,
            date_of_birth = NULL
        WHERE retention_expires_at < NOW() AND deleted_at IS NULL
    """)

scheduler = AsyncIOScheduler()
scheduler.add_job(purge_expired_records, 'cron', hour=2)  # 2 AM daily
scheduler.start()

10. Pseudonymize Behavioral and Analytics Data

Replace direct user identifiers in analytics with pseudonymous tokens.

import hashlib
import hmac

PSEUDONYM_SALT = os.environ.get("PSEUDONYM_SALT")  # stored in Key Vault

def pseudonymize_user_id(real_user_id: str) -> str:
    """
    One-way: analyst can track behavior across sessions 
    but cannot identify the real user without the salt.
    """
    return hmac.new(
        PSEUDONYM_SALT.encode(), 
        real_user_id.encode(), 
        hashlib.sha256
    ).hexdigest()

# In analytics event
analytics.track({
    "user_id": pseudonymize_user_id(user.id),  # NOT real user ID
    "event": "page_viewed",
    "page": request.path,
    "timestamp": datetime.utcnow().isoformat()
})

Quick Win Checklist (Complete in < 1 day)

[ ] Search all files for hardcoded secrets → move to env vars / Key Vault
[ ] Check all SELECT * queries → add explicit column list excluding sensitive fields
[ ] Verify storage buckets/containers → block public access
[ ] Remove console.log / logger.debug calls that print request bodies
[ ] Add HttpOnly; Secure; SameSite=Strict to all session cookies
[ ] Verify that /api/admin/* routes require admin role check
[ ] Confirm password reset tokens expire in < 15 minutes
[ ] Check that 500 error responses don't include stack traces in production
[ ] Verify .env and secret files are in .gitignore
[ ] Run git log --all --full-history -- "*.env" to check for historical secret commits

Blast Radius Reduction by Control Applied

When reporting the hardening roadmap, use these estimates:

Control Applied	Blast Radius Reduction	Justification
Fix all IDOR vulnerabilities	80–90%	Most breach scenarios exploit authorization flaws
Field encryption for T1 data	75–85%	Encrypted data is useless without KMS key
Remove PII from logs	40–60%	Log access is often less controlled than DB access
Tokenize payment data	95% for card data	Standard PCI-DSS compliance eliminates card data scope
Rate limit data endpoints	30–50%	Limits scale of automated harvesting attacks
Data retention enforcement	20–40%	Reduces "data lake" effect — less data to steal
Audit logging + anomaly detection	0% prevention, but -60% detection time	Breaches are caught faster
Pseudonymization of analytics	60–70% for analytics data	Analytics data decoupled from identity
Architecture: separate analytics from PII	50–70%	Breach of analytics store has no PII value

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

sjiyani

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

2026-11-09

Contributors