I'm Cédric, co-founder and CTO @ Bearer.

I'm super pumped to come back here with a Show HN with not 1, nor 2 but 3 new languages support!!!

Amongst those languages, the most requested ones by our customers Java and PHP which brings the total to 6 languages supported. The rules associated to it will grow also.

Not only this, but the integration with GitLab and GitHub has never been easier.

Let us know what you think!

I'm Cédric, CTO @ Bearer

I hope you will find this useful but I really enjoyed writing this one to help protect us (users) better. Let me know if there is anything you would like to improve.

Link to the Rule https://github.com/bearer/bearer-rules/blob/main/javascript/... Link to the Recipe https://github.com/Bearer/bearer/blob/main/pkg/classificatio...

Hi HN,

I'm super happy to provide TS support today. It has been a strong ask from the community after JS support.

Every rule written for JavaScript will work for both.

Please do let us know if you have any feedback!

We wrote about it here https://www.bearer.com/blog/loom-express-session-incident and we also updated the famous NodeGoat project to bring more awareness around that kind of mis configuration https://github.com/OWASP/NodeGoat/pull/286

I took the opportunity to even update the famous NodeGoat repo https://github.com/OWASP/NodeGoat/pull/286 so that people can get more familiar with that kind of mis-configuration issue. Really hope that helps

I’ve introduced the `absence` trigger that does that If express is present but helmet is missing then break.

Do you think that’d help achieve what you have in mind?

I think the design flaw in most of the problematic rules was from too simple of regex matching. Looking for a string pattern should be a clue to do some deeper analysis (maybe verify via AST), not necessarily to flag the string alone as security failure.

The rules do work on the AST but the current cookie rule is not as advanced as it could/should be. For example, we really should treat encryption as sanitizing the value.

We'll take another look at the rules with this in mind. If you are able to share the (rough) approach you take to build the cookie string it would help us to ensure we're covering the specific case(s) you have.

Hello 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!!

Thanks, 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)

Super happy to OpenSource this bit that we used heavily @BearerSH. Once you’ve tried it, there is no way you are coming back to the old way.

Yes we switched over from one to another because NewRelic doesn’t really support Rust and DD supports StatsD and there is no lock-in. Good spot ;-)

It doesn’t change the overall quality of the applicants and yet we received more than half from the US :-)