Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.binarly.io/llms.txt

Use this file to discover all available pages before exploring further.

Source-code scanning and binary scanning solve different problems. Understanding where each one applies — and where each one falls short — is the starting point for building a complete picture of what’s actually in your software.

​
Without security checks

SDLC pipeline with no security checks: code flows from development through build to release without any vulnerability scanning stage An SDLC without binary security checks ships software without inspecting third-party components, precompiled binaries, or transitive dependencies — the categories most likely to carry inherited vulnerabilities. Supply chain attacks, unpatched CVEs, and compliance failures are the direct result.

​
Source code scanning

SDLC pipeline with source code scanning applied to first-party code, leaving precompiled third-party components unanalyzed Source code scanning validates first-party code for vulnerabilities such as injection flaws, buffer overflows, and insecure configurations. It only works on code accessible to the development team. Many components — third-party dependencies, vendor-supplied libraries, firmware blobs — arrive as precompiled binaries with no source available. If a vulnerable library has no source, the scanner has nothing to analyze. The vulnerability ships undetected.

​
SDLC with binary scanning – closing the gaps

SDLC pipeline with binary scanning at the post-build stage, covering first-party and third-party compiled components together Binary scanning starts from the compiled artifact — the thing that actually runs. It doesn’t depend on source code access or vendor-supplied metadata. The Binarly Transparency Platform scans compiled binaries, including third-party and transitive dependencies, and analyzes them directly. This approach covers categories of software that source-code scanning structurally cannot reach:
  • Statically linked libraries compiled into the binary without a corresponding package manifest entry
  • Precompiled third-party components where source code was never available to the buyer
  • Backported patches where a vendor fixes a CVE without changing the version number, making version-based matching wrong in both directions
  • Proprietary and closed-source components, including drivers, firmware blobs, and vendor-supplied modules
Binary scanning integrates at the post-build stage, after all components have been compiled and linked. Security teams scan the final artifact — first-party and third-party code together — without requiring access to the original source. This makes it a practical complement to source-code scanning, covering the portions of the supply chain that source analysis cannot reach.