> ## 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. # Binary vs. source scanning > How binary scanning compares to source-code scanning across different SDLC security approaches. 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.