Binary composition analysis (BCA) is the practice of identifying the open source components, libraries, and versions embedded inside a compiled artifact — a container image, firmware blob, executable, or shared object — without access to its source code, build manifest, or package lockfile. Instead of parsing a package.json or pom.xml, BCA tools fingerprint the binary itself: extracting version strings, hashing functions, matching symbol tables, and comparing byte patterns against known-library signature databases. Security teams reach for BCA when they inherit software they didn't build — vendor firmware, third-party appliances, legacy systems with lost build records, or statically-linked and shaded artifacts where the dependency tree never survives compilation. It's the difference between trusting a vendor's stated bill of materials and independently verifying what's actually running. As supply chain attacks increasingly target build pipelines and shipped binaries rather than public source repositories, BCA has moved from a niche firmware-security technique to a standard control in software supply chain security programs.
What is binary composition analysis, exactly?
Binary composition analysis is a static analysis technique that inspects compiled code to determine which third-party and open source components it contains, without relying on declared dependency manifests. A BCA engine disassembles or unpacks the target artifact — an ELF binary, a Docker image layer, a firmware .bin file, a JAR — and searches for evidence of known open source libraries: embedded version strings (e.g., zlib 1.2.11), compiler-inserted symbol names, string literals unique to a library's error messages, and cryptographic hashes of individual functions that can be matched against a reference corpus of compiled OSS packages. Commercial and research tools that do this include Synopsys Black Duck Binary Analysis (formerly Protecode/BDBA), FossID, the open source FACT (Firmware Analysis and Comparison Tool), and BANG (Binary Analysis Next Generation). The output is effectively a reconstructed software bill of materials (SBOM) for something that shipped with no SBOM at all.
How is binary composition analysis different from software composition analysis (SCA)?
Binary composition analysis differs from SCA in what it reads: SCA parses build-time metadata like package-lock.json, go.sum, or pom.xml to enumerate declared dependencies, while BCA inspects the compiled output itself. SCA is fast and precise when manifests are accurate — it can resolve a full dependency graph for a Node.js project in seconds by reading package-lock.json. But SCA is blind to anything that doesn't appear in a manifest: a vendored copy of a library pasted into source, a statically compiled OpenSSL bundled into a firmware image, or a dependency that was present at build time but stripped from version control afterward. BCA catches exactly those cases because it doesn't need the manifest — it needs the binary. In practice, mature supply chain security programs run both: SCA on source repositories during CI, and BCA on final build artifacts, container images, and any third-party binaries entering the environment, to verify that what was declared actually matches what was shipped.
Why did the 2024 XZ Utils backdoor make binary composition analysis matter more?
The XZ Utils backdoor (CVE-2024-3094, CVSS 10.0) mattered because it was inserted into the release tarballs and compiled liblzma binary distributed to Linux distributions — not into the public GitHub source tree that most SCA tools scan. A contributor using the alias "Jia Tan" spent roughly two years building trust in the XZ project before adding obfuscated malicious code to build scripts on 2024-02-23, which modified the compiled liblzma.so to intercept SSH authentication via a patched OpenSSH sshd. It was discovered by accident on 2024-03-29 when Microsoft engineer Andres Freund noticed a 500-millisecond latency increase in SSH logins on Debian sid and traced it to the binary. Because the backdoor logic lived in the compiled shared object and build-time obfuscation, not in a diffable source file most reviewers would inspect, a binary-level integrity and composition check against known-good liblzma builds was one of the few controls positioned to flag the tampering before deployment.
Can binary composition analysis catch vulnerabilities like Log4Shell inside repackaged artifacts?
Yes — binary composition analysis is specifically designed to catch cases like Log4Shell (CVE-2021-44228, disclosed 2021-12-09, CVSS 10.0) where the vulnerable library is repackaged, shaded, or relocated inside another artifact so that manifest-based scanning misses it. Google's Open Source Insights team found in December 2021 that over 35,000 Java packages in Maven Central had a dependency on the vulnerable log4j-core, and a meaningful share of those were "shaded" — the log4j classes were physically copied and renamed into the consuming JAR's own namespace (e.g., com.example.shaded.org.apache.logging.log4j) rather than referenced as an external dependency. A tool reading pom.xml sees no log4j entry at all in a shaded build. A BCA engine that fingerprints class files or compiled bytecode inside the JAR by content and structure, rather than by declared coordinates, still identifies the embedded vulnerable version. This is the same reason BCA is standard practice for auditing "fat JARs," statically linked Go binaries, and vendored C libraries.
Where does binary composition analysis get used outside of application security?
Binary composition analysis is used heavily in firmware and IoT security, where vendors ship compiled images with no source access and no manifest at all. Router, camera, and industrial control firmware are typically distributed as a single .bin file containing a compressed filesystem, a Linux kernel, and dozens of statically linked or shared OSS libraries — BusyBox, OpenSSL, dropbear SSH, mbedTLS — with version information stripped to save space. Security researchers and OEM security teams unpack these images (often with binwalk) and run BCA to answer a specific compliance question: does this firmware contain an EOL or CVE-affected version of a library, and does the vendor's stated component list match reality? This same pattern applies to M&A due diligence, where an acquirer needs to know what's inside a target company's shipped binaries when source access is restricted, and to closed-source COTS software procurement, where BCA is often the only way to build an SBOM for a vendor that won't hand one over.
What are the limitations of binary composition analysis?
The main limitation of binary composition analysis is accuracy against heavily modified or optimized code: aggressive compiler optimization, dead-code elimination, symbol stripping, and obfuscation can all remove or alter the exact byte patterns and function hashes that signature-matching depends on, producing false negatives on the components that are hardest to identify by any other means. Version-string matching alone is unreliable too — a vendor can patch a CVE without bumping the version string, so BCA needs to be paired with function-level hash matching (comparing the compiled bytes of known-vulnerable functions specifically) to avoid both false positives and false negatives. BCA also generally cannot recover the full transitive dependency graph the way a lockfile can, since a binary doesn't preserve "which package imported which" relationships — it can tell you a component is present, but reconstructing exact provenance and version pinning intent often still requires build-system context. This is why BCA is treated as a complement to source-based SCA and SBOM ingestion rather than a replacement for either.
How Safeguard Helps
Safeguard combines binary and source-level visibility so security teams aren't stuck choosing between what's declared and what's actually shipped. Safeguard ingests and generates SBOMs across build pipelines, container registries, and third-party artifacts, then layers reachability analysis on top so a flagged component is prioritized by whether the vulnerable function is actually invoked in your call graph — not just present on disk. Griffin AI, Safeguard's investigation agent, correlates binary-derived findings against runtime and code context to cut through false positives from stripped symbols or optimized builds, the same class of noise that plagues signature-based BCA tools. When a real, reachable issue is confirmed, Safeguard can open an auto-fix pull request with the remediated version or patch, closing the loop from detection to a mergeable fix without manual triage.