What Package Manifests Miss: Deep Binary Scanning for Container Images

Binary composition analysis identifies the open-source components actually compiled into a container image - not just what a manifest declares - and KhaiCode produces a verified SBOM plus exploitability assessment from the binary itself, without access to source code.

Container security programs often start with the manifest. You scan package.json, requirements.txt, or the layer metadata that a registry exposes, and you get a list of declared dependencies. That list is useful. It is also incomplete - sometimes significantly so.

The gap matters most when you are deciding whether a container image is safe to ship or promote to production. If your SBOM only reflects what a developer typed into a dependency file, you are flying partially blind on what actually got compiled in.

Why Manifests Are Not the Full Picture

Package manifests describe intent. They record what a build system was asked to include. They do not always describe outcome.

Several common patterns produce a gap between the two:

• Vendored dependencies. A team copies a library's source directly into the repo instead of pulling it through a package manager. The copied code is compiled into the binary. No manifest entry.
• Statically linked components. Compression libraries, cryptographic routines, and parsing code are frequently linked statically into a final binary. After linking, there is no package-manager artifact left to scan.
• Build-time tools baked in. Containerized environments sometimes capture build tooling - compilers, test runners, CLI helpers - in a layer that never gets stripped.
• Third-party or proprietary binaries dropped in. A base image from a vendor or an upstream team may include pre-compiled components with no corresponding source or manifest in your control.
• Outdated base images with known-bad versions. A base image's declared package list can lag the actual library versions present on disk after in-place updates during image construction.

None of these gaps are theoretical. They show up routinely in real container builds, and they carry real CVEs and KEVs that a manifest-only scan will not surface.

What Deep Binary Scanning Actually Does

Instead of reading the manifest, binary scanning reads the compiled artifact itself. The scanner reverse-engineers the binary - in this case, a container image or its constituent layers - and identifies the libraries and components embedded inside.

KhaiCode's approach works like this in practice:

1. Upload the binary. You submit the container image or firmware artifact. No source code is required at any point.
2. Fingerprint and SBOM generation. KhaiCode analyzes the binary to identify embedded libraries, generates an SBOM in SPDX or CycloneDX format, and correlates findings against CVE and KEV databases.
3. Exploit validation. This is the step that separates binary-first analysis from a standard SCA scan. KhaiCode uses an exploit template database and proprietary attack-path analysis to assess whether a vulnerable component can actually be reached and exploited - not just whether the version number matches a CVE entry.

That third step matters for prioritization. A container image may contain dozens of libraries with CVE hits. The question you actually need answered is: which of these can an attacker demonstrate exploitability against in this specific binary, in this specific build configuration? Exploit-based validation narrows that list to what genuinely needs immediate action.

How This Fits Alongside a Source-Based SCA Tool

Binary scanning is not a replacement for source-based SCA. It answers a different question at a different point in the pipeline.

Source-based SCA (Labrador, for example) catches vulnerable dependencies during development, before a build, when a developer can act on findings fastest. Binary scanning catches what actually ended up in the artifact after the build, including the components no manifest ever mentioned.

For teams that own their own source code and ship containers, both have a role. For teams evaluating a third-party container - a vendor-supplied base image, an acquired software asset, an open-source distribution you do not build yourself - binary scanning may be the only viable tool, because source code simply is not available.

KhaiCode is designed for exactly that scenario. The analysis is binary-first by design, covering software, firmware, and container workloads across IT and OT environments.

Practical Implications for a Container Security Review

If you are reviewing your container pipeline with an eye toward SBOM completeness, a few questions are worth asking:

• Do any of your images include statically linked C/C++ libraries that your language-level package manager does not track?
• Are you pulling base images from an upstream vendor or public registry that you did not build yourself?
• Does your current tooling produce an SBOM from the compiled image, or from the source tree that produced it?
• When a CVE fires, can your tooling tell you whether the vulnerable code path is actually reachable in the binary you are shipping?

If the honest answer to any of these is "no" or "not sure," your SBOM and your vulnerability findings carry more uncertainty than they appear to.

A Harder Standard for SBOM Completeness

Regulatory and procurement pressure around SBOM quality is increasing. An SBOM that reflects only declared dependencies is easier to produce - and easier to dispute. An SBOM derived from the binary artifact itself is harder to argue with, because it describes what is actually present in what you shipped.

Deep binary scanning is what closes that gap. KhaiCode surfaces the components that did not show up in any manifest, correlates them against active exploit data, and produces a machine-readable SBOM your security and compliance teams can use.

If you want to see what is actually inside your container images, the starting point is a binary analysis demo at khaicode.com.

Published 5 November 2026

This post is about KhaiCode.