Software Composition Analysis (SCA): Overview, Challenges, and Implementation

Software Composition Analysis (SCA) is a technique that identifies, manages, and tracks software components by analyzing their metadata and characteristics.

In modern development, most application code consists of open‑source components. In China, 88.2% of enterprises used open‑source technology in 2020, up 6.8% from 2018. However, 84% of popular open‑source projects contained at least one vulnerability in 2020, with 60% having high‑severity issues.

Notable incidents include the Log4j2 vulnerability affecting over 44,000 open‑source packages and a 2020 GPL‑3.0 copyright dispute in China.

SCA can analyze any language (Java, Go, Python, JavaScript, binaries, firmware). The process extracts component names and versions from source code or binaries, matches them against known vulnerability databases, and reports risks.

Practical challenges arise when building a mature, easy‑to‑use SCA tool, such as handling diverse package formats, binary analysis, and accurate vulnerability correlation.

The implementation at DeWu Security uses a two‑layer architecture: automated component risk detection and early‑stage security shift‑left, integrated with CI pipelines and GitLab merge‑request reviews.

Supported languages and artifact types include:

Java – pom.xml, JAR

Go – go.mod, go.sum, compiled binaries

Python – requirements.txt, Pipfile, Pipfile.lock

JavaScript – package.json, package-lock.json, yarn.lock

Detection methods are:

Project build – extracting dependencies from compiled artifacts (e.g., JAR’s BOOT‑INF/lib).

Package‑manager files – parsing language‑specific manifest files (e.g., go.mod).

Vulnerability data sources include NVD, GHSA, GLAD, Go VulnDB, and Node security advisories. Upcoming CVE 5.0 format will add richer fields such as severity scores and researcher credits.

SCA is also used for incident response (e.g., Log4j2, Fastjson) to locate affected services and notify owners.

Future work aims to shift SCA further left, integrating it into internal private repositories so that only vetted components are used in development.

References: CAICT report, CVE format announcement, OWASP Dependency‑Check.