IDC Research has called the use of open source “the most significant, all-encompassing and long-term trend that the software industry has seen since the early 1980s.”  The study also revealed that open source was being used by 71% of worldwide developers, and was in production at 54% of their companies. Although upper management has only recently signed off on its use, developers have long understood that open source is the fastest (and cheapest) path to software innovation.
For good reasons, developers have been coding around OSS components for many years – it’s extremely accessible, it’s collaborative, and it’s free. While OSS offers clear benefits to application development, it also poses unique challenges to application security.
The sheer size of an application code base coupled with the number of contributing developers makes it nearly impossible for companies to get accurate documentation of OSS inventory and usage. Without this information, security vulnerabilities, copyright violations, and license requirements often go unnoticed. Undocumented code represents a significant gap in application security coverage that can lead to:
Unlike commercially supported third-party products, only one out of every 10 open source projects has a vendor offering commercial support. 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. 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.
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:
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:
Immediate Action Items for Your Security Team
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.
© 2008 SYS-CON Media Inc.