Guide to Software Composition Analysis: 5 key challenges of SCA

Understanding Software Composition Analysis: how does SCA work?

The code driving many—in fact, most—applications today includes open source components. However, open source code can contain critical vulnerabilities, such as the recently uncovered Log4Shell exploit.

Software composition analysis is your best bet for finding vulnerabilities in open source packages and learning how to fix them, empowering you to secure your code and the health of your applications. Use this guide for best practices when using SCA tools.

SCA is not new, but the growing adoption of open source over the past few years has made it a key pillar of application security programs. As a result, SCA tools have proliferated. However, not all SCA solutions are born equal. Modern software development practices, including the notion of DevSecOps, require that an SCA be developer-first—providing development teams with developer-friendly tooling, on the one hand, and security teams with the ability to guide developers so they can embrace security throughout the SDLC, on the other.

5 Software Composition Analysis (SCA) challenges

As defined above, SCA is an umbrella term for application security methodologies and tools that scan applications (like SAST), typically during development, to map the open source components being used in an application and subsequently identify the security vulnerabilities and software license issues they introduce. To successfully manage and mitigate the risk posed by these open source components, organizations deploying SCA methodologies and tools face a series of challenges related to the way in which open source is leveraged to build modern applications.

Read more about SAST vs SCA and how to leverage them to release secure software

1. Obscured visibility

How open source code is embedded into an application’s code base poses a huge visibility challenge. A developer might directly include a number of open source packages in his code. Still, those packages, in turn, rely on additional open source packages that the developer did not necessarily know about. These indirect or transitive dependencies can go several layers deep, making it extremely challenging to gain end-to-end visibility into what open source is actually being used by an application.

Exacerbating this challenge is that the vast majority of security vulnerabilities are found in these transient dependencies. The Snyk State of Open Source Security report found that an overwhelming 86% of node.js vulnerabilities are discovered in transitive dependencies. Similar numbers were found for Java and Ruby. This means that the vast majority of security vulnerabilities in applications will usually be found in open source code that developers are not even aware that they were using in the first place.

Cloud-native applications leverage open source in another way that can pose a visibility challenge for organizations: as one or more layers building up a container. Container images can consist of various open source components, which also need to be identified and tested for vulnerabilities. The abstraction layer that containers provide developers with, an advantage from a development perspective, is also a weakness from a security perspective.

2. Understanding the dependency logic

To accurately identify the dependencies an application is using, as well as the vulnerabilities they introduce, a deep understanding of how each ecosystem handles dependencies is required. Package resolution during installation, lock files, and development dependencies are examples of factors that affect how vulnerabilities in open source packages are identified and will determine subsequent remediation steps. An SCA solution must understand these nuances to avoid creating too much noise with false positives.

3. Drowning in vulnerabilities

The sheer number of vulnerabilities identified obscures visibility into vulnerabilities and the risk they pose to the organization. The Snyk Intel vulnerability database added over 10,000 vulnerabilities, reflecting this continuous rise in the number of vulnerabilities.

What does this mean for organizations? Well ultimately, these rising trends will usually trickle into their vulnerability backlogs, i.e., the list of vulnerabilities identified and requiring attention, often consisting of thousands of issues. Given the limited amount of resources development and security teams have at their disposal, it is extremely difficult to prioritize efforts without the right security skillset or tools that have advanced security expertise embedded into them. CVSS-based severities is the common method for assessing risk and prioritizing efforts but there are a few inherent weaknesses that make it difficult to use.

4. Find me a vulnerability database

Information on known vulnerabilities is distributed and diffused across various data sources. The National Vulnerability Database (NVD) is commonly used to receive updates on vulnerabilities. Still, there is a substantial amount of security intelligence on vulnerabilities that is available from other sources, such as issue trackers, online forums, security newsletters, and more. NVD might also not add vulnerabilities in a timely enough fashion. 92% of the JavaScript vulnerabilities in NVD, for example, were added to Snyk beforehand.  This lag can be crucial considering the need for short-as-possible exposure windows. Knowing about a vulnerability in time can make all the difference.

5. The need for speed

With developers moving at the speed of light, security teams are finding it hard to catch up. Pressed to deliver code more rapidly and frequently, developers are increasingly adopting open source. Security teams, short on manpower and resources, have traditionally tried to put in place security checks at various stages of the software development lifecycle but this has actually resulted in slowing down development. In other cases, perhaps more detrimental to an organization’s overall application security program, these checks end up getting bypassed or ignored.

This has given rise to the notion of DevSecOps and Shifting Left in the security model—moving responsibility for security into the development teams to ensure minimum disruption to development workflows while also ensuring security. A new breed of SCA solutions was designed with this principle in mind, enabling the implementation of open source security testing early on in the development process. A developer-first approach, such as the one employed by Snyk, complements shift-left by ensuring developer adoption. 

Why is Software Composition Analysis (SCA) important?

Gartner estimates that more than 70% of applications contain flaws stemming from the use of open source. As the case of Equifax shows, exploitation of these flaws can result in disastrous results for an organization. 

More and more, modern applications are composed of open source code. It has been estimated that open source code makes up to 90 percent of the code composition of applications. Of course, applications are not only composed of open source. In fact, one of the challenges facing organizations trying to secure their code base is the fact that applications are assembled from different building blocks that all need to be secured to be able to effectively manage and mitigate risk.

