Guide to Software Composition Analysis (SCA)

The code driving many—in fact, most—applications today includes open source components. But 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 in itself 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. But 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.

SCA tools should enable developer teams to embrace security throughout the SDLC

Why use a Software Composition Analysis tool?

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

The cost of a security breach

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. 

The vulnerability that led to this famous breach - a vulnerability in a very popular open source Java library by the name of Apache Struts - was known since February 14, 2017. A fix was released three weeks after that by Apache, and only one day passed before an exploit was made available. An additional two weeks passed between then and when attacks began to peak. If Equifax had found and fixed the issue within that window between the release and the attacks, they would have been protected. With the benefit of hindsight, we now know that they failed to do so. The cost for Equifax was high -  a huge lawsuit and subsequent unprecedented settlement, as well as a substantial hit to the brand’s reputation and credibility which cannot be overestimated.

The Equifax breach was a watershed moment for the security industry and application security in particular as it highlighted the importance of having controls in place to ensure the risk introduced by the open source being pulled in by developers is managed. The breach demonstrated the need for speed - time windows are short and organizations need to be able to find and fix vulnerabilities in the open source packages they are using quickly and repeatedly. Even with modern security toolsets, identifying and resolving security vulnerabilities is a challenge whilst developing with open source.

This is exactly where SCA comes into the picture. 

Why is Software Composition Analysis (SCA) important?

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.

State of open source

Software is eating the world and open source is eating software.It is hard to overestimate the role open source is playing in driving digital transformation. Together with cloud and DevOps, open source is one of the key factors helping companies to digitize their services and to 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 recent 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 a code to name just a few of the building blocks used as part of this new software supply chain, all of which a potential entry point 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 requiring protection. In the case of the Octopus Scanner malware, for example, 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—is what 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.

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

The manner in which 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, but those packages, in turn, rely on additional open source packages that the developer did not necessarily know about. These in-direct, 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 the fact that the vast majority of security vulnerabilities is actually 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. What this means is that the vast majority of security vulnerabilities in applications are usually going to 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, development dependencies—all these are examples of factors that affect how vulnerabilities in open source packages are identified and will determine subsequent remediation steps. It is important that an SCA solution understands these nuances to avoid creating too much noise with false-positives.

3. Drowning in vulnerabilities

Visibility into vulnerabilities and the risk they pose to the organization is obscured by the sheer number of vulnerabilities identified. The Snyk Intel vulnerability database added more than 10,000 vulnerabilities, also 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 which will often consist 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 for receiving updates on vulnerabilities but there is a substantial amount of security intelligence on vulnerabilities that is available in 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 more 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 different 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. More on that later.

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.

Download the cheat sheet PDF

Six Software Composition Analysis (SCA) best practices

Software composition analysis (SCA) tools are 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 these best practices as a guide when using SCA tools.

1. Find a developer-friendly tool (and show developers how it helps them)

Developers are busy writing code. They have to think holistically, design efficiently, and iterate quickly. An SCA tool that isn’t developer-friendly will slow down your developers’ workflow, which means they won’t be inclined to use it. A developer-friendly SCA tool must be easy to set up and use. It should also integrate simply with existing development workflows and tools and as early as possible in the SDLC (like version control tools and IDEs). 

After you choose a tool, educate your developers about why SCA matters and how it can help them. Developers who don’t think of security as their responsibility may resist the concept of taking it on. Help them understand that thinking about security from the beginning, and integrating security checks into their workflow, will save them time later by preventing the need for code rewrites (to incorporate security fixes). Code built securely the first time won’t need to be rebuilt!

2. Understand dependencies

Open source packages contain two kinds of dependencies: direct and transitive. A direct dependency is a package you include in your own project; a transitive (indirect) dependency is a package used by one of your direct dependencies. You can think of this like a nested tree: your packages contain dependencies, and those packages contain dependencies… and so on.

Analyses show that 80% of vulnerabilities in open source packages exist in transitive dependencies! This means that most vulnerabilities in your code are contained in (nested) dependencies that you probably didn’t know you were using. A good SCA tool should accurately inspect all of the dependencies in your code, and should be able to identify and inspect transitive dependencies. Being aware of the depth and complexity of the open source packages used in your code helps you ensure that good vulnerability detection is happening at every level. 

3. Automate scans and identify actionable fixes

A good SCA tool gives you the option to run automated scans at regular intervals. Take advantage of this! Set up proactive and continuous monitoring of your code. Automated scans provide actionable alerts about where vulnerabilities are and how to fix them. Carefully consider the direction your SCA tool provides around fixing vulnerabilities, and make sure that your developers feel confident taking that direction to apply fixes.

4. Integrate SCA into your CI/CD pipeline

Your SCA tool shouldn’t represent a stopping point on your path from development to testing to production. You should be able to integrate SCA scans into your CI/CD pipeline, so that identifying and fixing vulnerabilities becomes a functional piece of your software development and build process. Integrating your SCA tool with the rest of your pipeline also makes it easier for developers to adjust to a culture where code security is part of their daily workflow.

5. Consider the power of reports and SBoM capabilities

Many organizations—including the US federal government—require the inclusion of a software bill of materials (SBoM) report when they purchase a piece of software. Providing a detailed SBoM with your product shows that you understand the value of tracking every component inside of your application.

Clear reports on your security scans and fixes are also powerful. Providing detailed reports on your security practices and number of vulnerabilities fixed shows your commitment to security (and strengthens your market position).

6. Strengthen security policies and improve license compliance

Having clear visibility into the open source packages your developers use will help you create policies that define and enforce your organization’s security guidelines. You can use the knowledge you gain through vulnerability scans to create guardrails for your developers, guiding them to use open source packages with security in mind.

While keeping track of the open source code itself is important for application security, keeping track of open source licenses is crucial for compliance! Licenses define the legal terms of usage for open source packages. Use your SCA tool to get insight on the license terms and conditions of your open source components. As you build security policies, you can include specifications that encourage developers to embrace license compliance early in the software development lifecycle.

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.

About 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.