What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Current language coverage under Cycode stewardship: confirm against vendor docs
- Status and roadmap of the open-source CLI after acquisition: confirm
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Bearer takes a different angle from a conventional SAST scanner. It first builds a data type inventory by matching identifiers, database column names, class fields and API response shapes against a classification taxonomy: this field is an email address, this one is a date of birth, this one is a payment identifier. Then it runs rules over the code that ask what happens to those classified values. Is personal data written to a log statement? Sent to a third-party API? Stored without encryption? Passed into a string used for a query?
The output is therefore framed around data risk rather than purely around vulnerability classes. You get the usual injection and weak crypto findings, but you also get a map of which parts of the codebase touch which categories of sensitive data, which is hard to reconstruct any other way. Rules are written in YAML with pattern and data-flow clauses, and results export to SARIF and to HTML reports aimed at a privacy reviewer rather than an engineer.
Where it fits
Bearer runs as a CLI in CI, typically on pull requests with a diff-scoped scan and on a schedule for the full repository. Security engineers generally own the rule configuration while developers see the pull request comments. It pays off most when someone actually consumes the data inventory: a privacy team preparing records of processing, or an architect trying to find the undocumented paths by which customer data leaves the system. Without that consumer, you are running a mid-tier SAST tool and ignoring its best feature.
Strengths
- Sensitive data classification is genuinely useful and rare in this tool class, and it surfaces exposures a CWE-oriented scanner will never report.
- Reports are structured so a non-engineer can follow them, which makes privacy and compliance conversations concrete.
- The CLI runs without a build, and the rule format is legible enough to extend with organization-specific data types.
Limitations
- Classification depends heavily on naming. Fields called
f1orvalwill not be recognized, so results are only as good as the codebase's naming discipline. - Language coverage is narrower than the large commercial scanners, and depth varies noticeably between the best-supported languages and the rest.
- Now part of a larger commercial platform, which raises the usual question of how much investment the standalone open-source path keeps receiving.
Who it suits
Well matched to teams with real privacy obligations: health, fintech, anything handling personal data at scale. It suits organizations where security and privacy functions talk to each other. It is a poor fit if you want maximum detection depth across many languages, where a dedicated taint-analysis engine will find more.
Used Bearer? Recommend it under your own name and title.
Recommend this tool