Open Source Software Security Begins to Mature

Only about half of firms have an open source software security policy in place to guide developers in the use of components and frameworks, but those that do exhibit better security.

Companies that have an open source software (OSS) security policy in place tend to perform much better in self-assessed measures of readiness. They also tend to have dedicated teams in charge of driving software security, according to a survey published on June 21.

The survey — published by software-security firm Snyk and the Linux Foundation on Tuesday — found that seven out of 10 companies that have an OSS security policy in place consider their application development to be highly or somewhat secure. Comparatively, just 45% of companies that failed to institute such a policy consider themselves at least somewhat secure.

Open source software has significant benefits for application development, but companies also have to recognize and prepare for the downsides, says Matt Jarvis, director of developer relations for Snyk.

"While open source is a proven mechanism for innovation and building high-quality software, it's becoming somewhat a victim of its own success in that its ubiquity has made it a target for supply-chain attacks," he says. "Companies need to build a stronger understanding of both the mechanisms by which open source works, and this includes governance as well as code, and strengthen their approach to supply chain management through adopting developer-first security tooling and methodologies."

Smaller Firms Lag in OSS Policies

Overall, only about half of firms have an open source security policy in place to guide developers in the use of components and frameworks, with a greater number of small companies, 60%, either having no policies or not knowing whether they have one, according to the report.

The economics of security tends to reduce the priority of creating a formal policy for startups and smaller firms, the report states.

"Small organizations have small IT staffs and budgets, and the functional needs of the business often take precedence so that the business can remain competitive," the report states. "Lack of resources and time were the leading reasons why organizations were not addressing OSS security best practices."

Source: "Addressing Cybersecurity Challenges in Open Source Software" report

Different programming languages also brought different security considerations, according to the study. Applications written in .NET, for example, had the longest average time to fix flaws at 148 days, followed by JavaScript, Meanwhile, those written in Go had the speediest time-to-patch, and were typically fixed in a third of that time, or 49 days.

JavaScript Dependencies Abound

JavaScript application have the most dependencies — an average of 174 per project, according to Snyk — or about seven times the language with the fewest dependencies, Python, which averages 25 per project.

While large transitive dependency trees can result in circuitous paths to fix vulnerabilities, having a large number of dependencies is not necessarily a disadvantage, if an organization has ways to track the relationships between projects, says Jarvis.

"JavaScript packages tend to have a smaller scope than other ecosystems, so whilst there are more of them, there may be less code to audit for potential weaknesses," he says. "The most important issue is to understand the dependencies which you are using, particularly the transitive ones brought in as dependencies of dependencies, and that comes down to using the appropriate security tooling to scan things."

However, the data also shows that different languages tended to have different severities of flaws. The average project written in Java, for example, had more than 47 high-severity vulnerabilities and 28 medium-severity vulnerabilities, much higher than the second-ranked JavaScript, which had an average of 18 and 21 vulnerabilities, respectively. However, Python had the most low-severity vulnerabilities, an average of 20 per project.

"There are a lot of factors at play in the data — the complexity of projects, the number of developers, and the popularity will all have an impact on the number and types of vulnerabilities," Jarvis says. "Many developer eyes on projects that are extremely popular are likely to surface more bugs."

Automation = Security Maturity

Despite the importance of identifying vulnerabilities in dependencies, most security-mature companies — those with OSS security policies — rely on industry vulnerability advisories (60%), automated monitoring of packages for bugs (60%), and notifications from package maintainers (49%), according to the survey.

Automated monitoring represents the most significant gap between security-mature firms and those firms without a policy, with only 38% of companies that do not have a policy using some sort of automated monitoring, compared with the 60% of mature firms.

Companies should add an OSS security policy if they don't have one, as a way to harden their development security, says Snyk's Jarvis. Even a lightweight policy is a good start, he says.

"There is a correlation between having a policy and the sentiment of stating that development is somewhat secure," he says. "We think having a policy in place is a reasonable starting point for security maturity, as it indicates the organization is aware of the potential issues and has started that journey."

Source