Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Bearer – Open-source code security scanning solution (SAST)

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 62 posts

Re: Show HN: Bearer – Open-source code security scanning solution (SAST)

#41

Post by itake »

olddustytrail wrote: post #37
itake wrote: post #24

I wish these tools would just auto fix it for me. I hate messages like this: > CRITICAL: Only communicate using SFTP connections. If you know what’s wrong, then fix it. My integration or unit tests will fail if your fix doesn’t work.

You can't just fix that in code. FTP and SFTP are completely different protocols that use different servers. You need a new server to talk to in order to fix that. And if it's a customer server maybe it can only do FTPS rather than SFTP.

Yeah… so this example is saying “you need to redesign your infrastructure before you can merge this change in.”

If sftp is a requirement, it should have been captured earlier in the process and not after the integration code was written.

Re: Show HN: Bearer – Open-source code security scanning solution (SAST)

#42

Post by itake »

gmontard wrote: post #29
itake wrote: post #24

I wish these tools would just auto fix it for me. I hate messages like this: > CRITICAL: Only communicate using SFTP connections. If you know what’s wrong, then fix it. My integration or unit tests will fail if your fix doesn’t work.

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…

> changing your code that can get automatically deployed in production without any other checks.

I’ve never worked at a place that didn’t have at least 2:

Code review checks

Qa checks

Automated testing

If an edge case breaks the code, then great! The developer can fix it (if the tool can’t). Even if 2% of the time, the system fixes it properly that’s 2% of the time the developer didn’t have to roll up their sleeves.

Re: Show HN: Bearer – Open-source code security scanning solution (SAST)

#43

Post by cfabianski »

spmurrayzzz wrote: post #39
tyingq wrote: post #17

The big missing feature for these kinds of tools is a workflow and relationship for dev teams to mark findings. Marking them as "false positive" or "only applies if these other conditions are true", or "yes, but we have a mitigation/exception". etc. A fast workflow that allows for less blockers, reduced noise and a focus on things that actually matter.

Totally agree. I love the idea of SAST-in-CI, but I ran this on a handful of repos I manage (ranging from 40k-100k SLOC) and there were too many false positives for me want to add this as build-breaking criteria to our CI pipeline. Not unique at all to bearer in any way of course, as you point out, but still a real problem. I suppose an alternative would be to not have this be a zero-sum part of CI, but maybe as a qu…

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?

Re: Show HN: Bearer – Open-source code security scanning solution (SAST)

#44

Post by gmontard »

spmurrayzzz wrote: post #39
tyingq wrote: post #17

The big missing feature for these kinds of tools is a workflow and relationship for dev teams to mark findings. Marking them as "false positive" or "only applies if these other conditions are true", or "yes, but we have a mitigation/exception". etc. A fast workflow that allows for less blockers, reduced noise and a focus on things that actually matter.

Totally agree. I love the idea of SAST-in-CI, but I ran this on a handful of repos I manage (ranging from 40k-100k SLOC) and there were too many false positives for me want to add this as build-breaking criteria to our CI pipeline. Not unique at all to bearer in any way of course, as you point out, but still a real problem. I suppose an alternative would be to not have this be a zero-sum part of CI, but maybe as a qu…

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.

Re: Show HN: Bearer – Open-source code security scanning solution (SAST)

#45

Post by gmontard »

itake wrote: post #41
olddustytrail wrote: post #37

Earlier quoted context omitted.

You can't just fix that in code. FTP and SFTP are completely different protocols that use different servers. You need a new server to talk to in order to fix that. And if it's a customer server maybe it can only do FTPS rather than SFTP.

Yeah… so this example is saying “you need to redesign your infrastructure before you can merge this change in.” If sftp is a requirement, it should have been captured earlier in the process and not after the integration code was written.

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.

Re: Show HN: Bearer – Open-source code security scanning solution (SAST)

#46

Post by gmontard »

itake wrote: post #42
gmontard wrote: post #29

Earlier quoted context omitted.

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…

> changing your code that can get automatically deployed in production without any other checks. I’ve never worked at a place that didn’t have at least 2: Code review checks Qa checks Automated testing If an edge case breaks the code, then great! The developer can fix it (if the tool can’t). Even if 2% of the time, the system fixes it properly that’s 2% of the time the developer didn’t have to roll up their sleeves.

I agree, in theory :)

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

Re: Show HN: Bearer – Open-source code security scanning solution (SAST)

#47

Post by gmontard »

spmurrayzzz wrote: post #39
tyingq wrote: post #17

The big missing feature for these kinds of tools is a workflow and relationship for dev teams to mark findings. Marking them as "false positive" or "only applies if these other conditions are true", or "yes, but we have a mitigation/exception". etc. A fast workflow that allows for less blockers, reduced noise and a focus on things that actually matter.

Totally agree. I love the idea of SAST-in-CI, but I ran this on a handful of repos I manage (ranging from 40k-100k SLOC) and there were too many false positives for me want to add this as build-breaking criteria to our CI pipeline. Not unique at all to bearer in any way of course, as you point out, but still a real problem. I suppose an alternative would be to not have this be a zero-sum part of CI, but maybe as a qu…

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 :)

Re: Show HN: Bearer – Open-source code security scanning solution (SAST)

#48

Post by ac »

First of all, thank you for making and sharing this. I have a few technical questions, if I may.

Does Bearer perform data-flow analysis? If so:

1. Is the analysis inter-procedural?

2. Is it sound? (Does it only report findings that it’s absolutely certain in but missing others; or does it report all possible findings even if some of them report false positives)

3. How are sources and sinks of information specified?

4. I see it supports JavaScript and Ruby. Any plans on adding other languages? Is the current analysis implementation amenable to adding support for other languages?

5. What’s the analysis behavior around dynamic language constructs (e.g. eval)?

6. What’s the analysis behavior around missing symbols/dependencies?

Re: Show HN: Bearer – Open-source code security scanning solution (SAST)

#49

Post by itake »

gmontard wrote: post #46
itake wrote: post #42

Earlier quoted context omitted.

> changing your code that can get automatically deployed in production without any other checks. I’ve never worked at a place that didn’t have at least 2: Code review checks Qa checks Automated testing If an edge case breaks the code, then great! The developer can fix it (if the tool can’t). Even if 2% of the time, the system fixes it properly that’s 2% of the time the developer didn’t have to roll up their sleeves.

I agree, in theory :) But I’m happy you say that and gives me hope our future automated remediation suggestion can be easily adopted.

I think these tools have to have the automation baked into the checks from v0. Adding it later can be a mess without the right abstraction.

Re: Show HN: Bearer – Open-source code security scanning solution (SAST)

#50

Post by spmurrayzzz »

gmontard wrote: post #47
spmurrayzzz wrote: post #39

Earlier quoted context omitted.

Totally agree. I love the idea of SAST-in-CI, but I ran this on a handful of repos I manage (ranging from 40k-100k SLOC) and there were too many false positives for me want to add this as build-breaking criteria to our CI pipeline. Not unique at all to bearer in any way of course, as you point out, but still a real problem. I suppose an alternative would be to not have this be a zero-sum part of CI, but maybe as a qu…

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: ` 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.

Post reply on HN