Bearer CLI: a SAST scanner for security and privacy risks

What Bearer CLI scans for and who it is aimed at

Bearer CLI is a static application security testing tool. It reads source code without executing it, and the README describes its purpose as identifying, filtering and prioritizing security and privacy risks. The security side is covered by built-in rules mapped to categories from the OWASP Top 10 and the CWE Top 25: path traversal and open redirect under access control, weak algorithms and insecure communication under cryptographic failures, SQL injection, input validation, XSS and XPath under injection, hard-coded passwords and improper certificate validation under authentication failures, deserialization of untrusted data under data integrity failures, sensitive data written to logs, and server-side request forgery. All rules and their code patterns are published in the documentation rather than hidden inside the binary, which matters when you need to justify or suppress a finding.

The second half of the product is privacy. Bearer detects sensitive data flows, meaning the use of PII or PHI in an application, and it tracks components that process that data, with the README naming pgSQL, OpenAI and Sentry as examples. The output is a privacy report intended as input to a Privacy Impact Assessment, a Data Protection Impact Assessment, or the Records of Processing Activities that feed GDPR reporting. That framing tells you who the tool is for: application security engineers who want a scanner in CI, and privacy or compliance staff who need a machine-generated inventory of where personal data moves, rather than a hand-maintained spreadsheet.

How Bearer traces data flows through your code

Bearer is written in Go, and the module list in go.mod shows how it does its work. Parsing is handled by go-tree-sitter, the Go bindings for the tree-sitter parser generator, which is how one binary supports seven languages without a separate compiler front end for each. Language detection comes from go-enry, the same library GitHub uses for linguist-style classification, and gocloc supplies line counting, which is why Bearer can report on a repository's composition as well as its findings. The presence of open-policy-agent/opa indicates that policy evaluation is delegated to OPA, so rules are expressed as policy rather than hard-coded checks. Gitleaks is vendored in as a dependency, which means secret detection reuses that project's pattern set instead of a homegrown one.

The data flow part is what separates Bearer from a grep-style linter. Rather than matching a line in isolation, it builds a model of how values move from a source, such as a request parameter or a database read, to a sink, such as a query, a log call or an outbound HTTP request. A finding is raised when sensitive or untrusted data reaches a sink that the rule considers unsafe. That is why the README can claim detection of PII flowing into a third-party API: the scanner is following the variable, not the string.

The architecture is visible in the repository layout. cmd/ holds the CLI entry points, pkg/ the analysis engine, api/ the interface layer, contrib/ the install script, and e2e/ the end-to-end tests. The Dockerfile is deliberately minimal: an Ubuntu base, git installed, a non-root runuser created, the bearer binary copied to /usr/local/bin, and git's safe.directory set to wildcard so scans inside mounted volumes do not trip ownership checks. That last line is a small but telling detail about how the image is meant to be used.

Installing Bearer CLI and running a first scan

The README's fastest path is the install script, which picks the build for your architecture and places it in ./bin at the latest release version. The script is fetched from the main branch of the repository and piped to sh, so you are trusting a remote script; if that is not acceptable in your environment, use one of the package manager routes instead.

curl -sfL https://raw.githubusercontent.com/Bearer/bearer/main/contrib/install.sh | sh

Homebrew users install from the project's own tap, and the same tap handles upgrades:

brew install bearer/tap/bearer

On Debian or Ubuntu the README adds the Gemfury apt repository and installs the bearer package from it:

sudo apt-get update && sudo apt-get install ca-certificates -y && sudo update-ca-certificates
sudo apt-get install apt-transport-https
echo -e "Types: deb\nURIs: https://apt.fury.io/bearer/\nSuites: /\nTrusted: yes" | sudo tee /etc/apt/sources.list.d/fury.sources
sudo apt-get update
sudo apt-get install bearer

For a container-only workflow, the image is published on Docker Hub and ghcr.io. Mount the repository at /tmp/scan and pass that path to the scan command:

docker run --rm -v /path/to/repo:/tmp/scan bearer/bearer:latest-amd64 scan /tmp/scan

The same image can be declared in a compose file, with the repository mounted as a volume and the platform pinned to linux/amd64:

version: "3"
services:
  bearer:
    platform: linux/amd64
    image: bearer/bearer:latest-amd64
    volumes:
      - /path/to/repo:/tmp/scan

With the binary on your PATH, the first real use is a scan of the current directory. The README's guide walks through installing the CLI, running a security scan on a local project, and viewing the results, with the promise that this takes only a few minutes. You should expect a report listing findings by rule, each tied to a file and location, plus the privacy output if the scan detects sensitive data flows. Two operational notes from the repository: the Docker tags above always resolve to the latest release, so pin a specific version if you need reproducible CI results, and the compose file sets BEARER_EXECUTABLE_PATH, GITHUB_WORKSPACE and USE_BINARY environment variables for the development setup, which are not part of a normal install.

