Downloading open source is not a risky endeavor in itself. Organizations run into issues, however, when they download pre-patched versions of open source projects for which they have no automatic update mechanism, such as Red Hat and Novell for Linux. If you don’t know you have an open source project in your application, how would you know whether it needed a patch or even where to download it? How would you monitor it down the line for future bugs and vulnerabilities?

Unlike commercially supported third-party products, only one out of every 10 open source projects has a vendor offering commercial support.[2] As a result, organizations that use OSS components are largely “on their own” when it comes to patches, upgrades, or vulnerability assessments. The open source community is both committed and equipped to constantly improve upon their projects. The large number of community members work to provide updates to vulnerabilities often within hours of their revelation. If you aren’t patching OSS vulnerabilities in your code base, you’re not taking advantage of the robust support the open source community offers – essentially leaving half of the value of open source on the table.

Closing the Application Security Gap
Software security vulnerabilities are often caused by defects in specification, design, and/or implementation. It is becoming very clear that decisions made during the software development life cycle significantly impact the likelihood of security incidents and the success in responding to them.

According to research by Gartner and Symantec, close to 90% of software attacks are aimed at the application layer.[3] Once application vulnerabilities have been exploited, a company is at risk not only for the potential loss of vital customer or company data, but may even be open to additional attacks against other systems within the company’s network.

Most organizations believe they have adequate application security solutions in place such as firewalls, web-based authentication, intrusion detection, and identity management systems. Though these are important parts of an overall security arsenal, these solutions secure only the perimeter. None focus on securing applications from the inside out.

As engineering departments adopt richer, interactive environments – especially as they embrace Web 2.0 capabilities – they become even more susceptible to vulnerabilities (i.e., cross-site scripting). Unknowingly introduced by developers via OSS, vulnerabilities are easily exploited by knowledgeable outsiders. With Web 2.0 as the new software ecosystem, relying on perimeter controls alone is grossly insufficient. Externally facing mission-critical software applications must have security features encoded in from the start.

Gartner notes that Web 2.0 offers a collection of lightweight technologies and techniques that simplify the development of sophisticated code and content. Yet, technology light-weightedness, ease of use, and user friendliness come at a price – namely, lack of security and neglect for protection of IP.[4]

Application security cannot be adequately addressed until application development and security teams agree to work together to understand and manage security. Neither role benefits from the existence of silos. For instance, quality assurance and virus prevention are not mutually exclusive in application development.

Development teams commonly (and mistakenly) believe that security is solely the responsibility of security professionals. For many companies the development process has focused only on designing, architecting, coding, and testing applications to ensure that they fulfill functional requirements. With today’s strained budgets and resources, applications are not adequately tested for coding defects, vulnerability assessment, or conditions that could leave the applications exposed to external attacks.

Simultaneously, the mandate for security teams has been focused on defending the perimeter against external attacks. They have made significant investment in firewalls, web-based authentication, intrusion detection, and identity management systems. Security professionals are not coders and often don’t realize that decisions made during the development process have significant material impact on the deployed applications they are mandated to protect.

Therefore, neither team can adequately cover application security problems alone. Hackers, who often know coding methodologies better than security professionals and know security better than programmers, are exploiting this gap.

How to Eliminate Undocumented Code
It is the responsibility of security, development, and IT teams to ensure that their developers use processes that produce secure software. Working together, these three departments can effectively insert application security for open source into the overall security strategy by:

• Conducting code-level security reviews in addition to penetration tests for their internally developed code before deployment
• Insisting that code-level audits be conducted by outsourced development and business partners
• Ensuring that all other third-party code included in their software applications is identified and tracked for security flaws and updated version information
• Ensuring that internally developed applications have adequate checkpoints that enable thorough audit trails
• This means that development organizations must continue to acquire the high level of security expertise required, identify processes for producing secure software, adopt them, and consistently use them when they produce, enhance, maintain, and rework the software that supports a strong application infrastructure.
• Enacting best practices for open source use empowers organizations to use it to their best advantage as a solution for driving continual innovation and growth.

An application security for open source strategy requires processes, training, and tools. It also requires a partnership between security and engineering teams. The nature of the partnership is based on two key elements. The first element is an accurate inventory of open source components in use provided by the engineering team. This may be more challenging than it appears, since most large applications have had many different developers over a period of years, each with the potential to utilize open source components. The second element includes a system, managed by the security team, to associate the open source projects in use with known and published vulnerabilities. With this new awareness, coupled with robust new tools for open source management, both elements can be addressed and the gap can be easily bridged.

Engineering managers should be able to confidently answer the following 10 key questions to ensure that both teams are working together to secure deployed applications:

1. Where is our OSS inventory, including all versions in use?
2. How accurate is the information?
3. Where does the OSS we use reside inside our code base?
4. How are we using the OSS?
5. Are there vulnerabilities within the versions we’re using?
6. Are we on the latest version – if not, why?
7. Have we paid for commercial support for all the OSS projects in our code base?
8. If not, who is responsible for monitoring and upgrading to newer versions?
9. What is our OSS use policy and approval process?
10. Are we compliant with and enforcing our own policy?

Immediate Action Items for Your Security Team

1. Begin monitoring open source project sites and other sources for vulnerability alerts, based on existing OSS inventory
2. Assess relevance of alerts against internal usage
3. Make recommendation for version or patch upgrade as relevant

The widespread availability and use of open source has dramatically changed the nature of software development projects with substantial benefits including reduced development time and cost. This strategy brings with it, however, the possibility that a large portion of a software product or internal application could be comprised of undocumented content. With the increasing requirement for protecting information data, the security of core applications is essential. An application security strategy requires processes, training, and a spectrum of solutions. It also requires a partnership between security and engineering teams that has, until recently, been neglected. With new awareness and open source management systems, the gap that once existed can be easily secured.

References

1. IDC, “Open Source in Global Software: Market Impact, Disruption, and Business Models.” Doc# 202511, July 2006.
2. Based on Palamida research conducted February 29, 2008 - March 4, 2008, examining support structure for 3,168 popular open source projects.
3. Briggs, Linda L. “Application Security Comes Under Attack.” Application Development Trends, June 2006.
4. Gartner, Inc. “The Creative and Insecure World of Web 2.0.” February 2008.