I’m glad to see that Simon Phipps, independent open source consultant and a director of the Open Source Initiative, promote the need to manage components effectively. In his recent InfoWorld article he notes:
“Cyber security is on the national political agenda, but do we really understand what it takes to be secure? Now that enterprise development has become component based, rather than using custom code running off-the-shelf platforms, it’s time for enterprise development to wake up and smell the black hats. They’re targeting your components, not just your servers.”
Simon references our recent survey of 3500 developers, managers and architects that use open source software and our findings about the prevalence of OSS components. Things like:
- Applications are made up of at least 80% components
- Vast majority of organizations have not control over the components they use
- Developers don’t focus much on security
His quote sums up the fact that applications are the predominant threat vector, and with the recent data that today’s applications primarily consist of components it should be no surprise that components can be a significant threat. Why? Well it comes down to economy of scale. If the hacker can exploit a single component, and that component is used in hundreds or thousands of independent applications, hmmm check and mate.
In another article on InfoWorld, Simon addresses Oracle’s approach to Java stating “Oracle’s closed approach keeps Java at risk”. I’m drawn to his comments comparing whether proprietary or open source software (in this case Java) poses a greater risk. This type of editorial has been going on for years – debating the merits of the “many eyes” theory. He also discusses how technical debt in proprietary systems is a more significant issue than can be found in open source. While I understand (though I don’t agree with his thoughts), I think there is a bigger problem here. Since applications are constructed from components sourced from many locations, organizations need to treat software security using supply chain principles. Components of all types need to be managed: internally developed components, open source components, shrink-wrap (COTS), cloud services, you name it.
The issues that are coming to light with Java may vary in technical detail, but their impact is similar to the pervasiveness of Windows ActiveX controls, Adobe PDF files, or other technologies. For those of you old enough to remember, think about the rampant issues found in UNIX’s open source Sendmail program. The point being, this is not an open source vs. closed source debate, this is an application security problem that is rampant across all communities.
Personally I am glad that Oracle is starting to step up to the plate and address these issues head on, but let's not fault the fact that not all Java is open source. And let’s not lead people to believe that by making a project open source, that security is automatically improved. While there are lots of security stars in the open source community, there are plenty of black holes. As a security community, we need to promote better security practices across all development efforts and avoid generalizations that marginalize any one approach.
