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

Code scanning for security vulnerabilities now available

github.blog

Post reply on HN
Print view View original

111–120 of 125 posts

Re: Code scanning for security vulnerabilities now available

#111

Post by inbx0 »

bdamm wrote: post #94
falcor84 wrote: post #76

Earlier quoted context omitted.

What would be the attack vector in this case? Assuming that it's a vulnerability rather than an actually malicious package, how would an attacker exploit something running on your CI server? The only way I see is if they already have the ability to modify your source code, at which point it's of course already game over.

While it's not always considered a risk, there are many cases where being able to run code on a CI server is a vulnerability.

But ReDoS does not give them that ability

Re: Code scanning for security vulnerabilities now available

#112

Post by 411111111111111 »

cik wrote: post #60
nurettin wrote: post #46

Earlier quoted context omitted.

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

That's only true based on a certain level of care, which sadly is not always the case. Say you have a codebase that wasn't built well. Let's say your code scanner finds you at the very least the text "-----BEGIN R/DSA PRIVATE KEY-----*-----END R/DSA PRIVATE KEY-----". In my codebases that'll find nothing, but for many people, they just found SSH keys committed in plaintext. The same is true for any 1k/2k (++etc) stri…

Which is of no issue of they're just there for easy mocking etc.

I agree with the parents point, if there is value in such tests, it's so miniscule that it dwarfs the added effort to filter out all the false positives if the developers aren't total newbies. And if they are, code reviews by more experienced developers should be a given, making it redundant as well.

Re: Code scanning for security vulnerabilities now available

#113

Post by dwheeler »

franciscop wrote: post #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-…

> Open Source authors (including myself) have complained of automatic security scans. They yield way too many false positives, increasing the burden of maintaining repositories.

Unfortunately all tools have either false positives or false negatives, and in practice often both. Tools can (and should) take steps to minimize them or their impact. Nothing makes you use any specific tools; if you don't like what a tool does, don't use it.

> Specially troublesome are when e.g. the "vulnerability" (if it's even one) is in a devDependency that is not deployed to production.

This particular GitHub tool is for analyzing source code, and would not not normally analyze your dependencies. So that doesn't seem relevant in this case.

Of course, someone could mindlessly use this tool (or look at its results) and complain. That's easy, just ask for funding to fix the problem, or at least a pull request that fixes it.

Re: Code scanning for security vulnerabilities now available

#114

Post by ticmasta »

franciscop wrote: post #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-…

We have this problem with our non- OS project but found that after the initial review (of which most were false-positives) we could permanently suppress them with a comment and fail the build for net-new work without a huge impact on developers.

Re: Code scanning for security vulnerabilities now available

#115

Post by indymike »

prepend wrote: post #74
indymike wrote: post #70

Dear Github: I do not want to talk to sales for something listed on the pricing page for $21 per month. Thank you.

What’s frustrating is that it’s not part of the $21/month. I have that and have been trying to get pricing info for a few weeks. I’ve gotten mixed messages that it costs nothing extra and just uses Action minutes on their price schedule or that it costs some unknown price that is extra. My impression is that they haven’t picked pricing yet. It frustrates me when the price answer is “contact sales and let’s talk about…

Hmm. It says "included with gihub enterprise" on the product page, then on the pricing page it says $21/user/mo. Github has done a good job on making something complicated simple... but this appears to be the opposite... making the simple complicated.

Re: Code scanning for security vulnerabilities now available

#116

Post by beardedwizard »

prepend wrote: post #109
beardedwizard wrote: post #91

Earlier quoted context omitted.

They are still trying to determine pricing, and figure out how to position themselves against competitors (who are about to have thier lunch eaten if gh is smart)

I wonder if the problem is that the marginal cost is near zero because the rules are mostly open source and there’s no special infrastructure. So the problem is that they are trying to figure out the “value” instead of giving it out for free. What’s interesting about gitlab’s sast is that it’s really mostly just curating open source tools and using their existing CI stack. So it’s possible to just look at their code…

I'm also concerned about per user pricing

Re: Code scanning for security vulnerabilities now available

#117

Post by triplejjj »

greysteil wrote: post #27
ksec wrote: 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.

PM from GitHub here. We're adding Ruby support to CodeQL (the scanning engine used in code scanning by default). It's our top requested language, and one we use extensively internally. Adding each new language to CodeQL takes about 6-9 months and needs a team to maintain it in perpetuity, which is why we don't have it yet, but we're starting that work now. The other languages we hear the most demand for CodeQL suppor…

Is the CodeQL project itself open source? I would love to contribute support for Elixir.

Re: Code scanning for security vulnerabilities now available

#118

Post by franciscop »

lhnz wrote: post #65
inbx0 wrote: post #45

Earlier quoted context omitted.

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

You don't install your dependencies' devDependencies, so by definition 100% of the devDependencies on your the libraries you use are not a concern! I'm talking as a library author here (thought that was clear?), when a random vulnerability scanner marks one of my devDependencies as having an issue, that in principle won't affect the people using my library (except in some very very rare extreme cases).

Re: Code scanning for security vulnerabilities now available

#119

Post by Macha »

gitgud wrote: post #98
xjay wrote: post #14

In the not-so-distant future: Code snippet scanning for copyright infringement or Stack Overflow attribution. 2 years? 4?

Who has the rights to StackOverflow answers? Authors or the Platform? ... I wonder if it's in the terms of service...

It is. The authors own the content but must license it to SO under CC-BY-SA (the version having changed over time: https://stackoverflow.com/help/licensing ) and SO then publishes it to readers under that same license

Re: Code scanning for security vulnerabilities now available

#120

Post by lern_too_spel »

donatj wrote: post #82
nojs wrote: post #79

Earlier quoted context omitted.

It’s actually “lede” [1] > A lede is the introductory section in journalism and thus to bury the lede refers to hiding the most important and relevant pieces of a story within other distracting information. The spelling of lede is allegedly so as to not confuse it with lead (/led/) which referred to the strip of metal that would separate lines of type. Both spellings, however, can be found in instances of the phrase.…

As far as I can tell “lede” is entirely a relatively unpopular neologism being unnecessarily pushed, and the phrase spelled “bury the lead” outdates it by almost 100 years? Lede is just lead spelled incorrectly with the same meaning. https://books.google.com/ngrams/graph?year_end=2019&year_sta...

"Bury the lead" shows up in books as part of "bury the lead cable."
Post reply on HN