Securing Open Source, Part 2:
Software Composition Analysis comes into its Own

In part 1 of this report, we examined the drivers behind the adoption of open source software, which is redefining the nature of software development and operational deployment technologies such as containers and container orchestration. We identified a number of the risks and implications of open source adoption, from security and licensing to the complexity of management inherent in these issues.

In part 2, we take a look at the attributes of software composition analysis (SCA), the technology segment that has arisen to address a number of these risks for organizations embracing the open source revolution.

---

The 451 Take

Software composition analysis is becoming an increasingly visible aspect of due care for security and license risks in open source software. It is also a recognition of the complexity organizations face in getting a handle on these challenges – and an acknowledgement that a need exists for tools and technologies to help. In 451 Research's 2018 Voice of the Enterprise – Information Security: Workloads and Key Projects survey, nearly half (44%) of all respondents were either using software composition analysis (in a pilot or proof of concept of SCA) or planning to deploy it in the next 12-24 months. Of these, 42% expect to increase their spend on SCA in the next 12 months; one-sixth of this group expects that increase to be significant.

In this report, we explore the key values of managing security vulnerabilities, license complications and administrative complexity that are driving the adoption of SCA, as well as the increasing breadth of the technology – in support for languages and implementations, in the scope of coverage from development to operations, and in the range of integrated tools across the DevOps spectrum. We conclude with a look at example vendors, and what we expect in SCA going forward.

---

The Rise of SCA

The history of SCA traces back to a number of threads – from the lessons learned by private companies and their founders, who personally endured the pain of manually accumulating an inventory of software components and their liabilities, to OWASP (the Open Web Application Security Project, administered by The OWASP Foundation community), which in 2013 added 'using components with known vulnerabilities' to the OWASP Top 10 list of security issues facing web applications.

This addition was significant in that many policy and enforcement initiatives either directly require or indirectly influence organizations to address the OWASP Top 10 as part of their fundamental security measures. Nothing, however, has driven the rise of SCA like the emergence of recent high-profile security incidents related to open source vulnerabilities, from Heartbleed to the Equifax breach of 2017.

The integration of SCA capabilities with widely adopted repositories helped spur its adoption in some quarters; for others, the value of license compliance remains strong. More recently, a focus on security has shaped early players, as well as more recent entrants, many of whom also emphasize a more seamless approach to integration with popular DevOps practices and tools.

Today, SCA revolves around three fundamental realms of capability:

• Identifying and resolving security vulnerabilities in the open source components on which software is increasingly built.
• Addressing the impact of open source licenses on software projects.
• Managing the range and complexity of SCA involvement across the software spectrum, from mitigating issues in development to integrating with a wide range of modern development and IT operations toolsets and resolving exposures in operational environments. An emphasis on automation in concert with these toolsets adds to current market drivers.

Inventory, Integration, Administration and Coverage

One of the first and most fundamental values provided by SCA is the ability to identify and track all the open source software (OSS) in your portfolio. The accessibility of OSS is one of its primary values, but that same accessibility comes with risks. Licensing issues and exposure to security vulnerabilities inherent in that software are two of the best known (we will get to those in more detail shortly). But before any organization can assess these exposures, it needs to know just how and where these exposures may exist – and that requires an accurate and up-to-date inventory of OSS assets.

Software composition analysis can gather details on component inventory from a wide variety of sources to develop a bill of materials (BOM) for specific projects, or to provide a comprehensive view across a number of projects to help organizations manage multiple (sometimes interrelated) and often complex software efforts.

Repositories are among the most common sources of this data, with SCA tools often connecting directly to popular resources, including GitHub, package managers such as npm, open source projects such as Apache Maven and private repositories. Git and GitHub, in particular, have become an increasing focus of such efforts, representing an aspect of the larger trend toward 'GitOps,' which refers to using Git and GitHub pull requests as a management tool for software deployment and infrastructure provisioning. SCA can also police check-in/check-out processes to monitor the integrity of components and status of policy compliance. It can also enforce policy on the incorporation into projects of components that don't comply.

