RSS FeedBlogs

Apache Asserts

Apache Blogger

RSS FeedSubscribe to this blog
About Author
Apache Blogger

Insight from members of The Apache Software Foundation (ASF). Apache powers half the Internet, petabytes of data, teraflops of operations, billions of objects, and enhances the lives of countless users and developers. Established in 1999 to shepherd, develop, and incubate Open Source innovations "The Apache Way", the ASF oversees 150+ projects led by a volunteer community of over 350 individual Members and 3,000 Committers across six continents.

Notable Apache projects include Hadoop, Lucene/Solr,, Tomcat, and the flagship Apache HTTP Server, which powers more than 326 million Websites across the globe.

From enterprise Open Source adoption, industry trends, emerging innovations, and developer and community management issues, the opinions expressed in this blog are those of the individual authors and do not represent the official position of the ASF.



Worrying about the security of open source?

System design and operation are more important than licensing models in security

Article comments

Almost every company today has a presence on the web. These websites are much more complex from yesteryear’s simple set of static pages. Today, a company’s site is a growing collection of support documents, forums, various search tools, user login and management, and more. And I’m only talking about sites like those for car manufacturers or consumer electronics.

Companies that produce web-based services, like Amazon or Salesforce, have a much deeper and much broader website, providing much more functionality to the site’s visitors. Every new piece of functionality brings along the potential for attacks from black hats. Innovative startups and small companies are trying new things, potentially exposing themselves to new functionality, tools, and processes that could be subverted by the black hats.

However, any good security researcher will tell you that your system design and operations are the best way to protect your website, much more than the tools used to implement that design. PCI Level 2 Compliance may be a terribly burdensome process, but once you have been audited to that level, then your confidence in your site security will be much higher.

Similar design processes can apply to any web site: controlling access to data, limiting exposure to subsystems, audit trails, and more. A well-designed system expects and limits its own security vulnerabilities.

The second-most important aspect of creating a secure website is keeping the technology and tools updated. A site will always be subject to “zero day” exploits, but automatic updates will minimise your exposure over time. Once a fix is released, then your site can automatically deploy the change. In some cases, you may need sophisticated deployment processes to release a change, but your monitoring and paging systems should be configured to immediately alert you of new security fixes that need to be deployed.

Whether these services are provided by Microsoft, RedHat, Canonical, or some other software vendor, they should be used by your operations team. You will note that the above two concerns (design, and deployment of security fixes) are completely independent of whether your tools are proprietary or open source.

Empirical research shows that vulnerabilities are about as common to each type of licensing. Proprietary vendors will tell you, “black hats will research open source code to find vulnerabilities”, and open source vendors will tell you, “vulnerabilities can be found and fixed before black hats exploit them”. Each vendor has a stake in the game and will be biased in their answers, but the simplest answer is that exploits are found about as frequently in each type. Choose your packages independent of the licensing model. Choose them based on how those packages fit into your overall design and operations.

Additionally, you will want to consider the maturity of the technology that you choose. That maturity level should be considered in your system design. If a component is relatively young, and not much is known about its potential security vulnerabilities, then you may want to ensure is more strongly isolated. Mature components such as the Apache HTTP Server or Microsoft’s IIS can be deployed with much more confidence.

Rest assured that the licensing of your tools, libraries, and technology has little impact on your site security. Concentrate on your system design and operations first, the implementation and maturity second, and licensing last.

Blog post by Greg Stein

Greg is a Board Member/Director, Vice Chairman, Vice President Apache Subversion, and former Chairman of The Apache Software Foundation. Widely recognised for his work on versioning systems including Subversion and WebDAV, Greg most recently was an engineering manager at Google, where he launched Google Project Hosting. He's currently focused on licensing, developer tools, and community development.



Send to a friend

Email this article to a friend or colleague:

PLEASE NOTE: Your name is used only to let the recipient know who sent the story, and in case of transmission error. Both your name and the recipient's name and address will not be used for any other purpose.

We use cookies to provide you with a better experience. If you continue to use this site, we'll assume you're happy with this. Alternatively, click here to find out how to manage these cookies

hide cookie message