Live data from Hacker News

Code scanning for security vulnerabilities now available

github.blog

41–50 of 125 posts

Re: Code scanning for security vulnerabilities now available

#41
post #26

Earlier quoted context omitted.

That's actually a very interesting point in regards to switching from StackOverflow to Github - I have noticed the trend that what I could normally find on Stackoverflow, I now often find on Github issues

Yeah, I wouldn't mind if they added an extra tab for Q&A, with additional features to make it work like a community wiki (like what SO tries to do).

Already in beta: http://github.com/vercel/next.js/discussions

Re: Code scanning for security vulnerabilities now available

#42
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.

Re: Code scanning for security vulnerabilities now available

#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

- you'd better hope the code that was committed to be executed is actually the compiled source code (if, eg, it's based on the official Typescript example and committing some [com/trans]piled JS blob that is what actually gets executed)

- it has access to your code, maybe including write access

- or it could do damn near anything else

Re: Code scanning for security vulnerabilities now available

#44
I’ll look at this, today. I have bunch of OSS repos, and, even though I might feel smug about my quality and security, I don’t think it hurts at all to shine a klieg lamp on it.

I’m fairly aghast at the state of things, and every bit helps.

Thanks, GH!

Obligatory xkcd: https://xkcd.com/2347/

Re: Code scanning for security vulnerabilities now available

#45
post #31

Open Source authors [1] [2] (including myself) have complained of automatic security scans. They yield way too many false positives, increasing the burden of maintaining repositories. Specially troublesome are when e.g. the "vulnerability" (if it's even one) is in a devDependency that is not deployed to production. In theory automatic vulnerability scans sounds great, but having every repo ping you with not-actually-…

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.

Re: Code scanning for security vulnerabilities now available

#46
post #38

Open Source authors [1] [2] (including myself) have complained of automatic security scans. They yield way too many false positives, increasing the burden of maintaining repositories. Specially troublesome are when e.g. the "vulnerability" (if it's even one) is in a devDependency that is not deployed to production. In theory automatic vulnerability scans sounds great, but having every repo ping you with not-actually-…

There's a genuine security fatigue issue (much like event fatigue) that comes from false positives. Unfortunately that doesn't reduce the value of the scanning - the onus is on the false positives. At the very least, running and pruning scans should happen on projects so that at least we can have the conversation. It's like PCI (as an example, not an ideal); PCI isn't perfect, but at least it encourages a conversatio…

Automated proof of vulnerability is valuable. Kafkaesque pattern matching, is not.

Re: Code scanning for security vulnerabilities now available

#47

What programming languages does it support? I couldn’t find out from the press release.

I had to click around a bit from the PR but: CodeQL code scanning automatically detects code written in the supported languages C/C++ C# Go Java JavaScript/TypeScript Python Source: https://docs.github.com/en/free-pro-team@latest/github/findi...

OK, so I won’t be using it. I write in Swift, ObjC, and PHP.

I really think that PHP should be on that list.

Re: Code scanning for security vulnerabilities now available

#48

I’ll look at this, today. I have bunch of OSS repos, and, even though I might feel smug about my quality and security, I don’t think it hurts at all to shine a klieg lamp on it. I’m fairly aghast at the state of things, and every bit helps. Thanks, GH! Obligatory xkcd: https://xkcd.com/2347/

I do love that cartoon (its the one where all internet is a stack of Jenga blocks, clearly depending on one block labelled "OSS project some random in nebraska has maintained since 2003".

This sort of project (ought) to level that playing field out. It ought to be clearer to us all who depends on what, and that clarity ought to give true leverage to the valued authors, or possibly point out the OpenSSl like risks we are taking.

(In fact regulators will one day wake up to just this risk, and then this will be a really valuable area to be in)

Re: Code scanning for security vulnerabilities now available

#49

Open Source authors [1] [2] (including myself) have complained of automatic security scans. They yield way too many false positives, increasing the burden of maintaining repositories. Specially troublesome are when e.g. the "vulnerability" (if it's even one) is in a devDependency that is not deployed to production. In theory automatic vulnerability scans sounds great, but having every repo ping you with not-actually-…

For every automated tool we need another automated tool that cancels first one.
Post reply on HN