SCA is also becoming an aspect of capabilities being embraced by vendors that are advancing wider initiatives to coordinate pipelines of tools – both open source and proprietary – in a more coherent approach to DevOps automation and process management. Development projects and individual organizations may vary widely in the range of languages, implementations and toolsets they employ. To keep up with these dynamics, vendors increasingly widen the aperture of support. Even if known as a particularly recognized advocate of ecosystems, such as Java, many vendors today tout their support not only for multiple languages, but for multiple tools across the automation spectrum that reflect the distinctive preferences of each development and operational team.

SCA tools can deliver findings at multiple stages of a project – from initial source development to compiled binaries; output artifacts; and even operational deployments of containers, microservices and 'serverless' environments. While integration with specific tools is common – for example, integration with Jenkins helps prevent the incorporation of problems at build time – an emphasis on integrating seamlessly with tools throughout the DevOps spectrum has become increasingly evident.

At the development end of the spectrum, this reflects a 'shift left' trend that seeks to empower developers more directly for better software security and quality outcomes. These efforts align with closely related integrations, such as application and software security testing, as well as with source code analysis available to the individual developer that provides the ability to check one's own code before adding it to or changing a specific project. Here, SCA can, for example, block the incorporation of vulnerable components into a development project; prevent their release into source code management when not compliant with, for example, version control policy; prevent or alert on builds before they are executed; or restrict the inclusion of noncompliant components into operations.

As these examples suggest, 'shifting left' doesn't mean that SCA is exclusive of the operational end of the DevOps spectrum. Coverage of containers has also become a more frequent aspect of SCA, given the potential to include exposures introduced from components that go into the makeup of applications and microservices, and the highly portable software platforms on which they are increasingly deployed. Guarding against building known vulnerabilities into these environments is only part of the use case. When newly discovered vulnerabilities affect a given composition of containers or microservices, organizations will want to be aware of how they affect their own deployments, so they can remediate the existing resource complement and take appropriate action in the operational environment.

SCA is also now looking toward 'serverless' environments, where providers enable organizations to expose only the functionality specific to an event-driven service, without the need to provision or manage the underlying platform. The software that goes into this functionality may be composed of underlying components beyond custom development – and those components fall within the scope of SCA.

When SCA technologies present their insights, they must do so in a meaningful way. Among the questions they must answer: Do identified issues pose significant risk? Can these issues be ranked according to severity or impact in such a way as to facilitate more systematic management? Many tools today not only seek to answer these questions, but also to provide guidance on how best to answer them. SCA allows organizations to define policy and policy templates for specific issues, including the ability to whitelist acceptable components and software versions; alert or respond to security issues based on impact; and address contractual, licensing or other considerations.

Insights are not always presented only to human users alone, however. Feeding the findings of SCA directly into automation and integration with broader toolsets – from IDEs to operations management – is part of the overall trend to increase the level of automation in DevOps pipelines and further accelerate agile development and operations.

Security Vulnerability Recognition and Remediation

One of the key values of SCA – and arguably the one most directly relevant to software security – is the ability to identify vulnerabilities in software components, modules and projects on which development efforts are often built or based. While these components may include proprietary or closed elements, the emphasis of the SCA market is largely on open source, given the focal role it plays in modern software, and the visibility and impact of open source vulnerabilities.

Vulnerability inventory has long played a role in security, such as in the development of the US National Vulnerability Database, which provides a central clearinghouse for identifying specific vulnerabilities and tracking their severity, exploitability and impact. But to be listed in the NVD, a vulnerability must have already been researched and analyzed. Attackers, of course, aren't limited to the exploit of these issues – a 'zero day' vulnerability is, by definition, one that only becomes known when an attack for it appears. Independent research into software vulnerabilities thus becomes a differentiator for SCA providers that can give their customers early and actionable warning of such exposures.

