Hi HN,

we’re the co-founders of Bearer, and today we launch an open-source alternative to code security solutions such as Snyk Code, SonarQube, or Checkmarx. Essentially, we help security & engineering teams to discover, filter and prioritize security risks and vulnerabilities in their codebase, with a unique approach through sensitive data (PII, PD, PHI).

Our website is at https://www.bearer.com and our GitHub is here: https://github.com/bearer/bearer

We are not originally Security experts but have been software developers and engineering leaders for over 15 years now, and we thought we could provide a new perspective to security products with a strong emphasis on the developer experience, something we often found lacking for security tools.

In addition to building a true developer-friendly security solution, we’ve also heard a lot of teams complaining about how noisy their static code security solutions are. As a result, they often have difficulties triaging the most important issues, and ultimately it’s difficult to remediate them. We believe an important part of the problem lies in the fact that we lack a clear understanding of the real impact of any security issues. Without that understanding, it’s very difficult to ask developers to remediate critical security flaws.

We’ve built a unique approach to this problem, by looking at the impact of security issues through the lens of sensitive data. Interestingly, most security team ultimate responsibility today is to secure those sensitive data and protect their organization from costly data loss and leakage, but until today, that connection has never been made.

In practical terms, we provide a set of rules that assess the variety of ways known code vulnerabilities (CWE) ultimately impact your application security, and we reconcile it with your sensitive data flows. At the time of this writing, Bearer provides over 100 rules.

Here are some examples of what those rules can detect:
– Leakage of sensitive data through cookies, internal loggers, third-party logging services, and into analytics environments.
– Non-filtered user input that can lead to breaches of sensitive information.
– Usage of weak encryption libraries or misusage of encryption algorithms.
– Unencrypted incoming and outgoing communication (HTTP, FTP, SMTP) of sensitive information.
– Hard-coded secrets and tokens.
– And many you can find see here: https://docs.bearer.com/reference/rules/

Rules are easily extendable to allow you to create your own, everything is YAML based. For example, some of our early users used this system to detect the leakage of sensitive data in their backup environments or missing application-level encryption of their health data.

I’m sure you are wondering how can we detect sensitive data flows just by looking at the code. Essentially, we also perform static code analysis to detect those. In a nutshell, we look for those sensitive data flows at 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.

Then we pass this over to a classification engine that assess 120+ data types from sensitive data categories such as Personal Data (PD), Sensitive PD, Personally identifiable information (PII), and Personal Health Information (PHI). All of that is documented here: https://docs.bearer.com/explanations/discovery-and-classific…

As we said before, developer experience is key, that’s why you can install Bearer in 15 seconds, from cURL, Homebrew, apt-get, yum, or as a docker image. Then you run it as a CLI locally, or as part of your CI/CD.

We currently support JavaScript and Ruby stacks, but more will follow shortly!

Please let us know what you think and check out the repo here: https://github.com/Bearer/bearer