Extending a Secure SDLC to Remediate Open Source Security Issues

The challenge: If a vulnerability can’t be found, it can’t be patched

As with many organizations in the business of building software, Blue Yonder’s portfolio of 100+ applications contains a mix of custom-built codebases and commercial and open source components. Analysts such as Forrester and Gartner note that over 90% of IT organizations use open source software for mission-critical workloads and that open source components often compose up to 90% of some applications.

While the number of vulnerabilities in open source is small compared to proprietary software, over 7,000 open source vulnerabilities were discovered in 2018 alone. Over 50,000 have emerged over the past two decades. Of the codebases reviewed by the Synopsys Black Duck Audit Services team in 2018, 60% contained at least one open source vulnerability. Over 40% contained high-risk vulnerabilities, and 68% contained components with license conflicts.

From a license compliance perspective, whether an open source license is one of the most popular licenses or a one-off variant, unless an organization is aware of the rights, obligations, and restrictions of using a specific open source component, they can’t be sure whether they comply with those obligations. Noncompliant organizations could theoretically lose rights to their proprietary code or call into question the ownership of their IP.

From a security standpoint, all software, be it proprietary or open source, has weaknesses that may become security vulnerabilities. Only a handful of open source vulnerabilities—such as those infamously affecting Apache Struts or OpenSSL—are ever likely to be widely exploited. But when such an exploit occurs, the need for open source security management becomes front-page news—as it did with the Equifax data security breach of 2017.

A report by the U.S. Senate Permanent Subcommittee on Investigations noted that Equifax’s lack of a complete software inventory was a major contributing factor to its massive security breach. “Equifax lacked a comprehensive IT asset inventory—meaning it lacked a complete understanding of the assets it owned,” the report states. “This made it difficult, if not impossible, for Equifax to know if vulnerabilities existed on its networks. If a vulnerability cannot be found, it cannot be patched.”

Many companies don’t formally manage their developers’ use of open source, and few can produce an accurate, up-to-date inventory (also known as a bill of materials, or BOM) of open source components, licenses, versions, and patch status. In consequence, these organizations open themselves and their customers to risk. “Our open source management prior to Black Duck was done primarily through spreadsheets, developer honesty, and with our providing basic guidance on using permissive rather than viral licenses,” says John Vrankovich, Principal Architect at Blue Yonder.

“We have over a hundred products, with each of those products themselves having hundreds to thousands of different open source components. A decade ago, we had little concept of identifying and understanding open source security vulnerabilities in our BOM. The move to Black Duck was to address our not knowing about open source security issues. We recognized that we needed a solution to ensure we were tracking and managing open source and commercial components as part of our overall software security initiative.”