Open source has become a staple for software development in the enterprise, but keeping track of it and maintaining security for it remains an elusive goal, according to a survey of more than 3,500 data architects and developers published today by Sonatype, which provides component lifecycle management products and also operates the Central Repository for downloading open-source software.

In spite what is clearly considerable open-source usage -- for example 80 percent of a typical Java application is now assembled from open-source components and frameworks -- 57 percent said their companies "lack any policy governing open-source usage" and 76 percent indicated lack of meaningful controls related to software typically obtained at no cost though licensed.

When asked about how well their organizations control which open-source components are used in software development projects, 24 percent did say, "We're completely locked down: We can only use approved components." However, 44 percent answered, "Yes, we have some corporate standards, but they aren't enforced," and 32 percent said, "There are no standards. Each developer of team chooses the components that are the best for their project."

When asked about whether their company's open-source policy addressed security vulnerabilities, 24 percent answered, "We must prove that we are not using components with known vulnerabilities." But the remainder of the respondents indicated a weaker effort on security, saying they simply had a policy to avoid known vulnerabilities or their policy does not address security vulnerabilities.

Another survey question asked, "How would you characterize your developers' interest in application security?" To that, 40 percent of respondents indicated it's a top concern and they spent a lot of time on it. But 29 percent answered, "We do what we have to do, but this is the security group's responsibility" and 26 percent said, "We know it's important but we just don't have the time to spend on it." And 6 percent even flat out said, "It's just not something we're focused on."

According to Sonatype, more than 25 percent of the survey's respondents claim to have more than 500 developers in their organizations; some participants in the survey included Netflix, HSBC, FedEx, Disney, Goldman Sachs, Barclays, eBay, GE, Alcatel-Lucent, RSA, Facebook, and LinkedIn, according to CEO Wayne Jackson.

When the 3,500 survey respondents were asked what are the biggest challenges in their company's open-source policy, the main reasons listed were "no enforcement," "it slows down development" and "we find out about problems too late in the process."

When asked who in the organization has primary responsibility for open-source policy and governance, 36 percent ascribed that role to "application-development management," 14 percent to "IT operations," 16 percent to legal, 13 percent to an open-source committee or department, 7 percent to security, 7 percent to risk and compliance and 7 percent to "other."

When asked about whether policy restricted component usage based on specific license or license type, 20 percent said their policy did not. The remainder said "yes," with 29 percent indicating they examined every component but not its dependencies, and 51 percent saying they examined all components and dependencies.

When asked if their organizations maintain an inventory of open-source components used in production applications, 35 percent said yes, 45 percent said no, and the remainder said "yes, for all components but NOT their dependencies."

"Developers are acknowledging that components make up a large part of their application development." While there's still a lot of custom code written in C, for example, for Web applications, he says, the adoption of open source is now a way of life for both the enterprise and vendors, Jackson said.

But challenges remain in adequately tracking open-source usage and any flaws that identified by the open-source community, especially in the large libraries that have become foundations of application development that widely used. "Finding a flaw in a library is not much different than finding a flaw in an operating system," Jackson concluded.