Supported languages
Bearer CLI supports the following language and framework combinations. When you scan a codebase, Bearer will automatically select the appropriate language based on the file extension. For example, if your application is composed of Ruby and JavaScript code, Bearer will automatically apply the right language and set of rules.
Languages | Frameworks | # rules | Status |
---|---|---|---|
Ruby | Ruby on Rails | 74 |
GA |
JavaScript / TypeScript | Express, React | 87 |
GA |
Java | Spring | 79 |
GA |
PHP | Symfony | 69 |
GA |
Go | Gorilla | 71 |
GA |
Python | Django | 88 |
GA |
Language and framework support
Bearer CLI works across a variety of languages, especially:
- Dynamically typed languages such as Ruby or JavaScript.
- Optionally strong typed languages such as TypeScript.
- Strong typed languages such as Java.
You can access the complete list of security rules and associated vulnerabilities supported for each language by Bearer CLI in the rules section.
Framework support
Bearer CLI supports the majority of frameworks, requiring only core language support to perform its analysis. However, certain frameworks may require specialized rules: these are mentioned in the table above in the "framework" section. If you observe any gaps in support for a particular framework, please submit an issue with relevant details and examples.
Support status definition
- General Availability (GA): A language at the GA stage provides a comprehensive set of rules for a wide range of security risks and vulnerabilities. It has undergone rigorous testing to ensure maximum accuracy.
- Beta: A language at the Beta stage offers good coverage of top security risks and vulnerabilities, providing a good level of protection.
- Alpha: A language at the Alpha stage does not have a strong set of pre-built rules yet and is primarily intended for users interested in creating their own custom rules.
How do we evaluate language support?
The development of a robust Static Application Security Testing (SAST) tool hinges on two crucial performance metrics: recall and precision. A modern, efficient SAST solution aims to minimize the false positive rate, to avoid inundating developers with irrelevant findings. At the same time, it should not overlook relevant vulnerabilities, or it risks giving a false sense of security.
The methodology we employ for testing our software is instrumental in achieving this level of confidence. Although there are a few benchmarking projects available for SAST, they often fall short of providing a comprehensive assessment. The multitude of coding styles and the diversity of potential vulnerabilities as numerous as the developers themselves necessitate a well-rounded test suite that truly represents how code is written. Relying solely on benchmarking projects, in this case, is insufficient.
Given this, as part of our language release procedure, we heavily depend on Open Source projects to evaluate the quality of our support. Our engineering team has composed an in-depth post detailing our approach, which we strongly recommend you review here.
How does Bearer precision compare to solutions like Brakeman, Semgrep, or Snyk?
Establishing a high degree of accuracy for a SAST is challenging, and comparing them becomes an even more complex task. As a part of our in-house toolkit, we have undertaken the task of determining how Bearer stands against other well-established solutions in the market. The comprehensive results of our comparative analysis, along with an open data set, are available here.