Software Composition Analysis Explained

You cannot govern open source you cannot see. Software composition analysis is the tooling that makes it visible. At its simplest, software composition analysis scans your code and its build to discover every open source component inside it, names each one and its version, records the license, and usually flags known vulnerabilities. For most organizations it is the first practical step toward control, because it replaces a guess about what you run with an inventory. This article explains what software composition analysis does, why its license detection is as important as its security findings, and the limits you should plan around.

The article sits under the pillar on governance and SBOM and supports our open source governance and policy service, where SCA output becomes the basis for rules and controls. For the durable record SCA produces, see maintaining an accurate SBOM.

How software composition analysis finds your dependencies

Software composition analysis works by examining the signals that reveal which open source you depend on. It reads manifest and lock files from package managers, inspects the build, and in stronger forms fingerprints binaries and matches code against known component signatures. The important capability is depth. Most of your open source arrives indirectly, pulled in by another library that you chose deliberately, and a tool that sees only the top layer of declared dependencies misses most of the tree. Good software composition analysis traces transitive dependencies down through every layer, because that is where the components you never chose, and never tracked, actually live.

The output is an inventory: a list of components, versions, and licenses, ideally exported to a standard format such as SPDX or CycloneDX so it can be stored, compared, and shared. That inventory is the raw material for everything else, from a software bill of materials to a license policy to an audit response. Run once, it is a snapshot. Run continuously in the pipeline, it becomes a live picture that changes as your dependencies change, which is the form that actually protects you.

Why license detection matters as much as vulnerabilities

Most teams adopt software composition analysis for security, to catch known vulnerabilities in their dependencies. That is valuable, but for relicensing risk the license field is the one that earns its keep. Software composition analysis records the license of every component it finds, and a continuous scan compares that license against the last known state. When a component you depend on moves from an open license to a source available one, the change shows up at the next scan. That is how a move to the Business Source License or the Server Side Public License gets caught in your pipeline rather than discovered in an audit or a vendor letter months later.

The recent wave of relicensing makes this concrete. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License as of August 2023. Redis moved to the Redis Source Available License and the Server Side Public License as of March 2024. Elasticsearch and Kibana moved to the Server Side Public License and Elastic License in 2021. In each case, an organization running continuous license detection would have seen the license field change at the next scan and could have acted early, while the choices, including the forks OpenTofu, Valkey, and OpenSearch, were open and unhurried. Continuous monitoring is the subject of continuous open source license monitoring.

The limits of the tooling

Software composition analysis is necessary but not sufficient, and treating its output as a final answer is a common error. The tooling has real limits. It can miss code that was copied in by hand rather than pulled through a package manager, the vendored or modified components that no manifest declares. It can misread a license, particularly where a project ships multiple licenses or has changed terms between versions. And it does not interpret what an obligation means for your specific business, because that is a judgment, not a scan result. A tool that flags a copyleft component cannot tell you whether your use triggers the obligation.

The practical conclusion is that software composition analysis produces an inventory and a set of flags, and a person turns those into a ranked, funded decision. The scan tells you what you have and what changed. Human judgment, informed by your usage and your risk appetite, tells you what to do about it. That is why an open source license risk assessment pairs automated discovery with analysis, and why software composition analysis is the start of governance rather than the whole of it. For the broader program that the tooling feeds, see building an open source program office.

RELATED READING