Google Debuts OSV-Scanner, a Go Tool For Finding Security Holes in Open Source (theregister.com) 16
Google this week released OSV-Scanner -- an open source vulnerability scanner linked to the OSV.dev database that debuted last year. From a report: Written in the Go programming language, OSV-Scanner is designed to scan open source applications to assess the security of any incorporated dependencies -- software libraries that get added to projects to provide pre-built functions so developers don't have to recreate those functions on their own. Modern applications can have a lot of dependencies. For example, researchers from Mozilla and Concordia University in Canada recently created a single-page web application with the React framework using the create-react-app command. The result was a project with seven runtime dependencies and nine development dependencies.
But each of these direct dependencies had other dependencies, known as transitive dependencies. The react package includes loose-envify as a transitive dependency -- one that itself depends on other libraries. All told, this basic single-page "Hello world" app required a total of 1,764 dependencies. As Rex Pan, a software engineer on Google's Open Source Security Team, observed on Tuesday in a blog post, vetting thousands of dependences isn't something developers can do on their own.
But each of these direct dependencies had other dependencies, known as transitive dependencies. The react package includes loose-envify as a transitive dependency -- one that itself depends on other libraries. All told, this basic single-page "Hello world" app required a total of 1,764 dependencies. As Rex Pan, a software engineer on Google's Open Source Security Team, observed on Tuesday in a blog post, vetting thousands of dependences isn't something developers can do on their own.
well (Score:4, Interesting)
Modern applications can have a lot of dependencies. For example, researchers from Mozilla and Concordia University in Canada recently created a single-page web application with the React framework using the create-react-app command. The result was a project with seven runtime dependencies and nine development dependencies.
But each of these direct dependencies had other dependencies, known as transitive dependencies. The react package includes loose-envify as a transitive dependency â" one that itself depends on other libraries. All told, this basic single-page "Hello world" app required a total of 1,764 dependencies
I could use a tool like this to check hundreds of deps. Or I could use something with only dozens of deps, something which is not react.
This is only such a huge problem because of devops and containers. Every single thing you install this way can have its own versions of everything, so you have to check them all for each program. Is this really enhancing security? More and more often devs' answer to "I can't build your software by following the directions" is "install the flatpak" or worse, a snap. Now every user has this same problem, not just developers. How is this sustainable?
Re: (Score:2)
I could use a tool like this to check hundreds of deps. Or I could use something with only dozens of deps, something which is not react.
The second approach would be the smart one. It may also be the one where the product is hard to sell because nil-wit management things it is not bling-bling enough...
It is more than devops and containers though. A few years ago I was one of the lecturers in a practical course were the students had to develop a web-application in groups over the course of a semester. The worst ones had 4000 overall dependencies with 800 people maintaining them. The best ones were still over 1000 dependencies and 200 people
How did this happen? (Score:4, Insightful)
This massive mess of dependencies should be considered a full non-starter, no wonder everything gets hacked all the time, there's no way to keep track of vulnerabilities in a 2000-dependency Hello world app, let alone a real app. I cannot believe anyone considers this acceptable.
Re: (Score:2)
Re: (Score:2)
It's what you got when you use these shitty frameworks.
Indeed. Quickly developed, but even in the early maintenance phase the lead devs are already slacking off and losing interest. Complexity and millions of features instead of KISS and concentrating on the stuff you actually need. And tons of external dependencies in _everything_, often automatically pulled in at compile time (which should be a hanging offense).
Re: (Score:2)
It's the kids who won't grow up (Score:5, Insightful)
It's because the field is full of man-children. The kids who ran around "hacking" this and that, preferrably while drinking and smoking weed, grew bigger but not more mature, and eventually donned a notional hat and pretended that made them real-world "ethical hacking" (no such thing exists) "computer security consulting professionals". They fscked up the language, then hollywood and the rest of the media took over and it all became breathless bullshit without tangible meaning.
It's also because the rest of the field won't grow up either. Expect software engineers to take any sort of responsibilities at all? Much less like how German "Diplomingenieure" are personally liable for their fuckups? "Ha ha. Not in a million years. What are you smoking?"
Take, oh, let's take an old example from FreeBSD. Someone listed both perl and python as dependencies for glib, without glib needing any such thing to run. To build is a different dependency type, but that doesn't need it either. So everything that uses the handy-dandy let's-throw-it-in-for-good-measure-why-not glib, also depends on python and perl for no good reason. If you build your own ports you can just remove those two without any ill effects. But the port maintainers Will Not Remove Those Dependencies For Any Reason. Even phk commented on it, with disbelief.
As long as I took notice of them they never fixed it. They did revamp the entire build process, and instead of having the old, nice and simple, package manager be called by the build process when the build was done, now the new package manager is indispensable well before that, in fact you can not build any ports even if you only intend to install and not package, without it. And it's a monster: It'll auto-install and auto-upgrade every time you update the ports (build) tree, but is prone to break its databases (sqlite instead of a collection of plain files) of installed ports. You can no longer just drop the broken installed ports or wipe a few misplaced or borked files. You have to wipe the entire database and start over by installing every installed port anew. And it can no longer tell you what was installed, so you have to keep the list of the stuff you need and store it separately yourself.
The guilty software (pkgng) kept on shitting itself and the only thing the guilty developers managed to utter was "it'll be fixed in the next version". How many total wipes of installed ports is that going to take, dears?
But hey, it has a full-on SAT-solver! For dependency checking! (That's a massive NP-complete problem-attacker heuristic solver, for a task that is doable in half a page of awk, namely come up with some build order that doesn't loop, or bail and complain if the graph turns out circular.) Rather than fix the dependencies, they replaced the build system with something more brittle. The broken and superfluous dependencies are still there. And they were snooty about it. (Know of anybody else who won't fix the problems in his own software but loves to blame everybody else for not working around them? No? Nevermind then.)
This is more of the same bullshit. Instead of reducing the complexity, they build tools to "manage" the complexity, or, well, pretend to manage the complexity. The heap of software doesn't get any smaller, and still contains more and more of harder and harder to find bugs, after all.
Yes yes you're very clever, dear developers. So very clever.
Re: (Score:2)
Unfortunately, you are spot-on. Although in Europe and specifically Germany, there are now some efforts to make some classes of coders responsible for their code under some conditions. You know, just like real engineers. The cost of half-assing it has just gotten too high. Of course all the (aptly named) "man-children" scream bloody murder, so surprise there.
Personally, I would not mind. I have done some very high quality development were KISS is the Alpha and Omega and being careful is just standard operat
Re: (Score:2)
a simple hello world app should not have that many dependencies, on the other hand, a javascript web app is a gui and that alone is going to bring in a ton of crap.
I just got done moving a provisioning app (fed by xml, not a gui) to a new machine and had to deal with a seemingly endless bunch of dependencies - xml, database connections, service interface libraries etc. It's a nightmare, and yet the alternative is custom code in each app, which is a completely different, and much worse, nightmare.
Modern applications can have a lot of dependencies (Score:2)
Oh yeah, because that's doing a LOT of work. /s
Google is solving the wrong problem here. Their scanner should just tell the user that they write software incorrectly if they use certain development models. Using a package manager for software development is one of those models.
Re: (Score:2)
Yep. But there are few actually wise people at Google. Most are ones with high intelligence but no wisdom and little real-world experience, i.e. outside of Google. Obviously they try to fix the wrong problem here.
Bad environment? (Score:2)
this basic single-page "Hello world" app required a total of 1,764 dependencies
Perhaps we could just judge this programming environment as insecure (and insane!) and use something else? Dependency bloat is not only a security problem. It also eats memory and performances.
Re: (Score:2)
It also is a reliability problem. This whole house of card will come crashing down and it has already started to do so.