Open Source Security Top-of-Mind in DevSecOps, but Patching Still too Slow – InApps 2022

Synopsys sponsored this post.

Open source plays a critical role in today’s software ecosystem. All modern codebases are likely to contain open source components and libraries, with open source often comprising 70% or more of the overall code, according to the Synopsys Cybersecurity Research Center’s 2020 “Open Source Security and Risk Management (OSSRA)” report. Paralleling the growth of open source use is the security risk posed by unmanaged open source — 75% of the codebases audited by Synopsys in 2019 contained open source with known security vulnerabilities.

Synopsys recently released a companion piece to its OSSRA report, “DevSecOps Practices and Open Source Management in 2020,” which relates the findings of a survey of 1,500 IT professionals working in cybersecurity, software development, software engineering, and web development. The survey explores the strategies that organizations around the world are using to address open source vulnerability management, as well as the problem of outdated or abandoned open source components in commercial code.

“DevSecOps Practices and Open Source Management in 2020” shows that security and a component’s vulnerability to exploits were top-of-mind to survey respondents — those issues were cited as the top selection criterion when vetting a new open source component.

Unpatched Open Source Vulnerabilities: A Major Source of Developer Pain

It’s clear from the survey findings that unpatched vulnerabilities are a major source of developer pain. Over half — 51% — of respondents said that it takes two to three weeks for them to apply an open source patch. And over 50% of U.S. respondents (40% worldwide) reported that they had delivery schedules disrupted to address open source vulnerabilities. This is likely tied to the fact that only 38% are using an automated software composition analysis (SCA) tool to address open source security issues early in the software development life cycle. Automated SCA solutions allow development teams to identify and track open source in their code, mitigate security and license compliance risks, and automatically enforce open source policies using existing DevOps tools and processes. Organizations not using SCA tools are probably still employing manual processes to identify and manage open source — processes that can slow down developers and force them to play catch-up on security.

It’s important to remember that the security practices employed by an open source development team are likely different than those of an internal team creating custom code. Open source security updates probably won’t be tied to the same sprint cycle or release interval used by a proprietary coding team. The default settings for a given open source component may not align to an organization’s security policies. Identifying the risks associated with open source requires an accurate understanding of all the open source code used in an application, including the open source embedded within commercial libraries.

Starting With a Software BOM

This is the role that SCA tools can perform — starting with a software Bill of Materials (BOM). A comprehensive software BOM lists not only all open source components, but also the versions used, the download locations for each project and all dependencies, the libraries the code calls to, and the libraries those dependencies link to.

The concept of a software BOM derives from manufacturing, where the classic bill of materials is an inventory detailing all the items included in a product. When a defective part is discovered, a BOM enables an auto manufacturer, for example, to identify precisely which vehicles are affected, so it can begin the process of repair or replacement. Similarly, maintaining an accurate, up-to-date software BOM — that includes an inventory of open source components — is necessary for organizations to ensure that their code is high-quality, compliant and secure. And as in manufacturing, a BOM of open source components allows you to pinpoint vulnerable components quickly and prioritize remediation efforts appropriately.

As noted in “DevSecOps Practices and Open Source Management in 2020,” many organizations — especially those in the United States — should accelerate their time-to-patch schedules. A production-grade SCA solution is the key to reducing patching timelines from weeks to days, by providing continuous monitoring for new vulnerabilities and giving guidance on mitigation.

Feature image via Pixabay.