The open-source software (OSS) era has been transformative; OSS components have drastically improved development velocity and competitive responsiveness while giving companies access to hitherto unavailable global development communities.
These communities are often comprised of knowledgeable developers with wide-ranging technological expertise and a 24/7 support network enabling companies to steer clear of heavy hiring processes and development of costly centers of excellence. As a result, flexibility and velocity have become the two major pillars of the widely-adopted and fast-growing economy of OSS components; over a third of all enterprise software is now based on open-source code.
But these legions of free-to-use components come with their own multifaceted drawbacks, including but not limited to:
- Lack of support
- End-of-project development
- Potential security flaw exposures and vulnerabilities
- Component obsolescence
- Licensing compliance risks
Additionally, in most cases these components are not owned by any formal entity, yet remain licensed. Depending on the way the component is modified, used and/or distributed, its introduction in the asset could lead to loss of intellectual property (IP), IP disputes based on license incompatibilities, and other legal liabilities.
Against the backdrop of this complex, fast-evolving, exposed, and all-too-often poorly documented OSS environment, companies should implement an OSS strategy at both application and portfolio levels. Such strategies help build governance for how development teams can introduce OSS in their assets while acting as a “control tower” regulating application exposure levels based on OSS usage.
On OSS component version management
When it comes to investigating avenues to improve open-source risk control, version management is often overlooked or altogether the low man on the totem pole. But version management is a crucial part of the multi-layered cake of OSS governance; a new version of the same component could introduce newly discovered security vulnerabilities or, conversely, be much safer to use and deploy. In most cases, multiple versions of the same components will be found in one application. Sometimes, components’ versions are not standardized in the same application and often components can be present in dozens of different versions (up to 203 different versions in our sample of applications). Having multiple versions of the same component inside a codebase can dramatically impact the upkeep of the asset, making maintenance, testing, and deploying applications much more complex and time-consuming.
Mid- and long-term maintenance is also at stake, especially in preventing the application from becoming obsolete. OSS projects are living projects that develop (sometimes even thrive!) and eventually die. Any external piece of software evolves and changes over time as versions branch in development, implying diverse levels of support being covered. Every version has its own particularities, from development changes to new configurations. This can lead to feature disruption and long-term financial benefits or to bugs and crashes that impact and jeopardize brand image and equity. Having uncontrolled versions of OSS components can also impact automated test scenarios that perform functional tests of applications, thus increasing redundant dependency conflicts that contribute to edging away from sound development.
That being said, one could argue that change only needs to be operated with precautions and where needed, meaning it’s important to identify what needs to be added, replaced, or updated, otherwise issues could arise. Additionally, it might not always be possible to upgrade a component based on backwards-compatible features. However, it should be noted that maintaining varied and large license versions of assets is time-consuming and tedious, requiring an intensive approach to preventing attacks. Also, the myth of an application-level-based only management of OSS components needs to be debunked as the open-source strategy also needs to happen at the company level.
Indeed, managing OSS components at the application level (i.e. development level) on a day-to-day basis with code scanning tools is not sufficient to control the level of exposure involved in component introduction due to warning bypasses and lack of process standardization across different teams. Companies should implement a wider strategy at the enterprise level. It should not aim to replace the one already established, but rather act as a complementary solution. Just as the steadiness of the bricks in a wall is as important as its whole architecture. CAST offers an effective and fully-fledged way to implement an open-source risk control strategy that can successfully complement integrated code scanning tools at the enterprise level, thus allowing application owners to support OSS introduction control and get visibility on OSS drawbacks at the portfolio level. The core idea proposed by CAST Highlight is not to control and reduce the development independence of developers, but rather to act as a control tower at the executive level that can support OSS introduction choices, rationalize the usage of components, accelerate security vulnerabilities identification, help developers to understand liability issues, and to decide what components to avoid and why.
SHARE