Study Says Open Source Software a Security Risk 86
chareverie writes "Fortify Software released a study where they concluded that open source software poses a large security risk to corporations who have implemented it. They reason this by stating that the fault lies within the open source communities and their failure to adhere to minimum security practices. Fortify Software studied 11 open source software packages, where the application server Tomcat was determined to be the best. The other 10 were found to have poor results, with those being Derby, Geronimo, Hibernate, Hipergate, JBoss, Jonas, OFBiz, OpenCMS, Resin and Struts. Jacob West, manager of Fortify's research group, reminds that purpose of the study was 'not to condemn open source software, but rather to point out that the security practices need to improve because open source adoption by enterprises and governments is growing.'"
ZOMG!!! (Score:5, Interesting)
Why, this is just too much, how will we ever recover? And they even based it on 11 whole OSS projects... Game over!
Re:ZOMG!!! (Score:5, Insightful)
That being said, these are valid complaints, and if external support is going to be an issue with your company, then you need to think very carefully about whether open source software is right for you.
Re:ZOMG!!! (Score:2)
JBoss is owned by RedHat, so it qualifies as having a major company backing it (at least as much as RHEL does).
Re:ZOMG!!! (Score:5, Interesting)
Re:ZOMG!!! (Score:3, Insightful)
Yeah, I looked over most of the projects that they commented about... it's like, um... where are the big names? OpenBSD, Linux, X.org, Apache?
Like... oh right, if they reviewed high-profile FOSS projects rather than low-band FOSS projects, they'd come out with different results...
TRASHBIN!
Re:ZOMG!!! (Score:0, Troll)
The study is crap, but the software listed isn't.
JBoss and most of the others in the list is the major players in open source enterprise solutions.
JBoss is used in a large and fast growing number of major enterprise systems around the world.
Red Hat have world class global support for JBoss and the other technologies they support.
Java is becoming a integrated part of Open Source just like Linux, Apache, and X.org. The next versions of Ubuntu, Debian, Fedora, RHEL, and so on will have a record number of quality Java packages.
Re:ZOMG!!! (Score:1)
They were only reviewing application servers, blame the article summary.
Though incidentally: Tomcat and Geronimo are the Apache Foundation's, and JBoss is Red Hat's. Big enough names?
Re:ZOMG!!! (Score:0)
it is funny how "commercial software" vs "freeware" issues are always presented as if they were issues on "open source" vs "proprietary"
both open source and proprietary can perform good or bad depending on if they are commercialized done by proffecianals or freeware done by hobbiests
What we use (Score:2, Insightful)
Derby, Geronimo, Hibernate, Hipergate, JBoss, Jonas, OFBiz, OpenCMS, Resin and Struts
While we use tomcat, thankfully we don't use any of the others (in fact, I haven't even heard of several of them). As an example, we use Alfresco as our cms. If it ever caused security concerns, we could switch to a different open source cms. This would probably be quite a bit tougher if you were stuck with a single closed source package (and good luck finding out which "minimum security practices" a closed source vendor uses).
Re:What we use (Score:2)
So maybe the whole question if it's valid or not is completely off the mark.
Re:What we use (Score:1, Funny)
Not to be inserted into penis [failblog.org]
I've only heard of two of those... (Score:3, Interesting)
Tomcat and OpenCMS, to be specific. And I don't use any of them.
This might be interesting news to me if they found problems with: Apache 2, PHP 5, Wordpress, Gallery 2, or Python 2.5, which is basically what my site runs on.
And yes, I know there's security problems with PHP and Wordpress. I'm just pointing out that they aren't targeting more popular software; wonder why?
Re:I've only heard of two of those... (Score:4, Insightful)
JBoss is not widely used. Struts is, Hibernate mostly is... However, the underlying problem is that these are ALL middleware packages. Is the study claiming that the middleware is faulty? Or that the apps other people write on top of that middleware has issues? If it's the apps, then the middleware is likely blameless. Even if it is the middleware, why isn't the app filtering out erronious inputs? And why is the middleware being run in a container with excessive permissions?
This study manages to tell me one thing: This group has no idea how to perform studies. Even most FUD merchants would do a bit better job of covering the deficiencies in their methods.
Re:I've only heard of two of those... (Score:1, Funny)
why isn't the app filtering out erronious inputs?
Obviously a PHP programmer - as only one of those could think that should be necessary.
Re:I've only heard of two of those... (Score:3, Insightful)
Or a real programmer as any good programmer doesn't particularly care what SHOULD be necessary and only concerns himself with what IS necessary here in the real world.
Re:I've only heard of two of those... (Score:2)
Wow. You do realise that there is a whole realm of coding outside of web apps, and that at the very least you should check any and all input that is going to interact with a database or filesystem? I wouldn't call myself an expert on security, but some things are just obvious. Either that was just a very poor joke, or.. the mind boggles.
Re:I've only heard of two of those... (Score:2)
. Is the study claiming that the middleware is faulty? Or that the apps other people write on top of that middleware has issues? If it's the apps, then the middleware is likely blameless. Even if it is the middleware, why isn't the app filtering out erronious inputs? And why is the middleware being run in a container with excessive permissions?
They appear to be claiming the middleware is faulty. Note that the authors of the report sell a Java-based static analysis tool for detecting the kinds of security fault they're reporting. What proportion of the flaws it has located are actually flaws is kind-of an interesting question. If it's analysing middleware, it probably depends heavily on how the middleware is used, and chances are some of these supposed flaws are pretty unlikely to be encountered in real production code.
Here's an example I can imagine:
When an exception occurs in a servlet and it's configured to do so, Tomcat dumps the stack trace to the output web page. Now, it's plausible that the stack trace isn't quoted during output; there would not normally be any need to do so. Now imagine I create a servlet that produces and executes bytecode containing a method with a name specified by a user. Because it isn't going through a compiler, I suspect you may be able to get away with calling that method '<script>alert("hello")</script>'. This might create an XSS vulnerability, which would (at least from a static analysis tool's perspective) be in the application server's code.
I imagine this is the kind of tortured thinking that's necessary to see many of these as faults in the middleware.
Re:I've only heard of two of those... (Score:2)
a wordpress vulnerability is nominated for the pwnies.
it's probably patched, but not everyone uses the latest wordpress version, so it's still bad.
the compromise allowed remote attackers to put any kind of mal-ware distribution site on any vulnerable wordpress site.
not to mention the horrible debian flaw, dating back to 2006 where a programmer removed 2 critical lines of code, that limited debian to 15-bit keys for all openssl operations! that's about 15,000 keys.
FOSS is vulnerable to bad flaws, clever hackers can complain about a 'problem' with code, and if they're lucky get a patch put in that makes software vulnerable, easily, and with debian manage to corrupt systems for 2 years.
more eyes is better, yeah right. I still have hope for linux, because even if one particular distro makes horrible mistakes, you still have the source to work with. not to mention it only costs time to harden a linux system, with windows it costs money.
Re:I've only heard of two of those... (Score:0)
FOSS in theory is great- if a FOSS app has a critical flaw there is a great incentive to FIX it, fast, or the software will simply be dropped.
In a proprietary situation (like Windows) flaws are ignored if possible, touted as 'features' if unfixable, and hidden if critical. Those vendors have a vested interest in not only hiding problems, but also in providing support to 'fix' them for the customers. The last thing they want is someone releasing a fix for them- it makes them look stupid and prevents them from claiming that the 'fix' cost so much that they have to charge more, and makes their customers question why they pay for support in the first place.
Conflict of interest (Score:5, Funny)
Re:Conflict of interest (Score:2, Informative)
WTF? My team uses Fortify to analyze our Java webapps (compiled on the Sun JDK [slashdot.org] and running on their JRE), which is then deployed to Linux servers running RHEL 5 [redhat.com]. HTTP connectivity for the apps is provided by Jetty [mortbay.org]; the apps themselves connect to Oracle [oracle.com] databases (using C3P0 [mchange.com] for connection pooling).
With Fortify 4.0, I griped that it provided no value that we didn't already get with FindBugs [sourceforge.net] (for free). The 5.0 release (along with the workbench, which provides better information than the HTML report), however, did catch a few bugs which weren't caught by FindBugs. We now run both tools in our automated Hudson [java.net] builds.
Where, exactly, are the Microsoft products in the above list?
Re:Conflict of interest (Score:0, Redundant)
Despite the insightful mods, I think GP was trying to be funny.
Re:Conflict of interest (Score:3, Funny)
Not necessarily (Score:2)
Since Fortify is a security firm, it's obviously in their best interest to have everybody using their own products.
There. Fixed that for ya.
Re:Not necessarily (Score:0)
WOOOOOOOOOOOOSH!
Re:Conflict of interest (Score:0)
It's absolutely possible they want the "security job" security of a Microsoft hegemony.
I've worked with techs who really do see software deficiencies as job security. which sucks because I see those deficiencies as time wasters and ripoffs of the customer.
I expect my garbage to take itself out. (Score:0)
How can you expect decidedly anti-corporate open source to have decidedly corporate security regimes?
There WILL be vulnerabilities, but at least you MIGHT know about them in time to do something.
This is a HR problem for said organizations.
OSS is a risk compared too... (Score:5, Insightful)
... not running software at all (Score:1)
very good point.
9/10 dentists agree that you should brush your teeth.
The other dentist wants more business.
in other news... (Score:4, Insightful)
to explain the parent post with quotes : (Score:3, Funny)
Eric S. Raymond discusses the recent Microsoft security debacle in which an engineer inserted a back door in a library that allowed access with the phrase 'Netscape engineers are weenies!' The article notes that 'Apache will *never* have a back door like this one.
http://linuxtoday.com/stories/20234.html [linuxtoday.com]
Re:to explain the parent post with quotes : (Score:2)
O RLY? [cmu.edu]
Never is too strong of word methinks.
Re:to explain the parent post with quotes : (Score:0)
Oh, puh-leeze. This same ancient article is trotted out endlessly in every single security-related story here, apparently by people who don't understand it.
Look, it's a neat hack, but for numerous reasons (primarily the diversity of compilers and processor architectures in use today) it is, to all intents and purposes, as close as you can get to impossible that any major multi-platform open-source product (such as gcc) could have such a backdoor in it.
In other security news.. (Score:3, Insightful)
Re:In other security news.. (Score:1)
Note: research was done on a closed network and no hackers were able to infiltrate the system in a one hour window proving the closed source superiority
bullcrap. open source software is fixed faster (Score:1, Troll)
Judge for yourself (Score:5, Interesting)
I'm not an expert on open source and security but I get the feeling that the authors judged open source software based on closed source standards. They author complain that disclosing security issues with general bugs was a problem. Did the author not understand that full disclosure is one of the tenets of open source? The last gripe is that the service wasn't the same with lack of contacts and responses. Judging by the summary it appears that the author just monitored the community forums. Did the authors even pay for support? When you pay for software and support, you should get it. When you don't pay for software or support, why should you deserve service?
Re:Judge for yourself (Score:0)
But, if you don't twist the truth and scream that the sky is falling, that's not a news story!
Can you imagine a story: "Open source software working as intended"?
Re:Judge for yourself (Score:5, Interesting)
Many of the projects they evaluated are Apache projects. The Apache Foundation has a private list for security bugs (security AT apache.org) so their complaints on that basis are unjustified for those projects at least. And I would be very surprised if they found security bugs in all of those projects in order to test the responsiveness of the developers, so I guess they sent some random mail that was probably justifiably discarded as spam.
Re:Judge for yourself (Score:2)
Re:Judge for yourself (Score:2)
Proprietary Software Poses a Risk to corporations (Score:3, Interesting)
Closed source/propetiary software doesn't adhere 100% to industry "best" practices, such as providing a prominent link to security information on their Web site either.
It's just not as easy to see where closed source is lacking, because, well: you don't have the source to conduct research into the security flaws.
If the source was not public, you in many cases, would have never known that X practice wasn't being followed by certain elements of the software.
Closed software can ignore practices whenever convenience, and since the source is closed, they are all but immune to this type of analysis.
A true comparison requires actually obtaining the source to proprietary software and using that to its full advantage to find security flaws.
Blah blah blah (Score:3, Insightful)
Studies also conclude that lunixes is a big intellectual IP property ripoff doomed to failure, laptops will completely replace desktops in ten years, and piracy is a really big problem that's sending business after business into bankruptcy.
It's wonderful how you can release any anecdotal evidence from a limited perspective as a marketable 'study'.
I'm releasing a study on how interest groups posing as reputable and productive companies pass bullshit around like the flu.
Re:Blah blah blah (Score:2)
Re:Blah blah blah (Score:2)
It's not as exciting to be fair, and if all studies were fair and perfectly concluded there'd be a lot less news on the slashfront I think.
Apples, oranges, or bananas? (Score:5, Informative)
They also forgot to have a proprietary package -- so the comparison is between open source packages. They might as well say, "Proprietary software poses a security risk. We've evaluated
Re:Apples, oranges, or bananas? (Score:4, Insightful)
No, if anything, these packages aren't unrelated enough to get a good cross section of FOSS. They're mostly web app-related thingys that are tied into Java. I haven't heard of most of them, probably because I stay strictly away from Java.
Re:Apples, oranges, or bananas? (Score:2)
You may, but much of the enterprise web development world doesn't. Sorry to break it to you, but PHP really isn't that popular in massive corporation websites. Regardless of the quality of this review, Fortify is a fairly well entrenched security code analysis tool that many corporations use. I would say a number of Fortune 500 companies who use Java that had security analyses done at my former employer, but that is confidential.
Re:Apples, oranges, or bananas? (Score:2)
I don't use PHP either. And I do work under a Fortune 500.
WTF (Score:3, Funny)
Re:WTF (Score:0)
Re:WTF (Score:3, Funny)
Yes, Mr.Strawman, I'm sure they do.
Hmmm... that got me thinking.
Straw man + flamebait = ??? (think of an ultra flamable scarecrow)
Re:WTF (Score:1)
Nice, Slashdot has invented a new logical fallacy: The Burning Man Fallacy.
Behind closed doors.... (Score:0)
Why don't the closed source company's show us there code are they afraid we will see it's all half-assed security...
Closed source is based on lies!!!
the biggest lie (Score:0)
[guess]closed source is full of snagged open source code. That's one of the real reasons they want to keep it closed forever, legal liability.[/guess]
The best way to get results (Score:0)
Is obviously to do a study on software no-one's EVER heard of.
Well, that's not true, I've heard of tomcat, the most secure thing there, what a surprise.
How about they study software people actually use? Like Linux, Apache, Python, PHP etc.
I wonder if it's because the last times studies were done on those it was found that they were far more secure than closed source software, in a US GOVERNMENT FUNDED STUDY
Re:The best way to get results (Score:2)
I wonder if it's because the last times studies were done on those it was found that they were far more secure than closed source software, in a US GOVERNMENT FUNDED STUDY
The problem with that is you think that the government is going to be unbiased. Granted, the government isn't on the payrolls of Red Hat or Microsoft, but wouldn't it be in the government's best interest to use open source software that is a lot easier to audit and a ton cheaper? I'm not saying that they are wrong, but the government does have a lot of reason to mess with the statistics to their own favor.
Re:The best way to get results (Score:2)
We don't really know which way they're going to be biased, though. They could swing for closed source (if Microsoft's lobbists are going on a spending spree this week) or for open source (if it's Red Hat lobbists turn to do the same). The US government is also easily big enough to produce conflicting information due to different departments working on the same problem.
However, I maintain that the funding of the study is ultimately irrelevant. If the method is correct, and the data is correct, and the logic is correct, then the conclusions should be correct. If bias has an effect, you should be able to find it within one of those factors. If you can't find it, then repeat the study and see if you get the same results. If you do get the same results, and the majority of other studies get the same results, then the conclusion should be accepted. The scientific method is good at rooting out bias like that.
As for this study, the article seems to indicate that it mostly revolves around there not being a single point of communication for security on these projects, and security is treated through the same channels as general bugs. The benefits of hiding security info until after a patch is released is hardly a settled issue in the security community, and FOSS in particular will tend to err on the side of transparency. It's more of a nitpicky point than anything fundamentally wrong.
Re:The best way to get results (Score:2)
Is obviously to do a study on software no-one's EVER heard of.
To be fair to the report's authors, if you're a Java web app developer (which is their target audience, as they're trying to sell a Java web app security analyzer) you probably recognize most of these projects. Derby was the only one I didn't know.
Duh? Anyone else tag it like that? (Score:1)
Where to start... (Score:5, Informative)
FTFA:
The projects in question:
Tomcat, Derby, Geronimo, Hibernate, Hipergate, JBoss, Jonas, OFBiz, OpenCMS, Resin and Struts.
For those who don't play in Java often:
Derby is an embedded database.
Tomcat, Geronimo, JBoss, Resin and JOnAS are Java (EE) app servers.
Hipergate and OpenCMS are (you guessed it) content management systems.
Hibernate is a persistent framework.
Struts is a web framework.
So of any of these, it seems that the only projects that would be open to XSS or SQL injection would be the CMS products. Unless they're referring to the web administration for the app servers?
The only way to have SQL injection attacks in javaland is if you're not using prepared statements or if your database driver isn't preparing/escaping properly.
So they're saying two CMS projects have tens of thousands of XSS and SQL injection vulnerabilities?
Re:Where to start... (Score:4, Insightful)
I wonder how they're counting. They quote says across "multiple versions". Are they giving multiple counts for a single vulnerability that exists in multiple versions?
Re:Where to start... (Score:5, Interesting)
You're just on the edge, I suspect, of the reason they didn't get good responses from the maintainers of the code for the "vulnerabilities" they reported. That's because, in most cases, they probably weren't vulnerabilities. The authors of the report are the producers of a static analysis tool that -- you guessed it -- detects potential XSS and SQL injection vulnerabilities. Of course, it (like all such tools) has a very high false positive rate.
In the case of code that automatically generates SQL code algorithmically (not using hard-coded prepared statements, for example) like Hibernate, or generates HTML code algorithmically (like, say, pretty much any JSP implementation or templating language), the number of false positives is going to be huge.
Any bets they didn't bother stripping out those false positives before reporting the "vulnerabilities"?
Re:Where to start... (Score:0)
FTFA:
Note this:
associated with multiple versions of the 11 open source software packages examined.
How about testing oh, maybe the last version released?
Mutliple Versions? (Score:0)
"Fortify identified a total of 22,826 cross-site scripting and 15,612 SQL injection issues associated with multiple versions of the 11 open source software packages examined. "
By multiple versions, do you mean they summed the bugs found across all versions released, so a program in version 1.23 which fixed a SQL injection in 1.22 gets nailed for it in 1.1, 1.2, 1.3... 1.22?
This just in: releasing more versions multiplies the storage space required to store all versions of the software, thus Windows, with its 6-7 versions has a tiny footprint when compared to a monolith like Linux with its 26 bloated 2.6 kernels (we'll be kind and not even count the 2.4 ones). Everyone should move to Windows (study sponsored by a not-fully-owned-subsidiary-of-Microsoft
Java/Apache heavy? (Score:4, Insightful)
Is it just me, or is this survey extremely Java heavy?
Not only that, but there are a good number of Apache projects in particular... Apache Tomcat [apache.org], Apache Geronimo [apache.org], Apache Derby [apache.org], Apache Struts [apache.org]...
Re:Java/Apache heavy? (Score:1)
AIRC, The Fortify folks sell tools that do security auditing (static analysis) of Java code. So my money is on observers bias.
Not paying much attention to the Web Services arena, are these some of the most popular Java projects?
- ash
Re:Java/Apache heavy? (Score:2)
I've only used Tomcat. The others I've only run across while looking up information at work.
Re:Java/Apache heavy? (Score:2)
I don't know how much traction Geronimo or Derby have got now, but Struts, Hibernate, Tomcat, and JBoss are very popular, Resin and Jonas less so. The others I haven't heard of, but judging by their names OpenCMS and OFBiz are probably a bit outside my field so may be popular within their own field, and hipergate sounds like it might be a fork of hibernate, but a quick google shows it is actually a CRM server, again outside my field.
Re:Java/Apache heavy? (Score:2)
Not paying much attention to the Web Services arena, are these some of the most popular Java projects?
Yes. Judging by the recruitment adverts I see, Tomcat+Hibernate+Struts is probably the most common combination of server & frameworks for new Java-based web projects right now. The others are pretty close, though. I'm surprised they missed out Spring, but that's a more generic and not web-biased framework. Also, it's probably not particularly susceptible to static analysis, as it does most of its work via runtime code generation, I believe.
Re:Java/Apache heavy? (Score:2)
Java-focused (Score:2)
Yes, it's Java-heavy. The study author sells a proprietary static analysis tool for Java. So the Java bias is understandable, but their title should have made it clear that they were only analyzing a few Java programs, and not a representative sample of major OSS projects. They also ignored the enterprise support options for these programs, which is completely unjustifiable.
I think its Java bias matters. Until very recently, most Java programs required Sun's proprietary Java implementation. The FSF and others warned of the Java Trap [gnu.org] - so a very large proportion of the FLOSS community has actively ignored these Java programs. Sun has recently released most of its Java implementation as FLOSS, and the most recent versions of Fedora and Ubuntu have now integrated it (through Debian hasn't), so I think we'll start to see more cooperation in Java projects.
They made three claims, let's take a look at them...
"Failure to Provide Access to Security Expertise... [aka] documentation that covers the security implications and secure deployment of the software they develop, a dedicated email alias for users to report security vulnerabilities, or easy access to internal security experts to discuss security issues". Odd, they seem to be ignoring the enterprise versions (e.g., Red Hat sells JBOSS support); that doesn't seem to be a fair methodology. Their demand for a "dedicated email alias" and "easy access to internal security experts" shows that they fail to understand that some people want totally open discussions, which these projects do support. They may not LIKE that, and actually I'd agree with them, but claiming that there's NO way to report vulnerabilities or to talk with developers seems fundamentally mistaken. I agree with them that documentation about security needs improvement, though I don't see any evidence that FLOSS is worse than proprietary on that count.
"Failure to Adopt a Secure Development Process... In virtually every project analyzed, there were a significant number of security issues that went unaddressed over three generations of releases...". It's not clear what these "issues" were. Were these REAL issues, or just reports from a static analysis tool? I wish they'd gone more into this, it's hard to say this is really true or not given their report. Often static analysis tools' reports have LOADS of false positives. As a result, it's hard to see if this is real or not.
"Failure to Leverage Technology to Uncover Security Vulnerabilities: The number of security issues identified in the study - especially in the most popular open source packages - was surprising...". Again, not surprising if what is being measured is raw unanalyzed tool output. It could be that every single "vulnerability" is a false positive (not an uncommon result, unfortunately). I would agree with them that I'd like to see more projects use more tools, but a lot of FLOSS projects do use tools. For example, the Linux kernel developers ended up creating their own static analysis toolsuite because tools are normally designed to analyze applications, not kernels.
The claim that this is representative of FLOSS is unfounded, since it only considers a few Java programs and ignores their enterprise support options (which is what you'd use for an enterprise!). I really wish they'd explained what they meant by issues; the problem of tool false positives is very well known, and I don't see that they really addressed that.
The original said: "Government and commercial organizations that leverage open source should use open source applications with great caution. Risk analysis and code review should be performed on any open source code running in business-critical applications...". Um, let's try: "Government and commercial organizations that leverage software should use software with great caution. Risk analysis and code review should be performed on any software running in business-critical applications..."
Re:Java-focused (Score:0)
replying to unmoderate you, sorry bout that...
Did MS get their receipt for this study? (Score:3, Insightful)
This is a weak article about a specific set of open source projects designed to keep CIO's and CTO's from jumping off the Windows turnip truck.
FUD... it's what's for dinner.
On other news.... (Score:1)
On other news studies show that most studies are biased and wrong.
Can you feel that? The universe just imploded.
researchers on studies (Score:1, Insightful)
News Flash: researchers have released a study demonstrating that studies can conclude whatever you want them to conclude.
Re:researchers on studies (Score:1)
Biggest security risk of Open Source Software (Score:4, Interesting)
Re:Biggest security risk of Open Source Software (Score:3, Insightful)
I got that impression too. Have you ever tried calling Microsoft support? By the time you actually get a qualified person to answer your question, you could have received 2 - 3 responses on a OSS project's forum or mailing list.
Another interesting thing that I saw the study fail to mention, there are many OSS projects that clearly state on their web site "This is not yet production quality, use at your own risk" .. yet anyone selling something new would not dare to issue such a warning.
I really feel like the study is rampant FUD that hopes to be viral so that the authors can place themselves in some sort of authoritative role.
I'm actually a little shocked that Network World even ran the story.
Re:Biggest security risk of Open Source Software (Score:0)
Dude, right now they are rolling around rubbing themselves with glee at all the ad revenue that's rolling in as Slashdot visits.
YHBT. YHL. HAND.
Enterprises and governments before the people (Score:2)
"security practices need to improve because open source adoption by enterprises and governments is growing"
So these fortify people think security has to improve not because of the adverse effects it can have on users at large, but specifically because of the adverse effects on enterprise and government.
Oh yea, thats the reason i donated my time the open source community, to help enterprise and government. After all, they are all about helping the people. I never did it to try help the little bloke. /sarcasm
HAHAHA! (Score:2)
Have you voted yet? Apparently, about 80% of the readers of that article "doesn't get it", and votes the opposite of what the article is trying to push across....
it always comes down to.. (Score:1)
The great firewall of china (Score:0)
is supplied by these bastards. Looks like they run a very unethical shop all the way. Bet they're swimming in dirty dollars.
Hmnn (Score:2)
2. Pick 10 OSS projects that fail to follow that definition.
3. Release headline "OSS software a security risk"
4. ???
5. Profit! (From whom though?)
Something interesting to note... (Score:1)
I'm a DBA for a USAF Enterprise Java app. Recently, we underwent a security audit which involved a Fortify scan.
What makes this so interesting is that one of the Fortify findings was the lack of full implementation of Struts in the application, which we're in the process of correcting.
I find it quite funny that they're finding fault with Struts, which they recommend using in their security scans. Ah, Irony. How I love thee.