Where Bearer CLI stops and Bearer Pro begins

The sharpest limitation is stated in the README itself. Bearer CLI covers Go, Java, JavaScript, TypeScript, PHP, Python and Ruby. Bearer Pro, the commercial product available through Cycode, covers all of those plus C#, Kotlin, Elixir, VB.Net, Rust and Swift, and adds what the README calls advanced cross-file analysis for Java, Python, C#, Go. So if your service is written in C# or Rust, the open source tool does not scan it at all. If your codebase spreads a taint across files in a way that single-file analysis cannot follow, the open source tool will miss it, and that is precisely the class of bug SAST is supposed to catch.

The licence is the second thing to check. The repository's licence field is NOASSERTION, which means GitHub could not classify it automatically, and the LICENSE.txt file is the only authority. If you are planning to embed Bearer in a commercial product or redistribute a modified binary, read that file before you build anything on top of it. The README does not document rollback or downgrade procedures, so if a new release changes your finding set, you will need to pin versions yourself.

There is also a false-positive cost that the README does not quantify. Rules that trace data flows are more precise than pattern matching but still raise findings a reviewer will dismiss. Bearer's answer is prioritization and filtering, and the documentation publishes every rule and its code patterns so you can see why something fired. That is a reasonable design, but it means the first scan on a large codebase is a triage exercise, not a clean pass or fail gate.

How Bearer compares with Semgrep and other SAST tools

Semgrep is the obvious alternative, and the difference in approach is real. Semgrep's core model is pattern matching over syntax trees, with rules you write in a YAML-based DSL that mirrors the shape of the code you are looking for. That makes it fast to author a rule for a specific anti-pattern and easy to reason about why a match occurred. Bearer's model is data flow: it follows values from source to sink and reports when they reach a dangerous place, which catches vulnerabilities that no single-line pattern describes, such as a parameter that is sanitized on one path and not another.

The trade-off runs the other way too. A pattern-matching rule is transparent and cheap to run; a data flow analysis has to build a model of the program, and its results depend on how well that model handles your framework's conventions. Bearer's seven-language CLI scope is narrower than Semgrep's, and its cross-file analysis is a paid feature, whereas Semgrep's open source engine does interprocedural analysis within its supported languages. Bearer's distinguishing feature is the privacy side: the sensitive data discovery and the component inventory that feed a PIA, DPIA or RoPA are not what a general-purpose pattern matcher produces. If your driver is GDPR documentation, that is the reason to pick Bearer. If your driver is enforcing a house style or a specific API misuse rule, Semgrep's rule authoring will get you there faster.

Maintenance, upgrades and what the repository tells you

The repository is not archived, and the last push was on 2026-09-21, which is within the last week. Release cadence is visible in the tags: v2.0.2 on 2026-05-18, v2.1.0 on 2026-08-03, and v2.1.1 on 2026-08-24. That is roughly a minor release every few months with patch releases in between, which is a normal rhythm for a scanner whose value depends on keeping rules current with new vulnerability classes.

Upgrade cost depends on how you installed it. Homebrew users run brew update && brew upgrade bearer/tap/bearer. Debian and Ubuntu users run sudo apt-get update followed by sudo apt-get install bearer. RHEL and CentOS users run sudo yum -y update bearer. The install script and the Docker image both default to the latest release, so an unpinned script install or a latest-amd64 tag will move under you on the next run. In CI, pin the version explicitly if a change in the finding set would break a build gate.

The licence situation deserves a plain statement rather than advice. The repository metadata reports NOASSERTION, so the LICENSE.txt file in the repository root is the document that governs your use. The README describes Bearer CLI as a free, open solution and Bearer Pro as a commercial solution available through Cycode, which means the open source and paid products are deliberately scoped against each other. Whether that scoping affects your intended use is a question for the licence text, not for this article.

Editorial conclusion

Adopt Bearer CLI if you want a free, local SAST pass over a Go, Java, JavaScript, TypeScript, PHP, Python or Ruby repository, especially if you need a privacy report for a PIA, DPIA or RoPA. Skip it if your codebase is C#, Kotlin, Elixir, VB.Net, Rust or Swift, or if you need cross-file taint analysis, since those are listed as Bearer Pro features. Before rolling it out, run a scan on one repository and read the findings against the built-in rules documentation to see how much noise your codebase produces.

Frequently asked questions

Official sources

1. Bearer/bearer on GitHub
2. Issues
3. Project website
4. README
5. Releases