Why I Built BoolTools GDPR & Security Checker

If you ship software that handles user data, you have compliance and security obligations whether you think about them or not.

Most developers know this in theory. We hear about GDPR fines, data breaches, and vulnerability disclosures. But in practice, compliance and security auditing feel like someone else's problem. Legal handles GDPR. The security team runs penetration tests. We just write the code.

Except that is not how it works anymore. The compliance gaps and security vulnerabilities that cause real damage almost always originate in the codebase. A missing consent mechanism, a hardcoded secret, an unencrypted data store, a missing data deletion endpoint. These are not legal oversights. They are engineering defects.

And unlike a broken button or a failed test, they do not announce themselves. They sit quietly in production until an auditor, an attacker, or a regulator finds them.

What GDPR and LGPD actually mean for your code

GDPR (EU General Data Protection Regulation) and LGPD (Brazilian Lei Geral de Protecao de Dados) are the two most impactful data protection regulations in the world. If your application serves users in Europe or Brazil, you are subject to one or both of them.

From a developer's perspective, these regulations translate into concrete technical requirements:

Consent management. Users must give explicit consent before you collect, process, or store their personal data. This means your application needs consent collection mechanisms, cookie banners that actually block tracking scripts until consent is given, and a way for users to withdraw consent at any time. If your analytics script fires before the user clicks "accept," you are already non-compliant.

Data subject rights. Users have the right to access, rectify, delete, and export their personal data. Your application needs API endpoints or workflows that allow users to request their data, correct inaccuracies, delete their account and all associated data, and download everything you have stored about them. If a user asks "what data do you have on me?" and you cannot answer programmatically, you have a problem.

Data minimization and purpose limitation. You should only collect data that is necessary for the stated purpose, and you should not use it for anything else. That "just in case" field you added to the registration form? That analytics event that captures the full URL including query parameters with user tokens? Those are potential violations.

Security measures. Both regulations require "appropriate technical and organizational measures" to protect personal data. This includes encryption at rest and in transit, access control, logging, and incident response procedures. Your Content-Security-Policy headers, your TLS configuration, your database encryption setup, all of these are compliance requirements, not just best practices.

Breach notification. If a data breach occurs, GDPR requires notification to the supervisory authority within 72 hours and notification to affected users without undue delay. LGPD has similar requirements. Your application needs logging and monitoring sufficient to detect a breach, and your organization needs a response plan.

Why developers are the first line of defense

The reason compliance is a developer concern is simple: most compliance failures are implementation failures.

A privacy policy page does not make you compliant. A cookie banner does not make you compliant. What makes you compliant is whether your code actually does what those documents promise.

Consider a practical example. Your privacy policy says "users can delete their account and all associated data at any time." But your deletion endpoint only soft-deletes the user record and leaves their comments, uploads, analytics events, and payment history intact across six different database tables and two third-party services. You have a compliance gap, and it lives in your code.

Or consider security. Your infrastructure team configured the load balancer with TLS 1.3. But your application sets cookies without the Secure flag, serves sensitive API responses without Cache-Control: no-store, and logs request bodies that contain personal data in plain text. The infrastructure is secure. The application is not.

Compliance and security are not checkboxes on a legal document. They are properties of your running system that must be validated continuously.

The security side: what you do not know can hurt you

Security vulnerabilities follow the same pattern as compliance gaps. They are silent, they accumulate, and they are almost always the result of implementation decisions rather than infrastructure failures.

The landscape of known vulnerabilities is enormous. The NVD (National Vulnerability Database) contains over 200,000 CVEs. The CWE (Common Weakness Enumeration) catalogs hundreds of software weakness patterns. MITRE ATT&CK documents adversary tactics and techniques. CISA maintains a catalog of actively exploited vulnerabilities. OWASP (Open Worldwide Application Security Project) publishes the Top 10 most critical web application security risks, along with testing guides, cheat sheets, and frameworks like ASVS (Application Security Verification Standard) that define security requirements by maturity level. And new entries across all of these sources are added every day.

As a developer, you need to worry about:

Dependency vulnerabilities. Every npm package, Go module, or Python library you import carries its own attack surface. A single vulnerable transitive dependency can expose your entire application. OSV.dev, GitHub Advisories, and the NVD all track these, but most developers only check when something dramatic makes the news.

Code-level weaknesses. Hardcoded secrets, SQL injection vectors, insecure deserialization, improper input validation, missing authentication checks. These are CWE patterns that exist in virtually every codebase at some scale. They are not exotic attacks. They are common mistakes that automated tools can detect.

Configuration vulnerabilities. Missing security headers, overly permissive CORS policies, debug endpoints left in production, default credentials in Docker configurations. These are the low-hanging fruit that attackers scan for first.

Platform-specific risks. If you deploy on AWS, GCP, or Azure, each platform has its own set of misconfigurations that can expose data. If you use Docker, your Dockerfile and compose configuration need to follow security best practices. If you run a database, its access control and encryption settings matter.

The problem is not that this information is unavailable. It is that it is scattered across dozens of databases and standards, and no developer has time to manually cross-reference their codebase against all of them.

The real problem: silent accumulation

Here is what makes compliance and security different from other engineering concerns.

