Most of the software an organisation runs arrives as compiled artefacts, and source based scanning cannot tell you what is inside a vendor installer, an appliance image or a device firmware file. Binary software composition analysis (binary SCA) identifies open source and third-party components by examining executables, libraries, packages and firmware directly, then matches them to vulnerability and licence data. This guide covers how binary SCA works, where it is reliable and where it guesses, how to fold it into procurement and vulnerability management, and how to use the results with suppliers. It is written for product security, third-party risk and vulnerability management teams who assess software they did not build. For source and manifest based scanning in your own pipelines, see the Software Composition Analysis (SCA) Guide.
Key takeaways
- Binary SCA produces an "Analyzed" SBOM, the CISA tooling working group's term for an SBOM generated after the build from executables, packages, containers or virtual machine images, and it relies on heuristics.
- It answers a different question from source SCA: what actually shipped, including statically linked libraries, vendored code and components a supplier never declared.
- Accuracy depends on the evidence in the binary. Embedded package metadata (Go build info, Rust cargo-auditable data, package databases) is reliable; version strings and code signatures are approximations that cannot see backported fixes.
- Use it to verify, not to replace, supplier SBOMs. Compare the analysed result with the vendor's SBOM and VEX, and raise differences through the contract rather than acting on raw CVE lists.
- Stay within licence and law. NIST frames binary decomposition as something to do "when technically and legally feasible", so check the licence terms and get legal sign off before unpacking vendor software.
What binary SCA is and when you need it
The CISA facilitated community paper on SBOM types defines six types: Design, Source, Build, Analyzed, Deployed and Runtime. The Analyzed SBOM, sometimes called a "3rd party" SBOM, is generated through analysis of artefacts after the build. CISA lists its benefits as visibility without an active development environment (legacy firmware is the example given), no need for build access, the ability to verify SBOM data from other sources, and the chance to find hidden dependencies other tools miss. The limitations are equally plain: omissions, errors or approximations when the tool cannot decompose the software precisely, and reliance on heuristics.
NIST's guidance on software supply chain security under Executive Order 14028 lists binary decomposition of installation packages to generate SBOMs "if no vendor-supplied SBOM is available (e.g., legacy software), when technically and legally feasible" as an enhancing capability for acquirers, and warns that retroactively generated SBOMs may not reproduce the dependencies used at build time.
| Situation | Why source SCA does not help | What binary SCA adds |
|---|---|---|
| Commercial installers and agents (EDR, backup, VPN clients) | No source or manifest is shared | Inventory of bundled runtimes and libraries such as OpenSSL, zlib, libcurl |
| Network appliances and virtual appliance images | Vendor builds a full operating system you never see | Kernel, BusyBox, web server and crypto library versions |
| IoT, OT and medical device firmware | Supplier may no longer support the build environment | Visibility into legacy components and hard-coded credentials |
| Your own release artefacts | Manifest describes intent, not the shipped file | Catches statically linked or vendored code and build-time injection |
| Supplier provided an SBOM | You cannot tell if it is complete | Independent check of the vendor SBOM before you rely on it |
The last row matters. The XZ Utils backdoor payload sat in release tarballs and binary test files, not in the git source most reviewers read, which is a reminder that the artefact you deploy is the thing to analyse. For how the SBOM and SCA disciplines relate in general, see SBOM vs SCA.
How binary SCA identifies components
Tools combine several techniques. Knowing which one produced a finding tells you how much to trust it.
| Technique | Evidence used | Confidence | Typical blind spot |
|---|---|---|---|
| Package database parsing | dpkg, RPM or apk databases inside an image or root filesystem | High for packaged software | Anything copied in outside the package manager |
| Embedded build metadata | Go module data readable through the standard library's debug/buildinfo; Rust dependency lists embedded by cargo-auditable in a .dep-v0 linker section | High | Binaries built without module mode or without cargo-auditable |
| Archive and manifest unpacking | JAR, WAR, EAR, wheels and lockfiles bundled inside installers | High once unpacked | Nested or proprietary container formats |
| Version string and signature matching | Strings such as library banners, symbol names and known byte patterns | Medium | Backported fixes, stripped binaries, custom forks |
| Code similarity and function hashing | Fingerprints of compiled functions compared with a reference corpus | Medium, varies by tool | Heavy optimisation, different compilers, obfuscation |
| Firmware extraction | Unpacking file systems (SquashFS, UBI, CPIO and similar) and then running the techniques above | Depends on extraction success | Encrypted or signed images that cannot be unpacked |
Two points shape every programme. First, signature matching reports the upstream version it recognises, so a distribution or vendor that backported a fix into an older version still looks vulnerable. The open source cve-bin-tool project says this directly: its checkers only look for library signatures and version numbers. Second, static linking hides components from package based tools. A single Go or C++ executable can contain dozens of libraries with no package record at all, which is exactly where embedded metadata or signature matching earns its place.
Language toolchains are making this easier. Go binaries built in module mode carry the toolchain version and the set of modules used. Rust projects can opt into cargo-auditable, which embeds a compressed JSON dependency list (under 4 kB, according to the project) that cargo audit, grype, osv-scanner, syft and trivy can read. Asking suppliers to build with these options is a cheap contract clause that turns guesswork into evidence.
Tool categories and open source examples
Binary SCA capability appears in several product categories. Open source projects below are listed alphabetically as examples of each approach, not as recommendations; commercial binary analysis platforms cover similar ground with larger signature corpora and supplier workflow features.
| Category | Open source example | What it covers (from project documentation) | Outputs |
|---|---|---|---|
| Binary vulnerability scanner | cve-bin-tool (OpenSSF, GPL-3.0) | Hundreds of library checkers, language manifests, archive extraction (zip, tar, deb, rpm, apk); NVD, OSV, GitLab, Red Hat and curl data | SPDX and CycloneDX SBOMs; CSAF, CycloneDX and OpenVEX triage files |
| Firmware analyser | EMBA (GPL-3.0) | Firmware extraction, static analysis for outdated components, insecure binaries and hard-coded passwords, emulation based dynamic analysis | Web report and SBOM profile |
| SBOM generator for images and file systems | Syft (Apache-2.0) | Container images, file systems and archives across many packaging ecosystems | CycloneDX, SPDX, signed in-toto attestations |
Image scanners overlap with this category for container artefacts; the Container Image Scanning vs SCA page explains that split, and this guide stays with vendor binaries and firmware. For firmware specifically, the Hardware and Firmware SBOM Guide covers the hardware side of the bill of materials.
Choosing where to apply it
- Procurement gate: analyse the evaluation build of high risk software (internet facing, privileged agents, anything handling credentials) before contract signature, so findings become negotiation points rather than surprises.
- Release verification: run binary SCA on your own shipped artefacts and compare with the Build SBOM. Differences point to vendored code, static linking or a compromised build step.
- Legacy and orphaned software: where the supplier has gone or will not provide an SBOM, an analysed SBOM is often the only inventory available.
- Device fleets: for IoT, OT and medical devices, analyse each firmware version once and reuse the result across the fleet rather than scanning devices.
Small organisations: start with the open source tools on the handful of products with the widest privilege and network exposure, and lean on supplier SBOMs for the rest. Large organisations and manufacturers: a commercial platform with a curated signature corpus, supplier portal and VEX workflow usually pays for itself once hundreds of products or firmware versions are in scope.
Legal and contractual guardrails
Unpacking vendor software can conflict with licence terms that restrict reverse engineering or decompilation, and the position varies by jurisdiction. Treat binary SCA as an authorised assessment activity:
- Read the licence or EULA for analysis restrictions, and record legal approval per product or supplier.
- Prefer a contract clause that gives the right to analyse delivered software for security purposes and obliges the supplier to provide SBOM and VEX data.
- Limit analysis to identifying components and known vulnerabilities; do not decompile proprietary logic or redistribute extracted files.
- Store extracted artefacts in a restricted location: firmware often contains keys, certificates and default credentials.
- Report findings to the supplier through its vulnerability disclosure route, not publicly.
The Security for Procurement Teams Guide covers the wider contract terms, and the EU Cyber Resilience Act Guide covers manufacturer SBOM duties in the EU.
Implementing binary SCA: a phased rollout
- Scope (weeks 1 to 2): list third-party software and firmware by exposure and privilege. Pick ten to twenty high risk products and confirm legal approval for each.
- Pilot and baseline (weeks 3 to 6): run analysis on the pilot set, record the identification technique behind each component, and have an analyst validate a sample manually to measure false positives. Do not open tickets yet.
- Compare with supplier data: request each vendor's SBOM and VEX or CSAF advisories. Classify each difference as missing from the vendor SBOM, version mismatch, or likely false positive from signature matching.
- Triage with context: enrich findings with CISA KEV and exploit prediction data, then record decisions as VEX statements so they persist across rescans. cve-bin-tool, for example, can apply a previously edited VEX file to new scans. See the VEX Guide.
- Operationalise: add binary SCA to the procurement checklist and the release pipeline for your own products, store analysed SBOMs alongside supplier SBOMs in your SBOM operations repository, and rescan stored SBOMs as new vulnerabilities are published rather than re-unpacking binaries.
- Roll back safely: if false positive rates swamp the queue, return a product to "inventory only" status (keep the SBOM, stop ticketing) while you tune or request better supplier evidence.
Where identity fits
Firmware and appliance images routinely carry embedded secrets: default accounts, SSH host keys, API tokens and private keys for TLS or update signing. EMBA lists hard-coded passwords among its static checks, and the same extraction step that feeds component identification is the right moment to scan for secrets. Treat any credential found as a non-human identity that needs an owner, rotation path and supplier fix. The How to find hard-coded secrets in container images covers the same detection approach for images.
Detection and measurement
- Coverage: percentage of high risk third-party products with either a validated supplier SBOM or an analysed SBOM.
- SBOM agreement rate: share of components found by binary analysis that also appear in the supplier SBOM; a falling rate signals incomplete supplier data.
- Validated false positive rate: per identification technique, from analyst sampling; use it to decide which findings can raise tickets automatically.
- Time to supplier response: days from raising a finding to receiving a fix, VEX statement or mitigation.
- KEV exposure: count of deployed products with an unresolved KEV listed component, tracked to zero.
Framework mapping
| Framework | Reference | How binary SCA supports it |
|---|---|---|
| NIST CSF 2.0 | GV.SC-07, ID.AM-02, ID.RA-01 | Assess supplier product risk, inventory software, identify vulnerabilities in assets |
| NIST CSF 2.0 | GV.SC-05 | Contract requirements for SBOM, VEX and the right to analyse |
| NIST SP 800-53 Rev. 5 | SA-4, SR-3, SR-4, SR-11 | Acquisition requirements, supply chain controls, provenance and component authenticity |
| NIST SP 800-53 Rev. 5 | CM-8, RA-5 | Component inventory and vulnerability scanning of deployed software |
| ISO/IEC 27001:2022 Annex A | A.5.21, A.8.8 | Information security in the ICT supply chain; management of technical vulnerabilities |
| MITRE ATT&CK | T1195.002, T1195.003 | Compromise Software Supply Chain and Compromise Hardware Supply Chain, the threats artefact analysis helps detect |
Common failure patterns
- Treating every match as a vulnerability: signature based findings ignore backports, so raw CVE lists sent to suppliers damage the relationship and waste time. Validate first.
- Scanning only the source repository: build-time injection, as in the XZ Utils backdoor, lives in the shipped artefact.
- Accepting supplier SBOMs unchecked: without an independent comparison you cannot tell a complete SBOM from a declared intention.
- Analysing without approval: skipping legal review turns a security control into a licence dispute.
- Re-unpacking instead of rescanning: store the analysed SBOM and rescan it against new vulnerability data; re-extraction is slow and may give different results.
- Ignoring encrypted firmware: an image that cannot be unpacked is a finding in itself; ask the supplier for an SBOM rather than recording "no components".
Practitioner checklist
- Rank third-party software and firmware by exposure and privilege, and choose the binary SCA scope.
- Get legal approval per product and add a right to analyse clause to new contracts.
- Record the identification technique and confidence for every component found.
- Validate a sample manually to measure false positives before ticketing.
- Compare analysed SBOMs with supplier SBOMs and log every discrepancy.
- Record triage decisions as VEX so they survive rescans.
- Scan extracted file systems for embedded credentials and keys, and assign owners.
- Ask suppliers to build Go and Rust binaries with embedded dependency metadata.
- Store analysed SBOMs centrally and rescan them as new vulnerabilities appear.
Standards and references
- CISA: Types of Software Bill of Material (SBOM) Documents
- NIST: Software Security in Supply Chains, Software Bill of Materials
- NIST: SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
- OWASP: Software Component Verification Standard
- Go: debug/buildinfo package
- Rust Secure Code Working Group: cargo-auditable
- OpenSSF: CVE Binary Tool
- EMBA: Firmware Security Analyzer
Related NHI Mgmt Group resources: Software Composition Analysis (SCA) Guide · Container Image Scanning vs SCA · SBOM vs SCA · Software Supply Chain Security Guide