How open source security flaws pose a threat to organizations


A majority of the open source codebases found in commercial applications analyzed by Synopsys contained security vulnerabilities.

Image: Getty Images/iStockphoto

Applications that use open source code offer a host of benefits, including transparency, flexibility, cost effectiveness and community support. But how do such products fare on security? Though the community-based approach toward open source means that security flaws should be identified quickly, patching those flaws and applying the patches is another matter.

SEE: Top 5 programming languages for systems admins to learn (free PDF) (TechRepublic)

In a report released Tuesday, design automation company Synopsys looked at commercial applications that use open source code to see how they dealt with security flaws.

All of the companies seen in the marketing tech industry, which encompasses lead generation CRM and social media, contained open source code in their applications. Of these, 95% of the codebases had open source vulnerabilities. Some 98% of the codebases in the healthcare sector contained open source, and 67% of them had security flaws.

Some 97% of the codebases in the financial services industry contained open source, with more than 40% found with vulnerabilities. And 92% of the codebases analyzed in the retail and e-commerce sector used open source, with 71% discovered with security flaws.

Many of the security holes were the result of abandoned open source components. A full 91% of the codebases had open source dependencies with no development activity over the past two years, which means no improvements in code and no security patches.

“That more than 90% of the codebases were using open source with no development activity in the past two years is not surprising,” Tim Mackey, principal security strategist with the Synopsys Cybersecurity Research Center, said in a press release. “Unlike commercial software, where vendors can push information to their users, open source relies on community engagement to thrive. Orphaned projects aren’t a new problem, but when they occur, addressing security issues becomes that much harder.”

Outdated open source components also played a role in security flaws. Some 85% of the codebases examined by Synopsys had open source dependencies that were out of date by more than four years. These components are supported by active developer communities that publish security fixes, but the fixes aren’t necessarily being applied by commercial customers.

Open source flaws are on the rise. In 2020, the percentage of codebases with vulnerable open source components reached 84%, a 9% increase from 2019. Over the same time, the percentage of codebases with high-risk vulnerabilities rose to 60% from 49%. Several of the top open source flaws discovered in codebases in 2019 persisted in 2020.

To help organizations protect themselves against open source vulnerabilities, Mackey shared the following tips with TechRepublic:

  • Create an inventory of your open source assets. Reducing exposure to vulnerabilities starts with a full inventory of your open source assets. Ideally, this inventory is refreshed whenever new or updated software is deployed so you can tell if everything is patched properly. Be sure to include the origin of each open source component because that will tell you where to find the right patches.
  • Review how the supplier handles patches. When you acquire a new device or application, review how the vendor issues software patches. If you can’t determine that on your own, reach out to the support team.
  • Consider a different vendor when necessary. If the vendor can’t help you or doesn’t seem to be updating its own products, that means it’s likely time to find a different vendor. If the supplier isn’t keeping up with patches, then security probably isn’t as high a priority as it should be.
  • Review security patches before you apply them. Be sure to completely review any security patch before you apply it. This is especially critical with open source code as the developers don’t know your particular environment and can’t test for it.

Also see



Source link