Software composition analysis (SCA) is a method of finding out which open-source and third-party components a piece of software is built from, then checking those components for known security vulnerabilities, license obligations and signs of being outdated or abandoned. Most modern applications are assembled largely from libraries written by other people, so knowing exactly what is inside, and which versions, is the starting point for managing the risk they bring.
At a glance
- SCA is one method within application security testing, focused on the components you include rather than the code you write.
- It inventories direct dependencies and the indirect ones they pull in, with versions.
- It matches that inventory against vulnerability databases, often using CVE identifiers, and against license rules.
- Many SCA tools can generate a software bill of materials (SBOM).
- Results are often noisy, so prioritization by severity and reachability matters as much as detection.
What problem it solves
Developers add open-source libraries to save time, and each library may bring others along with it. Within a few years an application can depend on hundreds of components that nobody on the team chose directly. When a serious flaw is announced in one of them, the first question is “do we use it, and where?” Without an inventory, answering takes days of searching.
SCA answers that question continuously. It also catches license problems, such as a component whose license terms conflict with how you distribute your product, and it highlights components that are badly out of date, which tend to become technical debt if nobody upgrades them. For buyers of software, it is also the practice behind the question “how do you keep your dependencies patched?”, which matters more after high-profile supply chain attacks.
How it works
Discovery. The tool reads dependency manifests and lock files (the files that list which packages a project uses), and depending on the product may also scan built applications, container images or binaries to find components that aren’t declared.
Inventory. It builds a list of components, versions, licenses and the chain of dependencies that brought each one in. This list is the raw material for an SBOM.
Matching. Each component and version is compared against vulnerability databases and the vendor’s own research. License data is checked against policies you set, for example flagging licenses your legal team hasn’t approved.
Prioritization. Findings are ranked by severity, whether a fix is available, whether the flaw is known to be exploited and, in some tools, whether your code actually calls the vulnerable function.
Action. Many tools open issues or propose upgrade changes automatically, and can fail a build or block a merge when policy is breached. Ongoing monitoring re-checks existing inventories when new vulnerabilities are published, feeding wider vulnerability management.
When it matters for buyers
- When you build or customize software. Including internal tools, integrations and customer-facing applications.
- When customers ask for an SBOM or a dependency policy. SCA tooling is the usual way to produce and maintain one. Requirements vary by industry and country, so check what applies to you.
- When buying software or outsourced development. Ask how the vendor tracks components and how fast it patches known critical issues. For custom development, the statement of work (SOW) or security schedule can require scanning on each release and an SBOM at handover.
- When a big vulnerability is in the news. Organizations with SCA inventories can usually answer “are we affected?” faster.
- When comparing security platforms. SCA is often sold alongside SAST and other testing. Our application security testing overview covers how those bundles compare.
Questions to ask vendors
- Which languages, package managers and build systems do you support, including ours?
- Do you detect indirect dependencies and components that aren’t declared in manifests, such as in container images?
- How do you prioritize findings, and can you show whether vulnerable code is actually reachable?
- Which SBOM formats can you produce and import?
- How do you handle license policies, and can legal set them without developer help?
- How is pricing calculated: per developer, per repository or per application?
- If you are a software vendor selling to us: how quickly do you fix critical component vulnerabilities, and will you tell us when one affects our version?
How it differs from SAST
Static application security testing (SAST) analyzes the code your own team writes, looking for insecure patterns such as unchecked input reaching a database query. SCA looks at the components you include from others and compares them with lists of known problems. SAST finds new, unknown flaws in your code; SCA finds already-known flaws in someone else’s. A typical application needs both, which is why platforms often bundle them, but they are separate checks with separate findings, and a vendor that runs one has not necessarily run the other.