Increasingly, this insight is also accompanied by guidance on how to resolve the exposure, whether through upgrading to a version in which the issue is resolved or illustrating how an organization can modify its software, if an upgrade is impractical or infeasible. This guidance can include specific implementations of source code, but these are often limited to the most serious issues, given the sheer scale of potential vulnerabilities across the breadth of modern software.

One of the ways that vulnerabilities often appear is through software dependencies, and these dependencies may appear at multiple levels of depth, given how one project may be built on another, which in turn is built on others, and so on. Dependency analysis has recently become more visible, and not only among SCA players per se. GitHub itself, which in early 2018 'acqui-hired' the Y Combinator-backed AppCanary vulnerability analysis team, introduced the Dependency Graph in late 2017, which provides the ability to track dependencies throughout software projects. Shortly thereafter, GitHub also introduced security alerts for owners and administrators of public repositories (and private repositories for those who have opted in to vulnerability detection) concerning public vulnerabilities in components such as Ruby gems, npm and Python packages.

One of the advantages of dependency tracking is the ability to locate and identify vulnerabilities, even if organizations are not aware that vulnerable components are part of their software landscape. This can help to prioritize risk and exposure, as well as help determine a proper approach to remediation, whether via upgrade, modifying existing sources, or configuring access and use. Automating the kickoff of processes such as policy exception and approval workflows are other ways in which SCA can help organizations resolve issues without disrupting the development or operation of high-priority business functionality.

Another aspect of vulnerability management in SCA has appeared in a discernment of effective exposure. A component vulnerability that isn't actually used in the implementation of a dependent project may be effectively dormant – present, but not posing a risk since it cannot be accessed, or an exploit would not lead to compromise since the functionality is not in use. These distinctions must be reasonably sure that exploit would, in fact, be a dead end, and not inadvertently reveal an otherwise unsuspected exposure.

This capability has become more evident in SCA – and not just as a means to help rein in false positives and achieve the always sought-after goal of identifying exposures that most urgently require action. One of the often-touted values of SCA is the ability to halt a process that would result in the incorporation of vulnerabilities or other issues that would violate policy. But halting an agile pipeline can be one of the worst things that could happen to a modern organization – it could result in disruption of downstream expectations, significant cost and lost business opportunity. Issues that require immediate resolution must therefore be distinguished from those that do not necessarily threaten software production and operations, or the business itself. SCA can also automate the initiation of less disruptive processes to resolve issues as they arise.

Resolving Licensing Concerns

The spectrum of licenses encumbering software can be much broader – and their intersections, conflicts and overlaps more complicated – than many organizations suspect. In part 1 of this report, we noted that the Open Source Initiative listed no fewer than 83 open source licenses on its website. Organizations and developers alike may assume – or declare – that software conforms to a particular license. In fact, it may be governed by additional licenses, or another license altogether, and there may be not only conflicts among these licenses, but disconnects between the declared license(s) and the way the software is actually used.

As if that weren't complication enough, software products may in turn be utilized by additional organizations in subsequent developments – both inside an enterprise and third parties. Licensing conflicts and issues may dog software well beyond an initial implementation – and may come back to haunt any organization in the sequence of development that built on erroneous assumptions. This can be a particular bedevilment in cases such as mergers and acquisitions, where an acquiring organization may assume the obligations of the target – including proper licensing of software. SCA thus becomes part of due diligence to deliver a thorough inventory of the license conditions and obligations associated with the intellectual property of an acquisition, which factors into the liabilities, assets and opportunities acquired.

SCA can confirm that software use agrees with the declared license, and identify when use varies from that license. It can analyze licensing across all components of software to identify the scope of licenses that apply; identify conflicts; and (as with other aspects of policy noncompliance) alert on issues, recommend remediation or automate response.

Example Vendors

The following is a sampling of vendors offering software composition analysis, listed in alphabetical order. In addition to pure plays, these example vendors include those that have developed or acquired SCA to expand software supply chain management or an application and software security portfolio. In the latter case, SCA particularly aligns with static analysis of source code.

