How has the recent turmoil within the OpenAI offices changed your plans to use GPT in a business process or product in 2024?
Increased uncertainty means we are more likely to evaluate alternative AI chatbots and LLMs.
No change in plans, though we will keep an eye on the situation.
With Sam Altman back in charge, we are more likely to go all-in with GPT and LLMs.
What recent turmoil?
DevOps / Open Source / Security

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

An analysis of the Synopsys Cybersecurity Research Center’s 2020 Open Source Security and Risk Management (OSSRA) report.
Dec 17th, 2020 9:20am by
Featued image for: Open Source Security Top-of-Mind in DevSecOps, but Patching Still too Slow

Synopsys sponsored this post.

Tim Mackey
Tim is a principal security strategist within the Synopsys CyRC (Cybersecurity Research Center). As a security strategist, Tim applies his skills in distributed systems engineering, mission-critical engineering, performance monitoring, large-scale data center operations, and global data privacy regulations to customer problems. He takes the lessons learned from those activities and delivers talks globally at well-known events such as RSA, Black Hat, Open Source Summit, KubeCon, OSCON, DevSecCon, DevOpsCon, Red Hat Summit, and Interop. Tim is also an O'Reilly Media published author.

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.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.