Live data from Hacker News

Code scanning for security vulnerabilities now available

github.blog

11–20 of 125 posts

Re: Code scanning for security vulnerabilities now available

#11
post #9

Earlier quoted context omitted.

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

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

[deleted]

Re: Code scanning for security vulnerabilities now available

#12

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

Kind of surprised PHP isn't a front runner here

Re: Code scanning for security vulnerabilities now available

#13
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-an-issue becomes a chore very quickly. So far the vast majority of vulnerabilities I've seen are actually noise/not applicable. If this code checker is actually good, unlike all of the previous ones, that's another thing and might actually be a game changer.

Prominent open source authors have often suggested ways that GIthub can help but seem to be ignored, e.g. allowing to add friction to opening random issues would benefit open source greatly. At some point many beginner devs migrated from StackOverflow to Github because their really bad question were being closed there, and now they just overwhelm open source authors.

[1] https://twitter.com/sindresorhus/status/1123986529498664961

[2] https://twitter.com/FPresencia/status/1311551520689713152

Re: Code scanning for security vulnerabilities now available

#15
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!"

>Ruby is no longer a "Default supported" language in many projects.

Well it has always been like that. Amazon and Google has always had a thing about Ruby, and it is a minority market so I am not surprised and it doesn't make sense from Business perspective. But Github is a heavy Ruby users so I would have thought Ruby would be a first class citizen. I wonder if it has something to do with the language complexity.

Edit: From Github.

https://news.ycombinator.com/item?id=23094160

We (GitHub) absolutely plan to expand the list of languages CodeQL supports, and Ruby is a language we'd love to add (we're heavy users of it internally). In the meantime, because code scanning is extensible you can plug in third party analysis engines to scan the languages that CodeQL doesn't support.

Re: Code scanning for security vulnerabilities now available

#16

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

[deleted]

Re: Code scanning for security vulnerabilities now available

#17

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-…

It is tricky. I would say the perfect tool still needs to be developed. And I agree with you. Tools need to get better in detecting dependencies. However, it can be helpful to know at least that you rely on vulnerable code even if it does not get deployed to prod. To be automated, security scans are like unit tests. Just because a unit test is green does not mean your app is working and vice versa. So security scans are more like test levels: unit tests, integration tests, and end-to-end tests. Different scans, different results, and it takes us, humans, still to put it in perspective.
Post reply on HN