• CA Technologies acquired SourceClear in early 2018 to anchor its SCA strategy and align with the assets of its 2017 Veracode acquisition in application security – particularly its static analysis capabilities for source code testing. That alignment is further reinforced through SourceClear's founder, Mark Curphey, who was also the founder of OWASP. SourceClear emphasizes its investment in analytics, pointing to its Security Graph Language, which it claims is the industry's first domain-specific language designed to identify security issues in open source code. SourceClear uses a call-graph to trace a project's use of an OSS library to a specific line of code, which helps it identify when software is invoking a specific vulnerability. SourceClear is a fully SaaS offering, supporting multiple languages and integrating with a number of package managers and CI/CD tools. Features include license risk analysis, real-time vulnerability detection, analysis of vulnerable methods, a library catalog and a CI/CD agent. Tight coupling with DevOps toolchains enables SourceClear to control pipelines. Its analysis of vulnerability impact enables organizations to consider alternative approaches to remediation that don't require failing a build, which helps improve security's support for agile objectives.
• Flexera (fka Palamida) was one of the original companies to provide software license and compliance scanning for open source software. When it was Palamida, the company was primarily focused on code scanning and management, with some M&A vetting business, as well. Prior to its acquisition by Flexera in 2016, the company had more formally made security a focus by specializing in scanning open source software for vulnerabilities, in addition to license and other information. Flexera still offers software composition analysis and license optimization, but its focus goes well beyond open source software to include management of cloud, vulnerabilities, patches and edge computing. Flexera was among the first code management vendors to embrace security aspects of software releases, and the company still offers application security software. Flexera sells software and services, including consulting and training, and specializes in software supply chains for certain industries, including financial services, education, government, manufacturing and utilities. In 2015, Flexera acquired Secunia Research, which specializes in vulnerability intelligence, provides technology for vulnerability assessment across multiple platforms and helps organizations remediate software vulnerabilities. Secunia provides verification, testing and validation for Flexera's software vulnerability research.
• Snyk is a relative newcomer to SCA, but has made a splash based in part on its approach to reaching the open source development community, as well as its approach to vulnerability remediation. Snyk's offering is directly accessible from community repositories such as GitHub or npm, via API or from the Snyk website. Assessment may be as simple as validation of every GitHub pull request for newly introduced vulnerable packages, continuous scanning of repositories for known vulnerabilities, scanning a local project using a simple command line interface, or as part of continuous integration. Vulnerabilities are correlated to dependencies mapped by Snyk, as well as remediation guidance, which may suggest available upgrades or patches when upgrade is infeasible. Snyk for Enterprise offers these capabilities, plus dashboards for reports across an organization, license management, groups (including single-sign-on support) and issue-tracking through widely accepted tools such as Jira and Slack, as well as API-based access for custom enhancements and automation. Founded in 2015, the company is based inLondon with offices in Tel Aviv and Boston.
• Sonatype is among the early entrants in SCA. As an original core contributor to Apache Maven and curator of the Maven Central Repository, the company has strong ties to developers in the open source community. Today, Sonatype's products extend across the entire software supply chain and enable organizations to implement different levels of automated open source governance. Founded in 2008, the Fulton, Maryland-based company is now known for its support of all popular OSS languages and integration into leading DevOps tools. The Sonatype Nexus portfolio consists of three key anchors: Nexus Lifecycle, which helps organizations integrate intelligence, policy and control across a wide range of DevOps automation tools and processes; Nexus Firewall, which automatically enforces OSS policies by blocking undesirable OSS components at the earliest point in the development lifecycle; and Nexus Repository, which provides centralized management for OSS components, containers, build artifacts and release candidates.
• Synopsys gained a substantial share of the SCA market when it acquired Black Duck Software in 2017 to bolster its Software Integrity Group's application security portfolio. Prior to the addition of Black Duck, Synopsys' SCA offering, formerly known as Protecode, was somewhat limited, but maintained differentiation through its ability to analyze binaries, which is valued by organizations that don't have access to source code or may only see binaries late in the software supply chain. Black Duck, however, has broad penetration of SCA overall. Today, Black Duck by Synopsys includes the Protecode binary analysis technology and offers a broad range of capabilities, including open source software inventory, vulnerability mapping, identification and management of license and quality risks, open source risk policy management, and proactive alerting for newly detected security threats. Black Duck Hub provides centralized management for these capabilities, while OpsSight reflects a recent expansion of capability for assessing containers and alerting on newly discovered container vulnerabilities. Black Duck provides coverage for multiple languages and integrates with a wide range of DevOps tools, such as IDEs, CI tools and code repositories, as well as the Kubernetes and OpenShift container management platforms.
• WhiteHat Security acquired Infrared Security's static application security testing technology in 2011, and today offers both static (SAST) and dynamic (DAST) application security testing. Noting that an application is only as secure as its weakest elements, WhiteHat sees the high proportion of open source components in modern applications, and offers SCA either stand-alone or integrated with SAST in its WhiteHat Sentinel Source Standard and Sentinel Essentials offerings. Both types of tests are invoked from, and results delivered to, the WhiteHat Sentinel platform, which unifies assessment and analysis. The SCA functionality offers reporting, targeted at developers, who require detail on affected components for identification of vulnerabilities and appropriate remediation, in addition to high-level trend reports that cater to senior IT and security executives, as well as to software project managers.
• WhiteSource became an early entrant in SCA – advancing a concept of continuous open source component management and real-time detection of vulnerability and licensing issues whenever code is built, committed or utilized – in order to overcome then-current limitations of approaches such as periodic (and often incomplete) scanning. Today, WhiteSource Open Source Management offers solutions for both governance (policy enforcement, reporting, etc.) and developers that fit into the developers' natural ecosystem – from IDEs to the browser (often used to discover code examples or development guidance, for example) – to provide actionable insight into vulnerabilities and licensing issues, as well as pragmatic guidance for remediation. More recently, WhiteSource introduced effective usage analysis to provide detail on how components are used in software, which helps to prioritize vulnerability identification and remediation. Coverage includes support for container assessment – a growing enterprise demand – as well as for open source applications, modules and projects. WhiteSource offers extensive language coverage and has technology partnerships with other recognized names in application and software security, including Checkmarx and IBM, and offers an integration with MicroFocus (formerly HP) Fortify.

