What is software composition analysis

Definition

Software composition analysis, usually shortened to SCA, is the automated discovery of the open source and third party components inside a piece of software. An SCA tool scans a project, resolves its dependency tree, and reports what is present: the components, their versions, the known security vulnerabilities tied to those versions, and the license each component declares. It serves two purposes at once. On the security side it surfaces vulnerable components so they can be patched or replaced. On the license side it builds the inventory that license risk management depends on. The same scan that finds a vulnerable library also records that the library is, for example, under the GNU GPL or the Apache 2.0 license.

What an SCA tool finds

A capable SCA tool resolves the full tree, direct and transitive, rather than only the components a team declared. For each node it reports the version in use, matches it against vulnerability databases, and reads the declared license. The combined output is the foundation of a software bill of materials and the input to policy enforcement: a rule that blocks a build when a forbidden license appears, or flags a component when a critical vulnerability is published. Most SCA tools can emit the inventory directly in a standard format such as SPDX or CycloneDX, which is why the analysis and the bill of materials are so closely linked in practice.

Where it falls short on relicensing

SCA is strong at detection and weaker at judgment, and the relicensing wave sits in the gap. A tool reports the license a component declares, so once its database reflects a change it can flag that a component is now under the Business Source License or the Server Side Public License. What it does not do is tell you whether your specific use crosses the restriction those licenses impose, how far the change cascades through the components that depend on the relicensed one, or what the exposure costs in money and engineering time. Source available is not open source, and these licenses are not approved by the Open Source Initiative, but an SCA report treats a license string as a fact to record, not a situation to assess. The analysis that turns a flagged license into a sized, prioritized exposure is human work the tool supports rather than replaces. Treating an SCA pass as a complete license risk review is a common and costly mistake.

How it fits a license risk program

SCA is the right first instrument and the wrong last word. It produces the current, machine generated inventory that nothing else can match for breadth and speed, and it keeps that inventory fresh as the tree changes. The value comes from pairing it with analysis: reading the findings against your actual use, judging which flagged licenses create real exposure, and pricing the cost to cure. That pairing is the core of an open source license risk assessment, which uses the SCA output as a starting map and adds the judgment the tool does not provide.

Related reading

For the indirect components that SCA exists to surface, see what is a transitive dependency. For the function that turns these scans into a standing capability, read what is an open source program office. Both sit alongside the rest of our open source license risk glossary.