I’ve been on a call with a few security folks where their organization work with OpenAI and they are all clearly afraid of leaking sensitive data. No one yet really know how to handle this problem.

Interesting times.

I like your counter approach to everything we read lately on the topic!

I think to your point, besides the quality of the output (that we can challenge with every tool, AI or not), the problem reside in the prioritization aspect of it. Knowing you have 1000 issues is great, but knowing which one are the most critical and why, is much better if you really want to remediate them!

IMHO, AI should really help security tools when it comes to testing or providing remediation suggestions, but we should avoid using it as the engine to surface findings.

Here is an interesting article from Contrast CTO, especially in an industry that is quite opaque. Comparing one tool with another remains a big challenge, but at least this gives an interesting blueprint on how to evaluate them individually.

Oh, I’m really sorry about that, I didn’t know (my fault) mentioning we were on HN was against the rules. Calling that « vote manipulation » is quite exaggerated imho but I get it.

Ultimately I think I got carried away by the great community reception.

Anyway thanks for letting me know, I’ll avoid doing so next time.

https://hackertimes.com/newsfaq.html#ring exactly describes the circumstance and while it doesn't have its own heading in the guidelines:

> Don't solicit upvotes, comments, or submissions. Users should vote and comment when they run across something they personally find interesting—not for promotion.

seems to also match what dang is drawing attention to. My (outsider) suspicion is that the number of dead comments from new accounts on this thread drew attention to the goings-on

Btw if you have some exemple please share or even better write an issue, we’d be super happy to look at it and fine tune the rules.

It’s just a 1.0, we can do much better for sure :)

I'll cherry pick an example: the default cookie config rule(https://github.com/bearer/bearer/blob/main//pkg/commands/pro...).

We have many places where `cookie: <EncryptedString>` is used in our code and it triggers that rule. There are a few issues with this:

- Most of the expressions where we use that pattern are used to send a full encrypted cookie string. The use of `cookie` is not the name of a key in the cookie string, its the whole cookie.

- All of the data in the cookie string itself is encrypted and also sent over https. Just matching on a regex expression won't tell you this information without an accompanying AST to verify.

Notably, we're using hapi and not express but my notes above would still apply to some use cases in express as well. Its possible I am missing the actual value of that rule, but just matching on the expression is going to generate a ton of false positives.

Thanks for the feedback here; it is much appreciated :) I do know your point around catching encryption is more general than this example, but I’ve made a small improvement to the default cookie config rule regex to address one of the false positive cases mentioned https://github.com/Bearer/bearer/pull/754

This still generates the same false positive for me, in all of the previous repos I tested on.

Thanks for the report back; that's interesting. Perhaps I misunderstood your example. Feel free to write an issue if you like, and I can investigate further.

In an ideal world security tools like this one should be useless… but unfortunately we don’t all live in this world where security requirements are all captured, understood and implemented correctly.

This is what just an exemple, think about application level encryption, leakage in logger messages etc.

We need to open for configuration the filtering and prioritization logic that essentially does that today, but so you can apply your own logic.

I advise to start today by looking first only to critical alerts, with our scoring based on sensitive data impact that should be a good first step in triaging.

You're pushing it ^^

Once we're a bit more ready on the Cloud version, we'll release the pricing. Honestly I also hate when pricing is not available, so I'd like us to avoid this going further! Thanks for putting this back in my radar.

Anyway, with the OSS, you don't need to care about pricing :)

Also, super expensive, you need the $99 plan :) https://about.gitlab.com/pricing/

Integration with SCM is clearly a top priority for us, especially directly in PR. GitHub SARIF is a nice way to integrate third-party into their Dashboard, we're commited to it.