When a feature is broken, users report it. When a test fails, the CI pipeline catches it. When performance degrades, monitoring alerts fire. There is a feedback loop.

Compliance and security gaps have no natural feedback loop. They accumulate silently over months or years. A developer adds a new data collection field without updating the consent flow. Another developer introduces a dependency with a known CVE. A configuration change removes a security header. A new endpoint is added without rate limiting or authentication.

None of these trigger build errors. None of them break tests. The application continues to function perfectly. But the attack surface grows, and the compliance posture degrades.

You only discover these problems in one of three ways: a security audit finds them (expensive but controlled), an attacker exploits them (expensive and uncontrolled), or a regulator investigates you (expensive and painful). There is no good scenario for finding these problems late.

The only viable strategy is continuous, automated validation.

Why I built BoolTools GDPR Checker and Security Checker

This is the problem I set out to solve with two new tools in the BoolTools ecosystem.

BoolTools GDPR Checker is an open-source compliance auditing platform that validates any software project against GDPR and LGPD using 348 curated rules across six categories: consent, data rights, security, cookies, vendor management, and organizational measures. Each rule includes a check_instruction field designed for AI agents to verify against your actual codebase, not just a checklist, but actionable verification steps.

It supports six audit types: code audits, consent audits, rights audits, security audits, documentation audits, and full comprehensive audits. You can filter by regulation (GDPR, LGPD, or both), severity level, programming language, framework, and platform.

The project includes a web UI with real-time progress tracking, a REST API for automation, and an MCP server that lets AI agents like Cursor or Claude run compliance audits programmatically. The agent workflow is straightforward: start an audit, download the rules, verify each rule's check instruction against the codebase, report results, and get a compliance report with a letter grade from A to F.

The project is fully open-source and available at https://github.com/booltools/booltools-gdpr

BoolTools Security Checker is an open-source security validation platform that audits any repository or cloud architecture against thousands of known vulnerabilities from ten authoritative sources: NVD, CWE, MITRE ATT&CK, CAPEC, Nuclei templates, CISA KEV, EPSS, Exploit-DB, GitHub Advisory, and OSV.dev. All sources are normalized into a unified database with a common schema.

It follows the same architecture as the GDPR Checker: web UI with real-time SSE progress, REST API, and MCP server for AI agent integration. You specify your language, platform, tools, and minimum severity, and it returns a comprehensive audit against all relevant vulnerability patterns and attack techniques.

The project is fully open-source and available at https://github.com/booltools/booltools-security-checker

What these tools prevent

Together, these tools address the two categories of silent risk that every application carries:

Compliance risk. Without systematic checking, your application likely has gaps in consent collection, data deletion, user data export, cookie management, or privacy documentation. Each gap is a potential regulatory violation. GDPR fines can reach 4% of global annual revenue. LGPD fines can reach 2% of revenue in Brazil. These are not theoretical numbers, they are enforced.

Security risk. Without continuous vulnerability assessment, your application accumulates known weaknesses over time. Every dependency update, every new endpoint, every configuration change can introduce a vulnerability that matches a known CVE, CWE pattern, or attack technique. These weaknesses are exactly what automated scanners and attackers look for first.

The goal of both tools is the same: make compliance and security validation as routine as running your test suite. Point them at your project, get an immediate, comprehensive answer, and know exactly what needs fixing before it becomes a problem.

Why specialized tools beat a generic AI agent

You might be thinking: "I can just ask ChatGPT or Claude to audit my code for GDPR compliance or security issues." And you can. But the results will be fundamentally different from what a specialized tool produces.

A generic AI agent relies on its own training data. It knows about GDPR and security concepts in a general sense, but it does not have a curated, structured knowledge base with 348 specific compliance rules or thousands of cataloged vulnerability patterns from NVD, CWE, OWASP, and MITRE ATT&CK. It will give you a reasonable answer, but it will miss things. It might hallucinate a rule that does not exist, or skip a real requirement because it was not prominent enough in its training data.

Specialized tools like BoolTools solve this differently. They come with a pre-built knowledge base where every rule has been curated, categorized by severity, and mapped to specific regulations or vulnerability databases. When an AI agent uses BoolTools through MCP, it does not rely on its own knowledge to know what to check. It downloads the rules from the tool, reads the check instructions, and verifies each one against your actual code. The AI's role becomes execution and reasoning, not knowledge recall.

This is the same principle behind why we use linters instead of asking an AI "does my code have style issues." The linter has a definitive rule set. The AI has opinions. For compliance and security, you need definitive rule sets.

The combination is powerful: a specialized knowledge base that knows exactly what to check, plus an AI agent that can reason about your code and determine whether each check passes or fails. Neither alone is as effective as both together.

What comes next

BoolTools started with the SEO and GEO crawler. The GDPR Checker and Security Checker are the second and third tools in the ecosystem, and they follow the same philosophy: developer-focused, open-source, actionable, and designed to integrate directly into your workflow through MCP and AI agents.

If you are building software that handles user data, and in 2026 that is virtually all software, compliance and security are not optional extras. They are technical requirements that deserve the same continuous validation as your test coverage, your performance metrics, and your deployment pipeline.

The cost of finding these problems late is always higher than the cost of finding them early. BoolTools is built to help you find them early.