By Tae Jin “TJ” Kang
As software becomes more sophisticated, organizations of all sizes continue to harness its capabilities to transform their go-to-market strategies and streamline their operations. Whether the software is developed in-house, through third-party vendors or is of the pre-packaged, off-the-shelf variety; businesses are looking to exploit the latest innovations in order to more effectively compete in the marketplace.
With the rise in the value of intangible software-based services and the data collected through those services, companies have invested heavily in security software and systems in order to protect their most important assets. At the same time, DevOps have been given the mandate to implement more and more innovative functionality, as quickly as possible.
This has put the security and DevOps teams at cross-purposes. Getting software provisioned as quickly as possible has not given the security team’s adequate time to ensure full product security. Until recently, ensuring software security has not had the same priority.
That is changing. With new data security and privacy regulations being enacted in some states and the E.U., the C-Suite is pushing hard to have its cake and eat it too. In other words, CEOs, CIOs and CSOs are mandating that software be more capable, developed and provisioned more quickly, while being more hardened against attack.
The current third-party software procurement model makes the previously mentioned C-Suite goals unattainable.
Today’s Third-Party Software Procurement Model
By sourcing third-party code instead of developing all software internally, DevOps teams lower their overall development costs and quickly add innovative capabilities to help their businesses remain competitive. Leveraging third-party software components increases efficiency because it saves months or years of originally required development time.
In fact, the majority of the custom software in today’s enterprise is sourced externally or contains code from third-party vendors that is built using open source code components. Interestingly, the third-party code is almost always delivered in binary format. Though this delivery method protects the third-party development teams’ intellectual property, it makes it almost impossible to accurately account for all open source software (OSS) components in the provided binaries. This problem is compounded when an enterprise platform is updated by different software vendors, over extended periods of time and integrated with off-the-shelf applications.
Why Open Source Components Matter
More than 90 percent of all the software written and in use today integrates some open source code. Such code is used in operating systems, network platforms, and applications. This trend will only continue to grow because, by leveraging open source, DevOps can lower integration costs and quickly add new innovations the C-Suite was clamoring to have yesterday.
Whether software is proprietary or open source, it harbors security vulnerabilities. Because of its transparent and collaborative development model, open source code tends to be better engineered than a comparable piece of proprietary code. And thanks to its openness to extension and reuse, the open source code is used extensively. This means that a security vulnerability in a piece of open source code is likely to exist across a multitude of applications and platforms.
The open source community is becoming increasingly active in finding and publishing new security vulnerabilities. Consequently, known open source software vulnerabilities become a road-map for hackers to target and attack businesses’ systems. Those systems that contain known vulnerabilities that have been left unpatched or unaddressed are likely to fall victim to data loss and theft.
For the past three years, we have seen an escalation in the number and severity of security breaches and data thefts. In many cases, the access point has been hackers leveraging known open source software vulnerabilities. The most costly to date, the 2017 Equifax breach, was due to a vulnerability in Apache Struts that had been known about for months. The Equifax team’s failure to patch the vulnerability in their software was catastrophic.
Implementing Security Checks at Strategic Points & Addressing Them
Businesses will continue to rely on third-party vendors to supply their custom software. IT departments will continue to purchase off-the-shelf software and rely on system integrators for customized software components. DevOps teams, custom software providers, system integrators and off-the-shelf software will continue to leverage the collective, innovative power derived from open source.
Given that these trends are likely to accelerate further, businesses can address a significant number of known open source security vulnerabilities by implementing vulnerability checks at strategic points – and then fixing them.
In a typical platform, it is impossible to know what open source code elements exist in the software. Most platforms are an amalgamation of software developed in-house and by third-party contractors. It has likely gone through several upgrades, and key purchasers and contributors are no longer with the business or the custom software vendors.
Exacerbating the issue is that while custom software makers provide their clients with lists of software components in the code they are delivering, they themselves are unlikely to know all of the open source code elements that exist in their code. This is just as true for the in-house development teams.
A solution is to use a binary code scanner to determine open source code components any time new software is procured or developed. This will give the security team the opportunity to understand what exactly the software is composed of, and gives the DevOps team the ability to address known vulnerabilities prior to deployment while ensuring compliance with all applicable licenses.
Additionally, whether the software development model is waterfall or Agile, it is critical for these scans to be built into the early part of the development cycle. Recognizing the existence of known open source security vulnerabilities in the code is not enough. There must be adequate time to address them through patching and/or other workarounds.
With the constant drive to improve software functionality for every aspect of a business, companies will increasingly rely on third-party software that contains open source code components. Failing to understand and address open source code license issues and known vulnerabilities in newly developed or procured software is a recipe for brand damage and financial loss. Implementing binary scans early in development or procurement and allowing the DevOps teams to have the software corrected will save businesses time and money in the long-run.
About the Author
Tae Jin “TJ” Kang is a technology industry executive and entrepreneur. He is the president and CEO of Insignary. In addition to founding a number of successful technology startups, Mr. Kang has held senior management positions with global technology leaders that include Korea Telecom and Samsung Electronics, among others.Mr. Kang can be reached online at [email protected] and at our company website www.insignary.com
