gmontard

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.

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 agree, in theory :)

But I’m happy you say that and gives me hope our future automated remediation suggestion can be easily adopted.

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.

SARIF output is on our Roadmap btw!

Github code scanning is not so great from what we've heard so far, but also it's very expensive, you need to be on the Enterprise plan...

Well, we're getting there, at least into proposing some fixes.

Automatically fixing is tricky, it means changing your code that can get automatically deployed in production without any other checks.. Dangerous. Not sure if you want to trust anyone to do that, tbh.

Also, considering all the edge-cases there are, it's impossible to guarantee that a fix won't break your code. If someone does, they just lie to you.

But I understand why you'd love that, as a developer, I do too :)

Not taken, just wanted to give the context of why this license.

I wouldn't say dominating tbh, but clearly one of the good solution out there for sure.

Probably the biggest differentiator is our ability to detect sensitive data flows and map those to the different security findings. It allows finding unique risks as sensitive data leaking in loggers for example, but also dynamically prioritize issues based on the type of sensitive data at risks or even decide it's not important if none are.

Let's say you're connecting to an unsecure API, we're going to assess if you're sending sensitive data or not there, depending on that we'll change the priority of the risk. If none are involved it would be a low risk, if PHI are involved it would be critical.

For the rest, I let you be the judge of the UX, quality of findings, speed etc.

Workflow is coming with our Cloud offering, with all the cool integration you can think of as Jira or Slack.

On the "marking" part, we have two options that will be available super soon: 1) Directly in the code, by adding a special comment that will ignore findings. 2) In the Cloud, an ignore action will forever park an issue, even if it changes line etc. (smart fingerprinting applied). We can't really have that in the OSS since it's state-less.

We hear you

That's right, we don't want to have someone doing managed service on top of us without a getting a license (or just an agreement). Basically, it's the AWS vs Elastic case, that resulted in this license.

Happy to revisit the license in the future when we feel more protected, but for now, we've seen so much bad behaviors in this industry with big vendors taking advantages of small companies like ours.

Absolutely!

We wanted to find a good balance with a license to allow any team to use it for their own usage no strings attached and at the same time protect us against a big vendor tempted to package our work under their product without us getting a dime... Unfortunately, it happens in this world :(

Thank you! We were actually thinking Java or PHP for the next one, so I guess it's a +1 on java :D

Would love to have some feedback to that article and understand how other are doing it! Any feedback?

Hi, I'm the co-founder of Bearer.sh.

Indeed Bearer.sh works as a package (Gem, NPM) inside your application, and it automatically instruments your HTTP stack, meaning there are zero-code changes to do on your existing integrations to make it works instantly.

But more interestingly, since we're not a proxy at all, it means you don't have to trust us to deliver that very important API traffic of yours (who would?), offer a sub-millisecond impact on your performance and works with any public, private or crazy certificate or IP restricted APIs! APIs are a liability and dependence to your app, let's not add us to that list!

We're going to launch support for many other stacks soon, and also a whole new set of "active features" as you mentioned, by still beeing 100% NOT a proxy - stay tuned in the coming days :)

Feel free to try, we offer 1M API Call per month for free and you can quickly jump to 20M for $49 only.

We're super happy to see all of the interest around that space these days, let's change the API space altogether

For once it's not a post by founders, but a post by the team living the remote-work life.

Happy to hear your feedback if you also work remotely.

Couldn’t find a better time to post this article than in the middle of France biggest strike!

Thank you! I hope we’ll get a chance to talk next time.

We think the remote culture we set combined with the natural fit of the product for developers were two key drivers of success here.

Hiring works both ways for sure!

That is sadly a good example of why relying on trusted and accountable API clients should be considered critical for business.

When consuming APIs and not thinking about this, we are only building technical debt and security issues for the future.

Today's example is really bad since it targets a well-used meta API open-source library, but how many of those issues are already present on hundreds of other obscure open-source API clients?

If you're looking for a simple way to install it I made a single line command installer with ansible: https://github.com/gmontard/grafana-graphite-statsd-ansible-...

I agree with examancer, you could put Ruby in all your article and it's not going to change anything...