Software composition analysis

What is software composition analysis (SCA)?

SCA is a software security testing methodology that automatically identifies, inventories, and assesses the open-source and third-party components within a codebase. These components can be anything from libraries and modules to frameworks and container images. SCA tools meticulously scan an application's files to generate a comprehensive list of all these external resources, a crucial document known as a software bill of materials (SBOM).

Unlike other security methods that focus on custom-written code, SCA scrutinizes the "borrowed" parts of an application. It provides deep insights into the security posture of these packages by cross-referencing them against diverse databases. This process helps organizations proactively manage risks by highlighting known security vulnerabilities, outdated component versions, and legal issues related to open-source licenses. By integrating SCA into their workflows, development and security teams gain control over their software supply chain, which is often a major blind spot.

How does software composition analysis work?

The core of SCA is a systematic, multi-step process that brings transparency to an application's dependencies. SCA tools perform meticulous analyses to uncover every component, no matter how deeply nested it may be.

1. Component and dependency identification

The first step for an SCA tool is to create a complete inventory of every third-party component used in an application. This includes both direct dependencies (components explicitly added by developers, such as a logging library) and transitive dependencies, which are the components that the direct dependencies rely on. As illustrated in xkcd comic #2347, which we shared on our blog some time ago, this is a crucial step, as a project can unknowingly rely on a small, obscure, and undersupported package found several layers deep within its dependency tree.

SCA tools achieve this by scanning a variety of artifacts and files, including:

• Project manifest files: The tools analyze manifest files (files that contain metadata for a set of files) such as package.json (for JavaScript), pom.xml (for Java), or requirements.txt (for Python), which list a project's declared dependencies.

• Source code and binary files: SCA can also examine the source code or compiled binary files to identify components that may not be listed in a manifest, providing a more accurate picture of what's actually in use.

• Container images: By scanning container images, SCA tools can identify every package within the runtime environment, including those inherited from a base image. This helps to eliminate hidden risks in the deployment environment.

2. Creating the SBOM

Once the SCA tool has identified all the components, it compiles them into an SBOM. As we have discussed in a dedicated post, an SBOM is essentially a comprehensive "ingredient list" for a software product. It provides a detailed, structured inventory of all the components, their versions, and their relationships.

A well-generated SBOM includes essential information about each component, such as:

• Component name and version: The specific identity of the library or package.

• Origin and source: Where the component came from (e.g., a specific package manager or repository).

• License information: The license under which the component is distributed (licenses for open-source code may vary in their requirements for rights such as copy, modification, and redistribution).

• Hashes and checksums: Cryptographic data to verify the integrity and authenticity of the component.

• Known vulnerabilities: A list of any security flaws associated with that specific version.

An SCA tool can generate SBOMs in standardized formats like CycloneDX or SPDX, which ensures the data is easily understandable and shareable with internal and external stakeholders, including legal and security teams.

3. Vulnerability, license, and quality analysis

With the SBOM as a foundation, SCA tools perform their primary function: assessment. They cross-reference the components and their versions against a variety of databases to identify risks.

• Vulnerability databases: The tool checks the SBOM against public vulnerability databases like the National Vulnerability Database (NVD) and the Common Vulnerabilities and Exposures (CVE) database. It also leverages proprietary databases maintained by commercial vendors, which often contain more timely or niche vulnerability data not yet publicly disclosed. When a match is found, the tool can provide critical details such as the CVSS score (a numerical rating of severity), affected versions, and recommended remediation steps.

• License compliance databases: SCA tools analyze the licenses associated with each package and compare them to the organization's legal policies. (The most common types of licenses in open source are those categorized as permissive. These tend to have fewer restrictions on the use of components. They often do not require monetary or intellectual compensation and, therefore, represent a low risk. On the other hand, the riskiest, especially for commercial use, are the so-called reciprocal or "copyleft" licenses. These require some compensation for the use of the code.) This helps prevent conflicts with copyleft licenses (which may require the entire application to be open-source) or other restrictive licenses that can lead to legal disputes and financial penalties.

• Component quality: SCA can also assess the overall quality and maintenance status of components. It can flag outdated libraries, packages with low maintenance activity, or those that have been discontinued. This helps developers choose components that are actively supported and less likely to introduce future risks.

4. Reporting and remediation

Finally, the SCA tool generates reports with actionable insights, including a prioritized list of vulnerabilities based on severity, exploitability, reachability, and potential impact on the application's environment. The reports should pinpoint the exact component, version, and nature of the issue. A modern SCA solution also provides concrete remediation advice, such as updating to a specific patched version or replacing a component with a safer alternative.

Why is SCA important?

The need for SCA stems directly from the realities of modern software development, which is heavily dependent on an increasingly complex, interconnected software supply chain. As our post on the topic highlights, this supply chain is the entire ecosystem of components, tools, processes, and people that contribute to a software product.

