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.

Key Takeaways:

• 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.

Why This Paper Matters

Traditional SCA reports intent; attackers exploit reality. The gap between what your manifests say and what your binaries contain is where long-tail risk lives. This paper gives you a practical framework to detect, validate, and remediate those hidden exposures at scale.

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 and ldd.

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.

Who Should Read This

• Security & Product Security: validate “false positives,” cut noise, focus on exploitable risk.

• Platform & DevOps: harden builds; document flags and dependency paths that change binaries.

• Engineering Leadership: require evidence-backed SBOMs that reflect compiled code.

• Procurement/Risk: demand verifiable software inventories from vendors and OEMs.