8 ms·
Show HN: Bearer – Open-source code security scanning solution (SAST)
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 https://www.bearer.com and our GitHub is here: https://github.com/bearer/bearer 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/ 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-classification/ 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 https://github.com/Bearer/bearer
- cfabianski 4y agoHello HN community, I'm Cédric Fabianski, Co-founder and CTO @ Bearer. This is a big milestone for me personally and I'm super happy to be able to contribute to the Security space and help improve the security of others' applications. This is by far the most challenging project I've ever worked on but as people say, if you don't make security simple and accessible enough, there is no way engineers are going to care about it. Let me know what you think! Any feedback is more than welcome!!
- RangerScience 4y agoThanks, this is very cool, I've been clicking around a lot! I like what you've got going, and I like how it has a resemblance to Rubocop. My first feedback - It's a little too many "clicks to code" given (1) how easy it actually is, and (2) aimed at developers. Personally, I'd slap the `brew install` + `bear scan` on the initial landing page, just under the "Get Started" link. (with an "Other Installation Options" link, 'cuz brew)`. You do a pretty good job of this (the GIF) but I look at "clicks to code" as an indicator of how focused on ease-of-use the provider is, and you're more focused on it than the landing page suggests to me. (Sinatra is the reigning champ at this). Next - 1. Pronto integration. I'd like to be able to plug it into things like Pronto, so we make sure we're not introducing new problems while we're not ready to deal with existing ones. 2. Github PR comments. It's not clear to me if the output of the GH action will create comments in a PR ala Pronto / Rubocop. It looks it probably does, so just show me a picture so I know for sure? 3. YAML option for recipes 4. I needed to upgrade to XCode 14.1 (from 14.0). Why was that necessary? Seems like it shouldn't be? 5. THANK YOU for providing links to source code from the docs! (I checked out a couple of rules). I would pick a couple of your favs and link to them from the "Custom Rule" page, too. 6. I'd definitely run a few from-scratch workshops for custom rules, recipes, etc; point people at the docs and ask them where they run into even the smallest friction. Your docs are really good but I did need to scroll and click around a bunch as I came to an understanding. Smoothing that out would be nice! (Think Rails Guides vs Rails Docs)
- alexandre_i 4y agoHad the chance to try it a few weeks ago. Took only a couple of minutes to setup, and It gave me a a few interesting warnings about PII on one of my projects. Feels like it would be a great tool for a team that is just starting to pay attention to security risks and vulnerabilities. Will follow next evolutions of your tool, thanks for sharing!