Toward the future

There is somewhat of a parallel between the open source boom and the early days of SaaS and the public cloud, when the adoption of these new and disruptive resources was as simple as providing a credit card for whatever a development or business team needed. In the case of open source, that model extends from inexpensive to free. Open source projects abound and are often the seeds of new efforts for individual vendors, as well as for corporate development. Given the universal and seemingly unquenchable thirst for new technology, this model is one of the primary drivers of the open source revolution.

But such a disruptive model introduces its own risks. In the cloud, the accumulation of just a few dollars here and there has led to the Jevons paradox. With open source, this has led, for example, to the fact that there may be no central authority or agency of any sort responsible for assuring the mitigations of risk that may be introduced by any one developer or component, which can drive cost, complexity and risk beyond expectations.

This openness, however, introduced an opportunity for SCA to thrive. SCA vendors are now embracing the factors that have driven open source adoption itself. Accessing tools for dependency and vulnerability analysis from springboards such as GitHub or exposing their own API has become a market-penetration vehicle for some, giving a wide number of users a taste for SCA's benefits, and whetting an appetite for enterprise-class functionality.

As the demand for new technology parallels a growing awareness of its risks, we expect SCA to continue to prosper. We expect further acquisitions of players in the space, particularly among those that most closely reflect the values of open source adoption and practice, as well as those that need to invest in thought leadership to refresh portfolios that may be showing their age with respect to today's realities of development and IT operations.

We further expect SCA to reflect a growing awareness of the need to apply advances in automation and analytics to solve some of security's most long-standing problems with vulnerability awareness and remediation. An advantage of SCA is the ability to address many of these issues before they become incorporated in software. Uniting these efforts with advances in operational vulnerability awareness and mitigation is desperately needed, before a profusion of technologies permeating every aspect of everyday life poses threats as yet unimagined.