1
I'm Guillaume, the founder of Bearer, an Open Source code security scanning tool. Despite the buzz around generative AI (which, as a reader of HN, you've likely encountered), we've also heard concerns from security teams.
When using OpenAI’s developer APIs (and other LLMs), considering how Generative AI model works, essentially the more you give, the better you receive, we essentially open the door to “overshare” information. For example, If you are building an AI assistant into your travel booking app, sending sensitive data as customer information becomes highly probable. Though, as with any shared data, this does present important security and privacy risks that we can’t overlook, hence the fear of security teams.
To address these risks, we must have explicit policies and a culture of privacy and security within the organization. We should treat generative AI models like any other third-party dependency, assessing them for vulnerabilities and safeguarding customer data. Of course, having appropriate tooling also helps.
That's why we've added a new set of rules to Bearer CLI, our open-source static analyzer, that explicitly checks for OpenAI usage. Combined with our sensitive data detection capability, this feature can alert you and your team if your code is sending sensitive data it shouldn't be.
You can find a link to Bearer CLI and the specific OpenAI ruleset in the following URLs:
Bearer CLI: https://github.com/bearer/bearer OpenAI's rule for JavaScript: https://docs.bearer.com/reference/rules/javascript_third_parties_openai/
Please feel free to test it with your code and share any feedback with us below. We welcome contributions to improve detection and add new rules to further enhance the security of your code.
I’m Guillaume, the cofounder of Bearer, an Open Source SAST solution.
After launching a few weeks ago here on Hacker News with support for Ruby and JavaScript stacks, I’m happy to report we’ve just released a new version (v1.2) with TypeScript support!
In terms of code coverage, we use the same rules already implemented for vanilla JavaScript, but as usual, you can build your own.
The rules list is here: https://docs.bearer.com/reference/rules/
It’s a first version for TS, but we believe that thanks to the pre-existing JavaScript support it should already provide good insights.
If you have some TypeScript code, we would love for you to try it out and let us know in the comment below or on our Discord your experience and how we can improve the findings.
You can access the repo here: https://github.com/Bearer/bearer
Thank you again!
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