Bearer v1.1 releases: finds risks and vulnerabilities in your code

Bearer

Bearer is a static application security testing (SAST) tool that scans your source code and analyzes your data flows to discover, filter and prioritize security risks and vulnerabilities leading to sensitive data exposures (PII, PHI, PD).

We provides built-in rules against a common set of security risks and vulnerabilities, known as OWASP Top 10. Here are some practical examples of what those rules look for:

• Leakage of sensitive data through cookies, internal loggers, third-party logging services, and into analytics environments.
• Usage of weak encryption libraries or misusage of encryption algorithms.
• Unencrypted incoming and outgoing communication (HTTP, FTP, SMTP) of sensitive information.
• Non-filtered user input.
• Hard-coded secrets and tokens

How do you detect sensitive data flows from the code?

When you run Bearer on your codebase, it discovers and classifies data by identifying patterns in the source code. Specifically, it looks for data types and matches against them. Most importantly, it never views the actual values (it just can’t)—but only the code itself.

Bearer assesses 120+ data types from sensitive data categories such as Personal Data (PD), Sensitive PD, Personally identifiable information (PII), and Personal Health Information (PHI). You can view the full list in the supported data types documentation.

In a nutshell, our static code analysis is performed on two levels: Analyzing class names, methods, functions, variables, properties, and attributes. It then ties those together to detected data structures. It does variable reconciliation etc. Analyzing data structure definitions files such as OpenAPI, SQL, GraphQL, and Protobuf.

Bearer then passes this over to the classification engine we built to support this very particular discovery process.

If you want to learn more, here is the longer explanation.

When and where to use Bearer?

We recommend running Bearer in your CI to check new PR automatically for security issues, so your development team has a direct feedback loop to fix issues immediately.

You can also integrate Bearer in your CD, though we recommend to only make it fail on high criticality issues only, as the impact for your organization might be important.

In addition, running Bearer on a scheduled job is a great way to keep track of your security posture and make sure new security issues are found even in projects with low activity.

Supported Language

Bearer currently supports JavaScript and Ruby and their associated most used frameworks and libraries. More languages will follow.

What makes Bearer different from any other SAST tools?

SAST tools are known to bury security teams and developers under hundreds of issues with little context and no sense of priority, often requiring security analysts to triage issues. Not Bearer.

The most vulnerable asset today is sensitive data, so we start there and prioritize application security risks and vulnerabilities by assessing sensitive data flows in your code to highlight what is urgent, and what is not.

We believe that by linking security issues with a clear business impact and risk of a data breach, or data leak, we can build better and more robust software, at no extra cost.

In addition, by being Open Source, extendable by design, and built with a great developer UX in mind, we bet you will see the difference for yourself.

How long does it take to scan my code? Is it fast?

It depends on the size of your applications. It can take as little as 20 seconds, up to a few minutes for an extremely large code base. We’ve added an internal caching layer that only looks at delta changes to allow quick, subsequent scans.

Running Bearer should not take more time than running your test suite.

What about false positives?

If you’re familiar with other SAST tools, false positives are always a possibility.

By using the most modern static code analysis techniques and providing a native filtering and prioritizing solution on the most important issues, we believe this problem won’t be a concern when using Bearer.

Changelog v1.0

Highlights

• Further OWASP Top 10 coverage on both Ruby and JavaScript.
• Reworked severity calculation see documentation for more details.
• Summary report renamed to Security report #682
• Secret scanning separated from security scanning with --scanner flag #679

Changelog

• af4650a chore(deps): bump github.com/go-enry/go-enry/v2 from 2.8.3 to 2.8.4 (#731)
• 1cdc390 chore(deps): bump golang.org/x/mod from 0.8.0 to 0.9.0 (#733)
• 0dd817f chore(deps): update dependencies (#740)
• 8308b5c chore(rule): yank dangerous_insert_html (#745)
• a625c5a feat(JS ruels): add insecure CORS rule for express (#707)
• 8fe75d7 feat(JS rules): Add CWE 916 weak password encryption (#689)
• e6a6246 feat(JS rules): Add more rules for hardcoded JWT secrets (#705)
• fc4e698 feat(JS rules): Extend expressjs insecure cookie rule (#696)
• b642439 feat(JS rules): add AWS dynamodb query injection (#664)
• ff9c4d9 feat(JS rules): add CWE to JS insecure cookie (#687)
• 0d94455 feat(JS rules): add CWE-525 bad caching policy for expressjs JWT not revoked (#695)
• f4ae336 feat(JS rules): add CWE-94 AWS Lambda code injection (#726)
• 004d2f9 feat(JS rules): add expressjs rule for missing HTTPS protocol (#715)
• 85650e1 feat(JS rules): add open redirect rule (#713)
• 7a4fe5c feat(JS rules): add template render rule patterns for express js (#712)
• 747bbf5 feat(JS rules): extend expressjs cookie rule (#700)
• 7658ca0 feat(express rule): detect missing usage within same file (#711)
• 4c80de7 feat(javascript rule): add dom purify lib (#721)
• f77ca4e feat(javascript rule): add support for react’s dangerouslySetInnerHTML (#688)
• 72e7f07 feat(javascript rule): dangerous javvascript html inserts (#693)
• 11a1ba7 feat(js rule): enrich js axios rule (#686)
• 28d99ed feat(ruby rules): add rails rule for http verb confusion (#683)
• bd7bc3e feat(ruby rules): add rails rule for permissive regex validation (#723)
• c43f1a5 feat(ruby rules): add rails send_file to path rule (#709)
• 7222310 feat(ruby rules): rails rule for render using user input (#725)
• bf75b4e feat(ruby rules): rule for hardcoded secret (#699)
• b479804 feat(ruby rules): rule for reflection using user input (#710)
• 84ebfd9 feat(ruby rules): rule for regex using user input (#694)
• d7d784e feat: Separate secrets scanning and sast (#690)
• 97e8e40 feat: add jsonlines (#742)
• c011a71 feat: enrich dangerous insert html (#697)
• 86cdb46 feat: optimize report saving (#729)
• e8b8250 feat: rename summary report to security report (#684)
• b81e2c7 feat: simplify PDS key (#724)
• a68bd4f feat: update rules default severity (#730)
• 383492f fix(JS rules): make express eval rule stricter (#714)
• 3b65905 fix(JS tests): fix outdated testdata (#722)
• 9823386 fix(docs): broken links (#702)
• ada10d7 fix(ruby rules): set correct match node in hard coded secret rule (#708)
• 422989d fix(rules): Update missing rule documentation (#748)
• 77d701d fix(rules): special case warning severity (#749)
• 962e330 fix(security report): hide progress bar for built-in rules (#706)
• 08f8a15 fix: clean up superfluous YAML attributes in rules (#741)
• d48862a fix: ignore empty string literals (#720)

Install & Use