Protection against supply chain attacks

Nowadays, attackers have changed their approach and no longer tend to focus on individual organizations, but rather on compromising widely used components. By injecting malicious code or exploiting a vulnerability in an open-source library, they can compromise thousands of applications that rely on it, as seen in the infamous Log4Shell incident. This single flaw in a popular logging library exposed millions of applications to remote code execution. Another recent example is the npm supply chain attack, where a phishing scheme led to compromised versions of 18 popular JavaScript packages, downloaded billions of times weekly by the developer community.

SCA is perhaps the primary preventive measure against these attacks. By providing a clear and continuously updated inventory of all third-party components, it gives organizations the visibility they need to quickly determine if they are using newly compromised packages. This enables rapid responses and remediation before attackers can exploit vulnerabilities.

Managing risk and compliance

The sheer volume of open-source code and the number of known vulnerabilities make manual tracking impossible. SCA automates this daunting task, providing a scalable solution for:

• Vulnerability management: It systematically identifies and helps prioritize vulnerabilities based on their severity and actual risk, saving security teams from chasing every alert and allowing them to focus on the most critical threats.

• Legal compliance: The open-source ecosystem is governed by a multitude of licenses, each with its own set of rules. Some licenses, like copyleft, can have a significant legal impact on a company's proprietary code. SCA helps legal and compliance teams ensure that all licenses comply with organizational policies, preventing costly legal disputes.

The problem of undersupported infrastructure

Many open-source projects are maintained by a handful of individuals with little or no compensation. This can lead to security flaws and vulnerabilities due to a lack of resources, time, or expertise. As discussed in our blog posts on undersupported digital infrastructure and the "Nebraska joke," many projects that are critical to our digital infrastructure might be in a precarious state. When an SCA scan reveals that a critical component is no longer maintained or has known vulnerabilities, organizations can make an informed decision to either find a more secure alternative or contribute to the project's maintenance.

Aiding developer productivity

SCA is a tool that nudges developers, not hinders them. By providing real-time feedback within their integrated development environment or management platform, SCA allows developers to choose secure libraries and fix issues as they are writing code. The "shift left" approach prevents vulnerabilities from being pushed downstream, where they are far more expensive and time-consuming to remediate. It ensures that security is an integrated part of the development process, not an afterthought.

What types of issues does SCA find?

SCA is a multi-faceted tool that addresses a broad range of risks inherent in the use of third-party software.

• Known security vulnerabilities: This is the most common use of SCA. It detects known security flaws (CVEs) in specific versions of open-source packages. For example, it would alert you if your application uses an old version of a popular JavaScript library with a known cross-site scripting (XSS) vulnerability.

• Malicious or compromised packages: SCA can identify packages that have been deliberately compromised by attackers as part of a supply chain attack. It can also help detect malicious code that has been inserted into a legitimate project.

• Outdated or unmaintained components: A component that is no longer supported by its creators can become a security risk. SCA flags outdated dependencies, helping teams to update to newer, safer versions.

• License compliance issues: SCA checks the license of every component, ensuring that it aligns with the company's legal policies. It can help flag licenses that require attribution, are incompatible with the organization's business model, or could lead to legal action.

• Component quality and provenance: Beyond security, SCA can provide insights into a component's quality, such as its version history, contribution frequency, and authorship, helping teams to make informed decisions about which packages to use.

What are the differences between SCA and SAST?

It's crucial to understand that SCA and static application security testing (SAST) are complementary, not competing, security methodologies. While they both analyze code in a non-running state, they focus on different aspects of the codebase.

SAST focuses on the code that the development team writes, while SCA focuses on the code they use. When SCA is combined with SAST, an organization can move closer to a holistic security posture, protecting both the custom logic and the external components that form the backbone of the application.

What to look for in a software composition analysis tool

Implementing SCA effectively requires a strategic approach, starting with choosing the right tool. A high-quality SCA solution should have the following key features:

• Comprehensive coverage: A good SCA tool must be able to scan all parts of your software supply chain, including manifest files, source code, binary files, and container images. It should also have the ability to identify both direct and transitive dependencies, no matter how deeply nested they are.

• An accurate and comprehensive database: The quality of an SCA tool is heavily dependent on the quality of its vulnerability database. A top-tier tool should aggregate data from multiple public sources as well as its vendor's own vulnerability research. This ensures that new vulnerabilities are detected as soon as they are disclosed.

• Actionable insights: A tool that simply lists thousands of vulnerabilities can overwhelm a team. The best SCA solutions prioritize issues based on severity, exploitability, reachability, and potential business impact. They should also provide clear remediation guidance, such as recommending specific updated versions or offering automated solutions.

