Your code is RUBBISH, says GitHub. Good thing we're here to save you Last year, GitHub added security scanning to its dependency graph – and this month flicked the lid off a can absolutely crawling with bugs. The code-sharing site kicked off vulnerability scanning in late 2017, focussing on known Ruby and Javascript library vulnerabilities designated CVE numbers by MITRE. GitHub ran the …
This post has been deleted by its author
No, most code on GitHub is rubbish. Just like SourceForge before it, and countless other open repositories.
It's not all rubbish, obviously, but let's be honest there's a lot of shit out there written by people who simply don't know what they're doing half the time. Mostly due to lack of experience as much as anything else - which highlights another point - GitHub is where hobby developers dump their stuff because they heard backups are teh cool, bro.
I wasn't criticising anyone - at least not intentionally. I was merely pointing out facts.
As for people not using GitHub to spare us the grief, I certainly never suggested that. I merely pointed out that GitHub, along with other repositories, have made it easy for hobbyists and amateur developers to maintain backups of their work. This is, generally speaking, a good thing. But it does have the side effect that statistics such as the ones mentioned in the article will be skewed, and it can make it harder to find quality work when searching for something.
As for my own work, download and install the Oso Memory Profiler and take a look at the SDK. Constructive feedback is always welcome.
> Given the context I read that as "The code-shaming site"
Why? Are you saying that it is justifiable to hide your code from scrutiny, thereby potentially exposing your users to abuse, just because you have thin skin?
Getting vulnerability scans and other code criticism (and sometimes even patches!) for free is something that directly benefits everyone, apart from being of great educational value.
It's worth pointing out that this probably applies more to private projects than open source ones on the Ruby side. It's considered bad practise to commit Gemfile.lock in open source projects and you're not supposed to lock down dependencies to exact versions in your gemspec either. The gemspec may have something like ~> 1.2 and the whole of 1.x may be vulnerable and unmaintained but it's not clear whether this checks for that. Such cases often involve more than a simple "bump" too.
Well of course they are insecure, they are JS..
The language encourages bad practices & how many places run static analysis on JS code (whereas any compiled code will (at bare minimum) have compiler warnings and (you would hope) they would have used a LINT style tool for their language(s) of choice).
We have a number of customers that do their own dependency scans for CVE vulnerabilities using the OWASP dependency checker plugin, it finds vulnerabilities all the time, but having a vulnerability in a library does not mean the application is subject the that vulnerability. It may be in part of a library that is not used, or it may only be exploitable under a specific set of circumstances which will never occur in the application.
Even if you are exposed to a vulnerability, it is often in a 2nd or 3rd tier dependency and you are dependent on the frameworks you are using updating their dependencies, rather than it being anything you can fix yourself.
The key thing is to be aware of what vulnerabilities you are exposed to, and have mitigations in place (or be prepared to accept the risk), it is not feasible to aim for zero reported CVE vulnerabilities.
Sanity checking is there for a reason.
Code can be open to exploits of a nature yet considered secure.
Nothing is set in stone.
And finally everyone is an idiot.
Words to develop by. Code repository open to all or not, on the great scheme of things this is a good thing if only to stop stupid mistakes and it's better than not having it at all.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
