How SourceGuard finds vulnerabilities in a compiled binary
Disassembly, intermediate representation, simulated execution, and signature comparison — in four stages, with no source code and no reliance on version metadata
The method
The engine first disassembles the target binary and converts its executable instructions into a structured intermediate representation. That lets us analyse program behaviour rather than version strings or file fingerprints
Building on that representation, the analysis engine simulates key execution paths to extract stable behavioural and structural features. Those features are compared against reference signatures in VulSource — both vulnerable and remediated patterns — so the platform can determine whether the observed binary more closely matches an unpatched state, a fixed state, or a state that was never vulnerable
This matters most where version metadata is incomplete, altered or unreliable — vendor firmware, statically linked libraries, backported patches. By reading what the binary contains and how it behaves, precision improves and both false positives and false negatives fall
A version number is a claim,
the instruction stream is the evidence

Evidence
Vulnerable and patched, side by side
The matched region is shown in both states, so an engineer can confirm the finding — and a vendor can be shown exactly what still needs fixing
