Skip to main content
As referenced in the use cases section of this document there are some distinct advantages to analyzing post compilation binaries.  With so many of our critical assets we rely on leveraging software packages originating from largely similar supply chain vendors, we often unknowingly inherit issues rooted several layers deep.  This tangled web of commodity code added to dependencies built into packages that are then sold, and built into bigger packages and so on make remediation and mitigation extremely difficult.  Imagine if a very outdated SDK is used to develop drivers that are built into a low level component for a baseboard management controller.  This component and the code to support it will then be provided to an ODM (Original Device Manufacturer) or potentially an IFV or IBV (Independent BOIS Vendor) that may then add more code to it and ship it to an OEM, who again adds to it further and eventually builds it into a server type device.  In this scenario: 
  • You likely have three or more layers of code, that has been compiled and likely recompiled. Source code is simply not available to be assessed
  • A Software bill of materials can be helpful,  however an SBOM  is only a list, and is precisely as accurate,  or inaccurate as the data provided by  your vendor,  and your vendor’s vendor,  and your vendor’s vendor’s vendor.
  • In most cases,  and certainly  in the aforementioned scenario an assessment of the compiled binary is the only available source of truth.
The below table outlines some packages that the Binarly Platfom is often compared against. In many cases we don’t necessarily view these as competitors as our focus and depth of analysis is quite different as outlined.  It should also be noted that features and functionality in our own and other product offerings change, but generally,  this is what we see.  \ Comp Slide Pn