Why use a Software Composition Analysis tool?

Open source components are becoming major building blocks in software across practically every vertical. SCA tools help keep track of open source components used by your applications, which is critical both from a productivity and a security standpoint.

How to choose a Software Composition Analysis tool

SCA tools are not born equal and come in many different shapes and forms. With a market full of different vendors, it’s easy to be overwhelmed. Based on the challenges described above, We've put together a cheat sheet of the top 10 things you should consider when choosing an SCA tool.

Where are SCA tools used in the software development lifecycle?

SCA tools are integrated at multiple stages of the software development lifecycle (SDLC) to identify and mitigate risks associated with open source dependencies. During the development phase, they help developers detect vulnerabilities early by scanning code repositories and dependency manifests. In the build and testing phases, SCA tools ensure that only secure and compliant open source components are used before deployment. Additionally, post-deployment, they provide continuous security insights and alerts for newly discovered vulnerabilities.

What’s the difference between SCA and other testing tools like DAST, SAST, and IAST?

While SCA focuses on identifying vulnerabilities in open source components and their dependencies, other security testing tools target different aspects of application security. Static Application Security Testing (SAST) analyzes proprietary source code for vulnerabilities before execution, whereas Dynamic Application Security Testing (DAST) examines running applications for security flaws through simulated attacks. Interactive Application Security Testing (IAST) offers real time vulnerability detection during application execution. SCA specifically addresses risks related to open source software, ensuring compliance and security throughout the software supply chain.

Why do we need software composition analysis?

Software is eating the world, and open source is eating software. It is hard to overestimate the role open source plays in driving digital transformation. With cloud and DevOps, open source is one of the key factors helping companies digitize their services and leverage their technology to better compete in today’s highly competitive market.

How does open source help? Well, building applications from scratch consumes time and resources. Using open source packages that provide the exact same functionality helps reduce these costs. Open source, by its very nature, is highly flexible and can be easily customized if necessary. Backed by the community, open source is often safer as it is vetted more intensely. Open source is, of course, free and also helps organizations avoid vendor lock-in.

All these benefits translate into increased efficiency and explain the high adoption rate of open source across organizations looking to speed up time to market. In another study by Tidelift, 68% of respondents pointed to saving money and development time as the top key reason their organization encourages the use of open source for application development. 48% cited increased efficiency of application development and maintenance as the reason. Open source usage was peaking well before COVID-19 but the pandemic accelerated adoption rates. Gartner now estimates that 90% of organizations rely on open source in their applications today.

Modern software supply chains

Open source is just one piece of the puzzle comprising the modern, cloud-native application. Applications today are more assembled than they are built. In addition to open source packages, they are assembled from proprietary code, containers, and infrastructure as code, to name just a few of the building blocks used as part of this new software supply chain, all of which are potential entry points for malicious actors.

A vulnerability exploited in one part of the supply chain can be used to infect the entire application, thus expanding the attack surface and requiring protection. For example, in the case of the Octopus Scanner malware, GitHub discovered malware designed to enumerate and backdoor Apache’s open source NetBeans IDE. The method of attack here—affecting the supply chain by abusing the build process and causing its resulting artifacts to spread, with affected projects likely to get cloned, forked, and used by many different systems—made this attack interesting but, sadly, not unique. The recent SolarWinds attack, this time targeting proprietary software, further demonstrates the growing risk the modern software supply chain poses for organizations. 

Open does not mean secure

Open source projects are considered to be safer to use. After all, when there’s an entire community involved in maintaining and developing a project, issues are identified and fixed more quickly. This includes bugs, of course, but also security vulnerabilities. Having said that, this does not mean that open source is without risk. If fact, one may argue that the very same reason why open source code is often considered as being more secure is also a chink in the armor.

By definition, open source projects are public and visible to all. Malicious actors included. Any vulnerability discovered and fixed in them is implicitly exposed for attackers to find. The more popular the open source project, the more attractive the package is going to be as the impact of an attack is wider. Going back to the Equifax breach mentioned above as an example, the open source package used for the attack—Java’s Apache Struts library—is used by a huge amount of applications, making the attack notorious for its wide blast radius.

Of course, organizations consuming open source do so “at their own risk,” as there is no vendor to notify them about flaws or a signed contract that lets them shed the responsibility. The responsibility for keeping these components secure sits entirely with the consumer.

The future of Software Composition Analysis (SCA)

Given the growing adoption of open source, together with the publicity of recent breaches and cyber attacks, the interest in SCA will likely. The role open source is playing in fueling digital transformation is becoming increasingly apparent and there is little to no reason to assume that these trends will change any time soon.

Organizations are using open source to help them better compete in their respective markets while at the same time there is a growing understanding that they must control this usage by managing and mitigating the accompanying risks. Only Software Composition Analysis tools that answer the key requirements listed above will help organizations successfully achieve this goal.

Software Composition Analysis comprehensive solutions with Snyk Open Source

Snyk Open Source helps organizations like Salesforce, Google, and Facebook enhance application security by enabling development teams to automatically find, prioritize and fix security vulnerabilities and license issues in their open source dependencies and containers early in and across the SDLC.  Unlike other security solutions in the market, Snyk Open Source is a developer-friendly tool that integrates seamlessly into development workflows, providing automated remediation and actionable security insight to help organizations identify and mitigate risk efficiently.