Open Source Security Report Finds Library-Induced Flaws in 70% of Applications (techrepublic.com) 44
The State of Software Security (SOSS): Open Source Edition "analyzed the component open source libraries across the Veracode platform database of 85,000 applications which includes 351,000 unique external libraries," reports TechRepublic.
"Chris Eng, chief research officer at Veracode, said open source software has a surprising variety of flaws."
"An application's attack surface is not limited to its own code and the code of explicitly included libraries, because those libraries have their own dependencies," he said. The study found that 70% of applications have a security flaw in an open source library on an initial scan.
Other findings from the report:
Other findings from the report:
- The most commonly included libraries are present in over 75% of applications for each language.
- 47% of those flawed libraries in applications are transitive.
- More than 61% of flawed libraries in JavaScript contain vulnerabilities without corresponding common vulnerabilities and exposures (CVEs).
- Fixing most library-introduced flaws can be done with a minor version upgrade.
- Using any given PHP library has a greater than 50% chance of bringing a security flaw along with it.
3rd party JavaScript and PHP libraries? (Score:1)
For the record, I have always been opposed. You should buy all your JavaScript and PHP code directly from me.
Re: 3rd party JavaScript and PHP libraries? (Score:1)
"buy"... information ...
You don't know how this physics thing works, right?
Didn't we get warned about this "service economy" (Score:2)
Going by the Economy as a Service we have these days, I think he makes a fair point.
Your servitude is economical. Back to work, prole!
Well now (Score:5, Funny)
"Using any given PHP library has a greater than 50% chance of bringing a security flaw along with it."
My sincere congratulations to the PHP team for improving their security by a whopping 50%!
Re:Well now (Score:5, Interesting)
To me it feels like we are always re-inventing the need to do a security analysis of the things we work with.
And one thing that worries me a bit is that libraries in PHP and JavaScript may not show any signs of defects until you actually execute the code. In compiling languages like Java and C# you have the opportunity to detect a number of issues at compile time.
Of course - regardless of which language you use you have to be careful with how you treat the language. Only expose information that's needed, verify that incoming data is sane and make sure you have a good type safety. Personally I prefer strong static typing because then I will directly get an indication whenever there's a mistake in the code. Some code mistakes done in scripting languages can only be detected in testing using Special Circumstances (Iain M. Banks would love that) while those mistakes would be discovered at compile time if you use a compiling language.
For developers of Java it's a good idea to also use SpotBugs [github.io], set maximum level of warnings in the compiler (Eclipse have a huge number) and keep classes small and concise. Same goes for C# where Visual Studio has a pretty good built-in analyzer and then add StyleCop [visualstudio.com] to further improve the code and documentation of it.
Remember - a warning that a compiler emits is a sign that there's something that could give you a problem. Don't ignore it. It's like the flashing yellow lights in an intersection - ignore them all the time and suddenly one day you'd get mangled by a tank.
Re: (Score:2)
PHP has warnings, most "programmers" ignore them. As a sysadmin, the log output of both commercial and Open Sourced software drives me crazy.
Re: (Score:1)
And all those warnings are execution-time warnings, not compile-time warnings where they actually makes sense.
Re: (Score:1)
Re: (Score:2)
The downside of that plan is that what's a warning today could very well be an error tomorrow.
It also doesn't help that many warnings are attempting to warn the reader about either the possibility of data corruption or a security bug.
Re: (Score:2)
Re: (Score:2)
I always turn warnings and notices into fatal exceptions and enable strict modes where ever I can. N
Re: (Score:2)
I always turn warnings and notices into fatal exceptions and enable strict modes where ever I can.
I got called "Code NAZI" for doing that.
Strong typing != Compiled. V8 JavaScript compiler (Score:2, Interesting)
You absolutely make a good point that strong typing helps make more robust software.
30 years ago, compiled languages tended to be strongly typed and interpreted languages tended to be weakly typed. So you could say "compiled" when you mean "strongly typed".
Then byecode happened and most languages use similar processes to go from source code to execution.
Today, we use the V8 compiler on JavaScript. You compare JavaScript to (scripting language - interpreted?) to Java (compiled). Funny thing - it's actually
Re: (Score:1)
I've reviewed large-scale compiled applications that consisted largely of many, many calls to Process.Start or similar. Assembling command lines and then executing them for the dumbest things, things that are very easy to do directly
Very easy is not the same as easiest. C'mon, hit that easy button.
Re: (Score:1)
Java is a bytecode interpreter, V8 turns JavaScript into actual machine code.
This is wrong. First off, Java is a language, JVM is the bytecode interpreter (or Dalvik/ART when using Java on Android).
Second, while Java does do bytecode interpreting initially, when parts of code get executed multiple times (about 10x iirc), the JIT compiler optimizes that code and compiles it into native instructions. If the execution path changes, the JIT can optimize the byte code once again, and produce optimal native code. This optimized native code runs very fast, near C++ levels.
whereis java. /use/bin/java (Score:1)
> First off, Java is a language, JVM is the bytecode interpreter (or Dalvik/ART when using Java on Android).
Try running:
whereis java
You'll probably get a result like: /use/bin/java
Java with a capital letter even I the middle of a sentence is a language. Java with a lowecase letter (or at the beginning of this sentence) is an interpreter.
Re: (Score:1)
Well, you just went out of your way to make yourself look like an idiot...
When people are talking about Java, they mean the language in 100% of the cases. Just because you can rename a binary to just about any string doesn't prove your point. By that logic, I could alias httpd to java and claim "Java is a web server".
But my first point was just a nitpick, you ignored my main point, which is that Java does compile to machine code, and produces very optimized code. It's a lot more advanced than V8 in many reg
Re: (Score:2)
For developers of JavaScript, TypeScript - and using it properly - is a wise choice. So, yes, whilst JavaScript doesn't natively support strong static typing, it doesn't mean you can't do it, just do it right.
One of the ways of using it properly means avoiding the use of 'any' for Types, at all costs - by doing this, you are negating the very reason for having it in the first instance.
I'd encourage all JavaScript developers to make the switch to TypeScript - sure, there's a learning curve, it can feel like
Re: (Score:2)
I'm seeing a very large number of security flaws that aren't. A lot of security isn't local especially for libraries. They assume that they're operating behind an application or running on an isolated server.
In many many cases the flaws in libraries I've seen come about when user data is passed to them blindly in a way that I personally would tend to limit fully or greatly in the application us
Re: (Score:2)
The same company found just as many closed vulnera (Score:3, Interesting)
I evaluated this company's product for use at a large organization. I read their reports and studies and tested the product.
The same company that did this report, Veracode, found that closed-source components have the same number of vulnerabilities. Their sales pitch for their product is around open-source libraries, so the fact that closed-source is just as bad was a footnote in their paper.
Composer (Score:3, Interesting)
Re: (Score:3)
It's too late. Everything is an Electron app. Everything ships with its own entire browser and library and OS stack, because you wouldn't want to have dependency conflicts in your string padding function, now would you?
Re: (Score:2)
Re: (Score:2)
npm as well. Last time I dealt with a small Node.js app, it required downloading about 450 modules to build. When I looked at some of those modules, the vast majority of them were literally less than 5 lines of code. The manifest files were way bigger than the source.
Oh, and every time a new version of the app is released, it refuses to build and it takes hours to sort out the dependency problems. I knew there was a reason I quit doing this crap for a living.
Re: (Score:2)
Re: (Score:2)
Less RAD, more RAD (Score:4, Interesting)
Amen to that (Score:2)
Less of the now clearly stupid "move fast and break things" bullshit.
Also more of developers working with the business at an agile level, more peer-programming, more peer-reviews and more knowledge spread within a squad.
IOW, tear down the silo, flatten the waterfall.
Not so simple to fix with snap packages. (Score:1)
Re: (Score:2)
Goes beyond snap.
Basically, this push to 'containerize' applications without even trying to make them sanely installable means that it is pervasive that library fixes cannot be acquired from a distribution but from random application providers.
I'm not surprised. (Score:1, Funny)
Re: (Score:2)
If you take more than a second to understand what the hell he's talking about, it means you haven't had your coffee yet.
I'll be right back, going to make myself a drink for completely unrelated reasons.
Re: (Score:1)
Long for the good old days (Score:1)
The rest of the story... (Score:2)
''The authors concluded that "most of these fixes are relatively minor in nature, suggesting that this problem is one of discovery and tracking, not huge refactoring of code."
When you consider the fact that the codebase is actually auditable in relation to the walled garden one gets with commercial closed source software and the ease of a relatively pain free correction is all the more reason not to use the ''walled gardens''. Hiring super talented staff is much cheaper than paying MS for a commercial lice
Re: (Score:2)
No. We never did that.
We assume that more flaws are found in OSS since source code makes it easier to find them.
This means that well-maintained OSS is likely to have LESS flaws. Not none.
Re: (Score:3)
I see no reason that "well-maintained" closed source software cannot have similar advantages, along with the one that keeps hackers from examining source directly for flaws.
Re: (Score:2)
"Weasel-words alert -- "well-maintained" and "likely"."
You say weasel, I say honesty. I know that's nearly unheard of these days, but try it, you'll like it.
"I see no reason that "well-maintained" closed source software cannot have similar advantages,"
There is an obvious reason. It's that the source is closed. No one should even have to point this out to you.
Much closed-source software is very poorly maintained. Even after disclosure of vulnerabilities to vendors, patches are often a long time coming. This
Re: (Score:2)
Quite a lot of the flaws might be problems if the application is lazy in validating what it sends to a library. I see this a lot when I check out the security flaws that get flagged for libraries. Many require the libraries to be more user facing than an application should allow. I don't know exactly how many but it's a fair number that pass my eyes.
It's als
It's Turtles all the way down. (Score:1)
Seriously folks...
I have buggy code which relies on buggy libraries which rely on buggy libraries which rely on buggy interpreters which rely on buggy compilers which rely on buggy operating systems (and their libraries, which are buggy) which rely on buggy BIOS which rely on buggy microcode which rely on a buggy CPU.
Meaning, in comparison of Windows, MacOS, Linux, BSD, etc. it's not a comparison of which is better - but which is less bad.
That we can get *anything* to run > 99% (two-nines) indicates tha
In other news, Bears defacate in the woods (Score:1)
Wow, who'd've thought it, using libraries means you inherit their bugs... Oh, and Javascript isn't too good.