Your Security Scans Are Missing Critical Vulnerabilities
Most scanners only check manifests, missing the code that’s actually running. This white paper shows how binary analysis uncovers hidden components—like statically linked crypto and vendored libraries—that conventional tools overlook. Learn why manifests reflect intent, not reality, and how to close the gap.
Your Security Scans Are Missing Critical Vulnerabilities
Why This Paper Matters
Manifests Don’t Reflect Reality
Traditional SCA shows declared dependencies, not what is actually compiled into production binaries.
Hidden Risk Lives in the Binary
Long-tail vulnerabilities often exist in compiled components that never appear in source-based reports.
Closing the Gap Between Intent and Execution
Security teams need a repeatable way to detect, validate, and remediate hidden exposures at scale.
Hidden Risks in Your Attack Surface
If you build, secure, or manage software, your current scanners are likely missing significant portions of your real attack surface. Over the last 18 months, NetRise analysis repeatedly uncovered exploitable components absent from SBOMs and system diagnostics—from statically linked crypto to vendored libraries.
- Manifest/SCA tools often miss statically linked and vendored code embedded in executables.
- “Patched” systems can still execute old vulnerable versions inside modules and extensions.
- Build pipelines introduce hidden dependencies via flags, caches, and code generation.
- You need binary composition analysis to know what’s truly running.
From Escalation to Evidence
Security teams challenged our findings. We welcomed it—and proved them out with manual binary forensics:
- OpenSSL 3.0.0 inside Python SSL modules
System packages showed OpenSSL 3.2.x, but Python extensions contained statically linked OpenSSL 3.0.0, leaving CVE-2022-3602/3786 paths open despite “patched” libraries. - rsync shipping a vendored zlib 1.2.8
Package managers reported zlib 1.3.1, yet the rsync binary included a vendored 1.2.8 copy compiled in by default—invisible to manifest checks andldd.
What You’ll Learn in This White Paper
- Why scanners miss real risk
How static linking, vendoring, transitive resolution, build caches, and code generation insert undocumented components into your executables. - How to prove (or disprove) a finding
A field-tested validation playbook: strings/symbol inspection, source cross-checks, and build-flag analysis to turn a “weird result” into actionable evidence. - How to prioritize and fix
Map hidden components to CVEs, confirm exploitability, and drive recompilation or vendor fixes (e.g.,--with-included-zlib=no, Python system-lib flags). - How to operationalize visibility
Why binary composition analysis must augment SBOM/SCA so your inventory, compliance, and response reflect what actually runs.
Why Scanners Miss It (and Attackers Don’t)
- Static linking freezes vulnerable code inside modules—outside dynamic link checks.
- Vendored libraries live inside source trees and binaries, never appearing in manifests.
- Build choices (flags, caches, minimal version selection, hoisting) silently swap versions.
- Code generation creates vulnerable paths that don’t exist pre-compile.
Bottom line: manifests represent intent. Only analyzing compiled artifacts reveals reality.
You might also like
Learn how we helped the customers to reach the next level