Software composition analysis (SCA)

What is software composition analysis?

The term software composition analysis (SCA) applies to a software security testing methodology as well as to software tools that use this methodology. SCA differs from other application security testing methodologies such as DAST, SAST, and IAST in that it works not by finding actual security vulnerabilities but by discovering and precisely identifying software components that are known to have such vulnerabilities.

The primary interest of software composition analysis solutions lies in open-source software (OSS) used as part of the development workflow. Open-source components are an integral part of almost every software supply chain nowadays. Open-source code dependencies often make up as much as 80% of the overall application codebase. At the same time, such components are prone to AppSec vulnerabilities and not all development teams will always use the latest version of every component to minimize the risk of know vulnerabilities. This is why open source security is now a priority for many organizations.

How does SCA work?

Software composition analysis tools find all components in the application, identify their versions, and check this information against known vulnerability databases such as MITRE’s CVE and the National Vulnerability Database (NVD). In addition, some vendors build and maintain their own databases of known vulnerable components to extend publicly available data sources. Note that while open-source licensed components are of most interest, SCA tools are also able to discover and identify third-party components with commercial licenses.

SCA tools are non-invasive. They either interact with the running application to get a response that would allow them to fingerprint a component or search through the application code to get that information. They do not need to perform mock attacks like DAST tools or to deeply analyze the code like SAST tools.

Types of software composition analysis

While the goals of all software composition analysis solutions are the same, different products take slightly different approaches to analysis. There are two primary types of SCA tools:

Static SCA tools work with the source code of the software application and therefore require direct access to code repositories or IDEs. This makes them usable only during the early software development process. They pair very well with SAST tools, which have the same requirements and work in the same software development lifecycle stages. However, they leave a major gap in security by not being able to cover applications that are already in production.
Dynamic SCA tools don’t need direct access to the source code but do need a way to access the application both from the outside and from the inside. Instead of looking for known source code fragments, such tools fingerprint open-source components by recognizing their behavior, their external presence (HTML/JavaScript), or by using additional information from a sensor that interfaces with the runtime environment. Dynamic SCA is able to cover the entire SDLC (including live production environments), finds both front-end and back-end components, and pairs perfectly with DAST/IAST solutions. Sometimes it is offered as part of such solutions, as in the case of Invicti and Acunetix by Invicti.

Advantages and disadvantages of software composition analysis

Open-source vulnerabilities flagged by SCA through the identification of vulnerable components are also detected by DAST, IAST, and SAST. Why use SCA, then?

The biggest advantage of SCA solutions is that they give immediate remediation information and an SCA scan requires no manual verification, analysis, or even prioritization since the tool immediately identifies the severity of vulnerabilities. While many DAST/IAST/SAST tools can do the same, they primarily focus on the vulnerability itself and not the whole open-source component. Also, note that there is very little risk of false positives when using SCA. The only risk comes if your developers modify third-party components and therefore fool the fingerprinting mechanisms.
Another advantage of SCA is its speed. DAST tools need to perform checks by sending multiple complex requests and analyzing responses, which takes time and consumes resources. IAST tools need the entire application to run through all its functionality. SAST tools need to deeply analyze every line of code. On the other hand, SCA usually needs just passive fingerprinting or a single request and response to identify a component. Therefore, an SCA scan is by nature much less time-consuming. If you run a DAST/IAST scan with SCA scanning included, you won’t even notice that it’s there.
SCA tools help you build your software bill of materials (SBOM). In larger organizations, it’s nearly impossible for the security team to have a complete list of all the open-source components used by different teams. SCA tools bridge this gap by identifying all the open-source components introduced by developers, which improves risk management and may also be used for other purposes, such as license compliance. Since SCA is not limited to open-source, it may also help with finding potential licensing issues, for example, commercial third-party components used by developers without proper licensing.

On the other hand, SCA cannot be considered your primary application security tool due to its limitations:

By its nature, SCA does not cover your custom code at all, so an SCA scan will miss out on all vulnerabilities that you introduced in your own code or by modifying existing open-source libraries and other components.
SCA works with databases of known vulnerabilities, but many unknown vulnerabilities also exist, including in open-source projects. This could be because a specific open-source project is not popular enough and there is no one to report a vulnerability or because it is quite complex and vulnerabilities simply go unnoticed for a long time. In such cases, DAST covers the bases that cannot be covered by SCA – and it is not uncommon for DAST tools to discover previously unknown vulnerabilities using generic security checks.

How to use SCA?

Just like every type of cybersecurity tool, SCA covers a limited scope of potential risks and is not enough to ensure security. Software composition analysis should be part of a complete security solution ecosystem. To cover all use cases across web application security, it is best practice to use at least a DAST solution alongside SCA, though adding IAST, WAF, and SAST to the mix can also be beneficial, especially for larger organizations.

If you’re using tools such as Invicti or Acunetix by Invicti, where SCA is tightly integrated with DAST/IAST scans, no extra work is needed – you run your regular scans and benefit from getting additional SCA insights directly in your scan results in near real-time, including precise component version information. If you use a standalone SCA solution, you will need to run it as part of your regular DevSecOps routine, along with any other scans such as DAST, IAST, and/or SAST.

Since data sources such as NVD are updated daily and the use of open-source components keeps growing, it’s a good idea to run SCA scans daily, and not just in your DevOps CI/CD pipeline but also in production. What seemed safe yesterday may turn out to be dangerous today. A new vulnerability identified yesterday may already have an exploit in the wild today.

The recommended way to use SCA is thus to automate scanning together with DAST/IAST/SAST and perform daily scans at least of your critical web assets, including your production websites, web applications, and APIs.

Frequently asked questions

What is software composition analysis (SCA)?

Software composition analysis (SCA) means discovering and precisely identifying software components that are known to have vulnerabilities. SCA does not involve security testing, unlike application security testing methodologies such as DAST, SAST, and IAST that find actual security vulnerabilities rather than identifying known vulnerable components.

Find out how DAST+SCA gives you more coverage in a single scan.

What types of software can SCA be used for?

SCA can be used to discover vulnerable components such as libraries, modules, plugins, and more. It works for front-end components and frameworks as well as for back-end components. SCA focuses primarily on open-source components but may include commercial components as well.

Learn more about Invicti SCA.

How does SCA work in Invicti and Acunetix?

In Invicti and Acunetix products, the SCA functionality is provided by a separate sensor (agent) that also includes IAST. This sensor runs in the application environment and has access to more back-end information, so it is able to identify vulnerable back-end components. Components and versions are identified not only based on signatures (like in other products) but by their unique fingerprints.