Bearer: The Open-Source SAST Tool That Actually Cares About Your Users' Privacy
Hook
Most security scanners tell you if your code is vulnerable. Bearer tells you if your code is illegally collecting your users' personal data.
Context
Traditional SAST tools have been around for decades, focusing almost exclusively on finding security vulnerabilities—SQL injection, XSS, insecure deserialization. But somewhere between GDPR going into effect in 2018 and the subsequent wave of privacy regulations (CCPA, LGPD, PIPEDA), a gap emerged: developers needed to understand not just whether their code was secure, but whether it was compliant with privacy laws.
This isn't just about avoiding SQL injection anymore. You need to document what personal data your application collects, where it flows, which third-party services receive it, and whether you have legal basis for that processing. Traditional SAST tools like SonarQube or Checkmarx weren't built for this. They'll catch your security bugs, but they won't tell you that you're silently shipping user emails to twelve different analytics providers without proper consent. Bearer was created to bridge this gap—a SAST tool that treats privacy as a first-class citizen alongside security vulnerabilities.
Technical Insight
Bearer's architecture is built around two core engines: a pattern-matching rule engine for vulnerability detection and a dataflow analysis engine for tracking sensitive data movement. Written in Go for performance, it parses source code into abstract syntax trees (ASTs) and applies configurable rules across seven languages.
The dataflow engine is where Bearer differentiates itself. When you run Bearer against a codebase, it doesn't just flag that you're reading from user input unsafely—it traces how that data moves through your application. Here's a practical example in JavaScript:
// Bearer tracks this email from source to sink
app.post('/signup', async (req, res) => {
const email = req.body.email; // Bearer identifies PII source
await db.users.create({ email }); // Flow to database
analytics.track({
userId: email,
event: 'signup'
}); // Flow to third-party service - flagged
sendgrid.send({
to: email,
template: 'welcome'
}); // Another third-party flow - flagged
});
Bearer generates a data flow report showing that PII (email) flows to three destinations: your database, an analytics service, and an email provider. This is exactly what you need for a GDPR Record of Processing Activities (RoPA) or a Data Protection Impact Assessment (DPIA).
The rule engine uses a YAML-based rule format that's more approachable than Semgrep's pattern syntax but less flexible. Rules specify patterns to match, severity levels, and remediation guidance. Here's how Bearer detects JWT secrets in code:
patterns:
- pattern: |
jwt.sign($DATA, $SECRET)
filters:
- variable: SECRET
detection: string_literal
entropy: high
severity: critical
metadata:
cwe_id: "798"
owasp_category: "A02:2021"
description: "JWT signed with hardcoded secret"
The CLI design prioritizes developer experience. Running bearer scan . in a project directory gives you results in seconds, with zero configuration required. Output formats include JSON, YAML, and SARIF (for GitHub Security tab integration), plus human-readable terminal output with color-coded severity levels.
One architectural limitation worth understanding: the open-source version performs single-file analysis. Bearer can track dataflow within a file, but if your email variable gets passed to another module, the free version loses the thread. Cross-file analysis requires Bearer Pro, which makes sense from a business model perspective but does limit the tool's effectiveness on larger codebases. For a typical Express.js API where routes, controllers, and services are split across files, you'll catch obvious issues but miss inter-module data leaks.
The rule coverage is solid—OWASP Top 10 and CWE Top 25 are well-represented with built-in rules for common vulnerabilities like SQL injection, XSS, insecure deserialization, and weak cryptography. The privacy rules cover PII detection patterns (emails, phone numbers, SSNs, credit cards), PHI in healthcare contexts, and third-party data sharing patterns for common SDKs like Segment, Mixpanel, and Sentry.
Gotcha
The single-file analysis limitation isn't just a minor inconvenience—it fundamentally changes what Bearer can detect in real-world applications. Modern applications rarely contain security vulnerabilities within single files. A SQL injection vulnerability typically involves user input in one file, sanitization (or lack thereof) in a middleware file, and query execution in a database layer file. Bearer's open-source version will catch the obvious cases where everything happens in one place, but sophisticated codebases with proper separation of concerns will see reduced effectiveness.
Language support is another constraint. While seven languages sounds comprehensive, the analysis depth varies significantly. JavaScript and TypeScript get the most attention (unsurprising given web application focus), while PHP and Python support is adequate but less mature. If you're working in C#, Kotlin, or Elixir, you'll need the Pro version. There's also no meaningful support for infrastructure-as-code scanning—tools like Checkov or tfsec are better suited if you need to scan Terraform or Kubernetes manifests.
False positive rates are reasonable but not exceptional. Privacy rules that detect PII sometimes flag variable names containing 'email' or 'phone' even when they're not actually handling sensitive data. You'll configure ignore patterns for test files and mock data quickly. The tool also can't distinguish between legitimate uses of third-party services (with proper user consent and data processing agreements) versus problematic data sharing—it flags all third-party flows and leaves the legal determination to you.
Verdict
Use if: You're building applications that handle user data and need to maintain GDPR or similar privacy compliance documentation. Bearer excels at generating data flow reports for compliance teams while providing solid baseline security scanning. It's particularly valuable for small-to-medium teams (under 20 developers) working in JavaScript/TypeScript, Ruby, or Python who need both security and privacy visibility without enterprise SAST pricing. The CLI-first design makes it trivial to add to CI/CD pipelines, and the free tier is genuinely useful for startups navigating their first privacy audit. Skip if: You need deep cross-file dataflow analysis without paying for enterprise tools, work in languages outside the core seven supported by the open-source version, or require comprehensive dependency vulnerability scanning (use Snyk or Dependabot instead). Also skip if your codebase is large and modular enough that single-file analysis will miss most issues—at that scale, you're better off with Semgrep's free tier or investing in proper commercial SAST tooling.