Patch Management Runbook for Open-Source BI Tools

A Metabase vulnerability exposed data on 1,079,819 students and parents at Mathspace, with unauthorized access from August 10 to August 27, 2026. Attackers exploited an unpatched SQL injection flaw to gain administrator access without credentials. Framework, Tally, and Kilo Code disclosed similar breaches that month using the same vulnerability.

The pattern is clear: open-source business intelligence tools connect directly to your most sensitive databases, and unpatched instances are vulnerable to known CVEs. If you're running Metabase, Superset, or similar tools in self-hosted mode, you need a patch management protocol that treats these systems as Tier 1 infrastructure.

This runbook provides a repeatable process for managing vulnerabilities in self-hosted BI platforms. It's designed for environments where the BI tool has direct database access and holds query results in memory or temporary storage.

Purpose of This Runbook

Use this protocol when you operate a self-hosted open-source BI tool (Metabase, Apache Superset, Redash, or equivalent) that connects to databases containing personal data. The runbook establishes:

• A 72-hour patch window for critical vulnerabilities affecting authentication or query execution
• Quarterly vulnerability assessments tied to your GDPR Article 32 Technical and Organisational Measures obligations
• Access controls that limit BI tool exposure to production data

This is not a generic patch management policy. It's a specific workflow for tools that sit between your analysts and your customer database.

Prerequisites

Before implementing this runbook, verify:

• You maintain an asset register listing every BI tool instance, its version number, database connections, and the data protection officer responsible for that system
• You have a test environment mirroring your production BI configuration
• Your incident response plan includes a breach notification template compliant with the 72-Hour Notification requirement under GDPR Article 33
• You've documented which databases each BI instance can query (this becomes your blast radius map if a breach occurs)

If you don't have a test environment, create one before patching production. Metabase and Superset both support Docker deployments that you can set up in under an hour.

The Runbook

Monthly: Vulnerability Scanning

First Tuesday of each month, 09:00 local time:

1. Check the official security advisory page for your BI tool:

   • Metabase: github.com/metabase/metabase/security/advisories
   • Superset: github.com/apache/superset/security
   • Redash: github.com/getredash/redash/security/advisories

2. Subscribe to the project's security mailing list if available. For Metabase, watch the GitHub security advisories RSS feed.

3. Run docker exec [container-name] cat /app/version.txt or equivalent to confirm your running version matches your asset register.

4. Document findings in your vulnerability tracking system with CVSS score, affected versions, and exploit availability.

Critical Vulnerabilities: 72-Hour Response

Trigger: CVSS score ≥7.0 affecting authentication, authorization, or SQL execution

Hour 0-4:

• Notify your data protection officer and technical lead
• Assess whether the vulnerability affects query execution or authentication
• Check exploit databases (Exploit-DB, Metasploit modules) for working proof-of-concept code
• If a public exploit exists and you process special category data under GDPR Article 9, initiate Prior Consultation procedures with your supervisory authority

Hour 4-24:

• Deploy the patch to your test environment
• Run your standard BI query suite to verify functionality
• Test SSO integration if you use SAML or OAuth
• Verify that database connection strings and credentials weren't altered during the upgrade

Hour 24-48:

• Schedule a maintenance window
• Create a database backup
• Apply the patch to production
• Verify all database connections re-establish correctly
• Test one query against each connected database to confirm access controls remain intact

Hour 48-72:

• Monitor application logs for authentication failures or unexpected query patterns
• Document the patch deployment in your Technical and Organisational Measures register
• If you missed the 72-hour window and suspect unauthorized access occurred, you're now in breach notification territory under Article 33

Quarterly: Access Review

Last Friday of each quarter:

1. Export a list of all user accounts with query access
2. Cross-reference against your HR system or identity provider
3. Remove accounts for departed staff
4. Verify that service accounts use API keys, not shared passwords
5. Confirm that your BI tool enforces Column-Level Security or row-level filters that align with your data minimization obligations under GDPR Article 5(1)(c)

Annual: Architecture Review

Every January:

1. Map every database connection your BI tool can reach
2. For each database, identify whether it contains special category data (Article 9), data on minors, or high-risk processing categories
3. Ask: Does this BI tool need direct production access, or can it query a sanitized replica?
4. If the tool must access production, document this as a justified exception in your Data Protection Impact Assessment under ISO/IEC 29134
5. Evaluate whether you should migrate to a managed BI service with SOC 2 attestation, or continue self-hosting

Customization Options

Adjust the 72-hour window based on your data sensitivity:

• If you process special category data or data on minors, reduce to 48 hours for critical patches
• If your BI tool only accesses aggregated, anonymized data, you can extend to 96 hours

Add environment-specific checks:

• If you use Metabase's embedding feature, test that signed URLs still validate after patching
• If you've customized the Docker image, verify your changes survive the upgrade
• If you use LDAP or Active Directory integration, confirm group mappings persist

Integrate with your existing patch management:

• Link this runbook to your broader vulnerability management policy
• Use the same ticketing system and approval workflow you use for application patches
• If you operate under ISO 27001, map this runbook to control A.12.6.1 (Management of technical vulnerabilities)

Validation Steps

After deploying this runbook, verify it works:

Week 1: Run a tabletop exercise. Simulate a critical Metabase CVE announcement and walk through the 72-hour response. Time each step. If you can't patch within 72 hours, identify the bottleneck.

Month 1: Execute the monthly vulnerability scan. Confirm you can access the security advisory feed and that your version detection script works.

Quarter 1: Complete the access review. If you find orphaned accounts, that's a gap in your deprovisioning process.

Month 6: Audit your breach register. If you've had any security incidents involving your BI tool, check whether this runbook would have prevented or accelerated detection. Update the runbook based on what you learn.

Ongoing: Every time you patch, record the elapsed time from CVE publication to production deployment. If you're consistently missing the 72-hour window, you need a faster change approval process or a dedicated patch window for security updates.

The Mathspace breach happened because a known vulnerability went unpatched while attackers scanned for vulnerable instances. This runbook won't eliminate every risk, but it gives you a structured response when the next Metabase CVE drops. Customize the timelines, integrate it with your existing processes, and practice it before you need it.