The survey saw record participation from more than 3,500 developers, architects and managers across all industries, company sizes and geographic regions -- making it the largest, most comprehensive survey of its kind.
Findings show that organizations of all sizes have embraced open source components as the building blocks of modern software. But, the lack of internal controls and a failure to address security vulnerabilities throughout the software development lifecycle threatens the integrity of the software supply chain and exposes organizations to massive, unmanaged risk.
Open source component usage has exploded. In 2012, Sonatype's Central Repository registered eight billion component downloads, an 800 percent increase in activity since its inception. Nearly 80 percent of the organizations surveyed report components found in Sonatype's Central Repository to be important or critical to their development efforts.
An overwhelming 86 percent of those surveyed believe their applications are at least 80 percent open source with the remaining 20 percent custom components and code, illustrating a dramatic shift in how mission-critical software is built. This paradigm shift is forcing companies to rethink how they manage risk in the age of agile, component-based software development.
While reliance on open source components increases year-over-year, limitations on the visibility, control and management of their use continues to be a problem. Of those large organizations surveyed (companies with > 500 developers), an astonishing 76 percent have no control over what components are being used in software development projects and even more alarming is that 65 percent don't maintain an inventory of components used in production applications.
Like operating systems or database, open source components represent a rich attack vector for hackers to exploit given their commonality across organizations and applications.
Despite the widespread acceptance of component-based development, 57 percent of those surveyed lack any policy governing component usage. Organizations with open source policies in place share that enforcement is a challenge and not a top priority.
Developers cite the biggest problem to open source policy is that it slows development, expectations are unclear or policy is unenforced, and that problems are found too late in the development lifecycle.
The lack of policy enforcement may be due, in part, to confusion over who owns or is responsible for monitoring and managing open source usage. No single, centralized authority governing open source emerged in the organizations that indicated having a corporate policy. Other contributing factors are that large organizations often are unaware that open source is even being used.
Open source standardization is seen more frequently in organizations with less than 500 developers -- but that doesn't mean large enterprises aren't using open source frameworks and components. For developers on large teams, 44 percent say they are standardizing on an open source development infrastructure stack, with 33 percent stating, "It's not our corporate standard, but tons of people use it."
In addition to gauging how development teams embrace open source components, the 2013 survey sought to determine how developers, architects and managers balance the need for speed with the need for security. For large enterprises ( > 500 developers) more than half shared that developers don't focus on security at all.
Nearly 20 percent of this group shared they know application security is important but they don't have the time to spend on it, while almost one-third deferred responsibility to the security and risk management group entirely.
Even organizations with an open source policy are doing very little to prevent security vulnerabilities from creeping in. Only 25 percent of respondents, or one in four organizations surveyed, must prove they're not using components with known vulnerabilities. But due to the high volume of dependencies for each component (often tens or 100s) and the frequency of updates and changes (a typical component is updated four times per year), all organizations concede it's near impossible to monitor and maintain accurate component intelligence.