Real world use, open source risk


Open source code is vital for software development in most organizations, but that doesn’t mean companies have figured out how to use open source without inadvertently introducing vulnerabilities into their code.

A new study by the Synopsys Black Duck Audit Services team has found that vulnerabilities in open source software have been reduced, but many organizations appear to be struggling to keep up with patch status of their open source components. Synopsis Anonymized data from more than 1,200 code bases in companies in 17 different industries revealed that more than 96% of the code bases contain open source software or libraries.

And according to their Open Source Security and Risk Analysis report, 60% of the code bases they audited had at least one vulnerability, up from 78% in last year’s study.

Over 99% of code bases with over 1000 files contain open source components. And in those codebases, there are an average of 298 separate open source components, up from an average of 257 in the previous research. This increase in the number of open source components is significant given that “few companies accurately track the components they use in their code. Most do not have the policies, processes and tools to track the choices made. by their developers, ”the report says.

The use of open source components is so widespread that in 13 of the 17 industries tracked there were more open source components than proprietary components in the code base. This is why, says Tim Mackey, senior security strategist at the Synopsys Cybersecurity Research Center (CyRC), it is encouraging that the report contains good news: “For the first time, there has been a fairly substantial decrease in number of open source vulnerabilities in the code base, ”he says.

Mackey says the reduction stems from a combination of fixed vulnerabilities in open source code and a greater likelihood that the fixed code is in code bases. “Companies are more and more aware of what to do and how to do it,” he explains. That said, the unpatched code remaining in organizations’ code bases is a significant issue.

“Even though we are seeing a decrease in vulnerabilities overall, we are still seeingg a lot of things that are “out of date,” Mackey says, citing an example of the oldest seen by researchers in this year’s study from 1990. According to the report, 43% of the scanned code bases contained vulnerabilities greater than 10 years – an indication that companies are not following open source patches.

Considering the number of open source components in most code bases, just keeping up to date with the open source components of your software can be a daunting task – no matter tracking fork, version, and state. code updates.

“Golden image”

Ed Giaquinto, CIO at Sectigo, says it’s important that open source code is properly inventoried and maintained to avoid introducing security holes in applications. In response to a question from Twitter about how organizations handle open source components in their code libraries, it points to its desktop systems, where “We get notifications from all installations (above and beyond). approved applications) of our endpoint management system. “All servers,” he says, “are built from approved ‘golden images’ with all deviations pre-approved and fully documented.

He says he believes the combination of an automated process and development discipline gives the company 95% knowledge of vulnerabilities and risks. with open source code.

The importance of automation to keep up with open source updates is echoed by Rhett Glauser, vice president of marketing at SaltStack. “With modern scale and complexity, humans cannot effectively ensure continued compliance on their own,” he wrote in a response on Twitter.

Mackey is adamant that knowing the code in a codebase is essential to maintaining the updates and fixes required for secure code. “You can’t patch something you don’t know you have,” he says.

Even with a reliable inventory, it can be difficult to know if the code in your codebase is the latest and most reliable version.

“Regardless of what software asset software you have, you need to create the BOM that includes the source of the code in the first place,” Mackey explains. “A solution to correct something from one source may not work for the same item from a different source. “

And you might not even know that there is one thing that needs to be fixed if the open source world is supposed to be like the commercial software market, where updates are frequently sent to the client and there is regular communication on updates and fixes. “They have to engage with the communities,” explains Mackey. “In the open source world, they don’t know who you are without the level of engagement.”

He recommends having a development strategy in place that includes committing time and resources to participate in the open source communities that develop the code you adopt. This commitment can help in terms of security, he says. “… the transparency of mature and well-adopted free software [open source software] may foster peer review that is difficult to match in terms of ownership [software]. “

Associated content:


Comments are closed.