Java open-source frameworks 'pose risk' to biz - report
Hibernate and don't mingle your Java and C/C++, warns software analyst
Posted in Management, 31st January 2013 10:19 GMT
Free whitepaper – Hands on with Hyper-V 3.0 and virtual machine movement
Open-source programming frameworks revolutionised Java development during the last decade, but not enough people know how to use them properly.
That’s according to the CRASH Special Report by CAST that sampled 496 applications with 152 million lines of code and found most apps had been misconfigured. This increased the degree of risk from a security perspective and lowered the quality threshold, by letting more bugs sneak in.
CAST, who makes software analysis tools, said the most popular open-source frameworks in use with Java are Struts, Java Enterprise Edition, Hibernate and Spring. CAST reckoned Hibernate has the highest quality scores and Struts the lowest scores.
Applications built without a framework of any kind had a “huge variance in quality,” CAST said in its report.
However, CAST noted apps built using just Java EE, without a framework and without any mingling of difference languages, also scored highly on quality.
Mixing Java with C or C++ lowered the score but mixing Java with COBOL, Java-DB and Microsoft’s .NET delivered “higher quality scores.”
The common link is the framework, and knowing how to use it properly.
CAST reckoned its report showed that a large majority of applications analysed had some level of misconfiguration, indicating the need for better training or to simplify the use of frameworks.
“IT leaders should double-check their choice of framework, how they mix languages, and how they enforce architectural integrity. Frameworks boost developer productivity, but they can also heighten risk and reduce quality,” CAST said. ®
Free whitepaper – Hands on with Hyper-V 3.0 and virtual machine movement
COMMENTS
You don't understand the recent vulnerability reports.
That's not how it works, not even close. Those methods can be exploited if you can send code that invokes them in a particular fashion to be executed on the host, such as when java is enabled in the browser, but a desktop application that use them isn't necessarily even network-connected, and won't be invoking them in the bad context that is required to bypass security even if it is. It's not like a buffer overflow where you can simply send them some bad data; you have to be running your own code on the host already, as the exploit only lets you get out of the security sandbox.
I'm afraid your FAIL icon applies only to yourself.
Spring/Hibernate is reinventing the wheel
Actually, it is a reinvention of the wheel. J2EE already existed, as a framework, and does most of the stuff Spring and Hibernate does. Some folks just got mad that Entity Beans were chosen for ORM mapping, then went on and built the "renegade" framework. The EE5 spec now uses annotations, threw away the original EntityBean and now uses something closer to Hibernate (IIRC Hibernate can be used as the persistence engine). Upshot of using EE5+JSF w/o extras is that resulting EARs can be deployed to appservers without munging with extra libs or XML config files on the appserver...
Enhanced knowledge!
People use frameworks, or they don't. This may increase risk or lower risk. Misconfiguration may play a role. Conclusions can or cannot be drawn, and any conclusion drawn may be due to sampling, preselection, look-elsewhere effects or lousy stats.
Next: Activities of bears in woods.
Post hoc ergo propter hoc
Right. So I should just throwing in .Net code in a Java project and magically watch the quality increase?
Did those code gazers bother to do any analysis on *why* these differences occur or is our Reg hack in question too lazy to quote them?
So using a framework doesn't automatically make code good?
Well there's a surprise.
The new Office Garage series:
