Live data from Hacker News

Code scanning for security vulnerabilities now available

github.blog

61–70 of 125 posts

Re: Code scanning for security vulnerabilities now available

#61

Isn't this already done by Dependabot[1]? I've been using it for some time with my JS/TS repos to keep my dependencies up-to-date. It's not the greatest as it sends alerts about vulnerabilities in devDependencies. But with automatic merge checks I only get an email that the issue has been fixed so it isn't the worst thing in the world. [1] https://dependabot.com/

PM from GitHub here and author of Dependabot. It's different. - Dependabot looks for vulnerabilities in your dependencies, and creates pull requests to update you to fixed versions. - Code scanning looks for vulnerabilities in your own code. So, for example, if you have written code that takes user input and creates a database instruction from it without escaping it, it will flag that you are introducing an SQL injec…

Thanks, that makes sense and I probably should have looked into the article properly.

I'm not sure, how easy it will be to filter the devDependencies. Maybe scan for config files (webpack, babel...) would be a good alternative to manually tag each npm package.

Re: Code scanning for security vulnerabilities now available

#62

GitLab has had this as part of their autodevops for a while now. My experience with their solution has been: - 'unusual' repo structures throw it off, silently doing essentially nothing. - noise is real - It caught some genuine vulnerabilities I'm not sure if github also offers the secret detection, license scanning and dependency scanning that gitlab does.

The pretty well describes pretty much every static analysis, automated security scanning tool I've ever used. They generally work ok if you use a common framework in a standard configuration using a standard project layout (once tuned properly to filter out false positives). Once you get to that point you can actually pay attention to the alerts and may even catch some significant issues.

Re: Code scanning for security vulnerabilities now available

#64

Too much nitpicking here for an unprecedented leap forward in infosec. Github giving away yet another enterprise class property away for free. The future of security is very dire and available means like this are essential to protect democracy and freedom. A lot of those noisy repos do actually run cog wheels of critical infrastructure. All praise our source code OVERLORD.

[deleted]

Re: Code scanning for security vulnerabilities now available

#65
post #45
post #31

Earlier quoted context omitted.

Just because a dependency isn’t deployed to production doesn’t mean it’s safe. Remember when eslint tried to steal people’s npm credentials? https://news.ycombinator.com/item?id=17513709

Sure, but the reported issues are usually not nearly that severe. Most of the time what I see is "A dependency of a dependency of a dependency of Webpack is vulnerable to a Regular expression Denial of Service attack" or prototype pollution or something like that.

Webpack generates code which might be loaded by users and additionally it's very common to run it on a CI server (which can sometimes have network access out to other machines at a firm).

In general, it's quite strange to me that vulnerabilities in `devDependencies` are considered less important than those in `dependencies`. These dependencies are generally for tools that are run within your company network, and contrary to what people insist, that seems quite risky to me.

Re: Code scanning for security vulnerabilities now available

#66
post #45
post #31

Earlier quoted context omitted.

Just because a dependency isn’t deployed to production doesn’t mean it’s safe. Remember when eslint tried to steal people’s npm credentials? https://news.ycombinator.com/item?id=17513709

Sure, but the reported issues are usually not nearly that severe. Most of the time what I see is "A dependency of a dependency of a dependency of Webpack is vulnerable to a Regular expression Denial of Service attack" or prototype pollution or something like that.

Also, many times those "vulnerabilites" are not really applicable because the application code can not trigger it if it never ends up in the vulnerable code path (for example when a vulnerable regex is never passed untrusted input).

I imagine those cases could be detected using static analysis but the current vulnerability reporting tools that do not even look at actual code are completely useless in that regard.

Re: Code scanning for security vulnerabilities now available

#67
post #43

Hopefully GH will apply this to Github Actions, which seem like an exploit vector just sitting there. GH Actions are: - complex enough to develop that third-party solutions are attractive, especially for simple-seeming tasks (I have just been through this) - but yay there's a "marketplace" for actions! - the code in the marketplace is the wild-west, but you'll find something that seems like it'll do what you want - y…

As far as I can see they also have access to your secrets. I really haven't gotten myself to use any non-GitHub-defined Actions yet, because I haven't been able to verify if that's actually safe.

Re: Code scanning for security vulnerabilities now available

#68
post #9

Earlier quoted context omitted.

Interesting. Consider that Github uses lots of Ruby but the tool does not support Ruby from the get go.

I have been noticing that a lot as well on other places. Ruby is no longer a "Default supported" language in many new projects. OpenTelemtry for example doesn't include Ruby in its initial beta program announcement. ".NET, Java, JavaScript, Python, Go, and Erlang!"

[deleted]
Post reply on HN