• Seamless integration: The SCA tool should fit naturally into your developers' existing workflows. Look for solutions that offer IDE plugins and continuous repository assessment to get real-time feedback as code is written. This "shift left" approach is crucial for fast and efficient remediation.

• Effective SBOM generation: The SCA solution should be able to automatically generate an accurate SBOM in an industry-standard format (like CycloneDX or SPDX). This feature is essential for demonstrating transparency, ensuring compliance, and sharing information with partners and clients.

• Continuous monitoring: As new vulnerabilities are discovered daily, a one-time scan is insufficient. A robust SCA solution provides continuous monitoring, sending alerts as soon as a new vulnerability is found in a component you're already using.

Key steps to implement SCA effectively

Beyond simply choosing a tool, a successful SCA implementation requires a strategy for integrating security throughout the software development lifecycle (SDLC).

Early integration

The maximum value of SCA is realized when it is integrated as early as possible in the SDLC. SCA tools should be configured to run in developers' local environments, providing immediate feedback on insecure dependencies before they are committed to the codebase. This helps developers learn secure coding practices and prevents vulnerable components from ever making it to a central repository.

Establish clear policies

Before running the first scan, an organization needs to establish clear security policies. This includes defining an acceptable severity level for vulnerabilities and a list of approved and unapproved open-source licenses. These policies can then be enforced by the SCA solution, which can be configured to automatically block builds or deployments that contain a component that violates a predefined rule.

Prioritize and remediate

SCA can often produce a large volume of findings. It is crucial to have a process for triaging and prioritizing these issues. Vulnerabilities should be ranked based on their severity and their relevance to the application's functionality. For example, a high-severity vulnerability in a library that is not actively called by the application's code may be a lower priority than a medium-severity flaw in a core component.

Continuous assessment and improvement

SCA is not a one-time process. Organizations must continuously evaluate their dependencies for new vulnerabilities, as they are discovered daily. The methodology should also be reviewed and updated regularly to account for new technologies, programming languages, and evolving security threats.

Fluid Attacks: a comprehensive approach to SCA and beyond

At Fluid Attacks, we recognize the importance of a comprehensive and proactive approach to software security. Our SCA is a core part of our Continuous Hacking solution, designed to help organizations secure their software supply chains from the very beginning of the SDLC.

We offer an SCA tool that provides a holistic view of your dependencies and their associated risks. Our scanner, which only takes a few minutes to set up to connect to your Git repository, can:

• Generate accurate SBOMs: Our tool automatically creates a detailed SBOM that includes a complete mapping of your dependency tree, giving you a comprehensive inventory of all the open-source components, libraries, and services you use. This helps you systematically and thoroughly recognize and analyze the dependencies of your software projects.

• Provide timely and valuable insights: We provide timely information about your dependencies' security issues and carefully determine their reachability—that is, whether your application can actually access and trigger the vulnerable code. Our automated testing tools deliver vulnerability reports through our easy-to-use platform, as well as through IDE extensions, making them even more accessible to your development team.

• Stay ahead of threats: Our security research team works tirelessly to keep our scanner updated, especially for new vulnerabilities in widely used open-source projects. For example, we helped our clients identify and remediate the Log4Shell vulnerability and the recent npm supply chain attack, avoiding potential disaster.

• Offer seamless integration: Our SCA tool is designed to integrate into modern DevSecOps workflows and is compatible with major Git repositories, including GitLab, GitHub, Azure, and Bitbucket. This allows for continuous scanning that keeps pace with your development teams.

What truly sets Fluid Attacks apart is our integrated, human-augmented approach. Our SCA tool is complemented by other security testing methodologies, including SAST, DAST, and pentesting as a service (PTaaS). This ensures that we not only find vulnerabilities in your third-party components but also in your custom code and runtime environment. With our Continuous Hacking solution, you can rest assured that your software supply chain is secured from end to end.

Conclusion

In an era where modern software relies heavily on open-source components, software composition analysis (SCA) is no longer a luxury—it's an essential requirement for a robust application security strategy. SCA shines a light on the often-hidden risks within the software supply chain, from security vulnerabilities to legal non-compliance.

By providing comprehensive visibility into an application's dependencies and automating the painstaking process of tracking and assessing them, SCA enables organizations to build more secure, reliable, and compliant software. When SCA is integrated with complementary methodologies like SAST, DAST, and pentesting and seamlessly woven into a mature DevSecOps pipeline, it provides a powerful defense against the most common and damaging cyberattacks.

As we continue to rely on the collaborative power of the open-source community, adopting SCA is a proactive way to manage that shared responsibility. It not only safeguards your applications but also demonstrates an unwavering commitment to excellence, transparency, and security in a world built on a shared digital foundation.

If you are interested in detecting vulnerabilities with our SAST, DAST, and SCA tools, we invite you to subscribe to our 21-day free trial. If you have any questions, do not hesitate to contact us.