by Casey Yarbrough - Posted 4 months ago
The software of today is built using open
nsource. A 2020 Open Source Security and Risk Analysis
nreport by Synopsys states that
n99 percent of 1,250 audited applications contain at least one open source
ncomponent. Some of the most popular programming languages today, including .NET
nCore and Node.js, are open source, along with Docker and Kubernetes, the two
nhottest applications for containerized applications and workloads.
One particular “chat” application found on
nGitHub has over 1,600 OSS components. It is not uncommon to have 10 or more
ndifferent versions of the same component in various applications across the
nenterprise. Total component count can often be measured in the tens of
nthousands because OSS is cascaded inside other OSS, and what you thought was
none component may in fact be 200.
The first OSS risk to understand is the use of
nvulnerable software components. Just like commercial off-the-shelf (COTS)
nsoftware, OSS can have bugs. Often, these vulnerabilities are addressed quickly
nin a newer version or release. Unfortunately, consumers of the older versions
nmay not be aware of either the vulnerability or the available update. Remediating
nvulnerabilities in your environment may introduce a whole lot of unplanned
nwork, and as a result, delivery can be delayed. With potentially thousands of
nopen-source components in use in an organization, keeping up with all the
nvulnerabilities can require a small army.
The second risk involves OSS licensing. The chat
napplication mentioned above had over 100 different license agreements within
nits internal components. OSS license agreements can be complex, but they
ngenerally fall into one of two groups: permissive and copyleft/restrictive. If
nyou choose to distribute your software, permissive licenses allow you to
ndistribute the OSS without any substantial restrictions on licensing. Copyleft
nrequires you to offer any source code created with that component available
nunder the same licenses. Copyleft means that all the code your developers wrote
nfor your new whiz-bang application needs to be given away for free, but if you
nuse permissively licensed OSS you do not have to do this.
An additional risk arises when using abandoned
nversions of OSS. These versions create problems if they contain security and
nother vulnerabilities, and no one in the community is maintaining
A company needs to understand its software
nsupply chain - what all the components are and where they come from. According
nto the Sonatype's 2019 State of the Software Supply Chain Report, 79 percent of organizations not practicing
nDevOps do not have a software bill of materials. Industry best practice is to
nuse tools such as Sonatype Nexus or JFrog Artifactory to store local copies of
nthe components needed to build applications. Then, if an Internet outage occurs
nand your team is temporarily unable to get to the open-source central
nrepositories, you will have cached copies locally, which supports your business
ncontinuity/disaster recovery plans.
Open-Source Action Plan
ncreating value for your business partners, speed matters. Reinventing the wheel
nby not using OSS only causes delays and lost opportunity costs. Open-source
nsoftware is an accelerator.
Thomas J. Sweet is VP Cloud Services at GM Financial. Sweet is
npassionate about Digital Transformation, DevOps, Agile, Cloud, and attacking
nthe talent shortage head-on by investing in his teams. His views are his own
nand not that of his employer, GM Financial.