.webp)
At Binarly, our research and product teams have been working diligently to develop and refine the Binarly Transparency Platform v2.0. Our primary focus has been enhancing and strengthening the powerful capabilities and framework that were introduced earlier this year. In that release we launched the Binary Risk Intelligence Core, designed to prevent software supply chain attacks effectively. Our detection of the XZ utils backdoor showcased our next-generation approach to tackling such threats. Leveraging this technology, we released a free scanner for generic detection of all modifications related to the XZ utils incident in less than 24 hours -- weeks ahead of others in the industry!
In this latest product iteration, the Binarly team focused on prioritization of detection results and addressing the complex problems related to the discovery of new security risks to support secure-by-design practices. In large enterprise organizations, the complexity of modern software often results in hundreds of thousands of alerts and identified issues. The key question is how to address these and focus on what truly matters. Most legacy solutions rely on industry best practices for prioritization, such as Exploit Prediction Scoring System (EPSS) and Stakeholder-Specific Vulnerability Categorization (SSVC). However, we believe these approaches are insufficient. Both metrics do not focus primarily on code analysis and provide only additional insights based on metadata analysis from external sources related to a specific security problem.
But what if the discovered vulnerability isn’t exploitable in a specific environment and the detection leads to false positives where EPSS or SSVC won’t provide the necessary clarity?
That’s precisely why we’ve chosen a different approach to address this complex industry problem with a real solution: the industry’s first Binary Reachability Analysis. Binarly Reachability Analysis technology is a patent-pending approach, developed by the best minds in the industry, that focuses on program analysis and software supply chain security issues. This technology and approach offer greater clarity for making remediation and mitigation decisions, as well as more efficient allocation of resources to support these efforts.
Reachability analysis is the holy grail of risk prioritization. Finding vulnerabilities or security risks is always important, but how do you prioritize thousands of similar signals across software and firmware assets? That's where alert-fatigue takes hold and attackers gain the upper hand. Things are getting worse with transitive dependencies and statically linked code. In the end, an SBOM is only useful if it's actionable.
Most Software Composition Analysis (SCA) tools only focus on scripting languages. They simplify analysis and focus on easy targets where source code is available, mainly estimating reachability path analysis to the vulnerable code pattern. However, when it comes to compiled languages, specifically C/C++ or others, many program components could be defined during compilation and provide algorithmic complexity to be solved on the source code level. This creates a significant challenge in implementing a robust approach for reachability analysis on the compiled binaries, as this requires a comprehensive binary code analysis technology. In our previous release, we raised the bar on code analysis with the introduction of our Binary Risk Intelligence technology. Today, we are extending this technology to the next frontier of the state-of-the-art advancements in the program analysis field.
Solving reachability analysis on the binary level is very difficult. It requires a significant investment in the comprehensive internal development of program analysis tooling. Today we are introducing our customers to a new groundbreaking advancement in our Binary Risk Intelligence technology, solving the prioritization dilemma for defenders at scale with reachability analysis on a binary level without requiring access to the source code.
In the figure below, you can see how building a call graph to a target function requires recovering complex relationships between all the various entities defining the reachable path to the function, but there could be a lot of contextual nuances applied.
Binarly is introducing support for call-graph reachability metrics that will report how a given finding (vulnerability) can be reached within a given binary. We are defining different shades of the reachability analysis depending on the kind of “entrypoint” a given finding is reachable from.
Direct – a path in the call graph exists from the original entrypoint to the finding location. This covers the most obvious kind of reachability and is reported when the finding location and the original entrypoint of the analyzed binarly are directly connected by either an inter-procedural or intra-procedural path. We refer to this as “entrypoint” reachability.
Exported - covers indirect reachability to exported functions from third-party components or external library code. For example, for BMC firmware or a Linux container that contains shared libraries, we assume exported functions are viable entry points, and if a finding is reachable from an exported function, then we report it as “exported” reachability. For UEFI, we consider identified SMI handlers, functions in registered protocol interfaces and PPIs, and so on, as if they are exports.
Referenced – covers cases where a finding is reachable because it is referenced from code that is reachable by direct or exported reachability. This covers cases where we believe a finding is reachable because it is referenced from code that is reachable by direct or exported reachability, but we are unable to determine the exact reachability statically.
Undetermined – covers the cases where reachability was unable to be determined.
Another important and powerful feature of this product update is the introduction of custom semantic detection rules. Product security teams can now develop the detection of the vulnerabilities that are discovered internally before the external release which may never have an assigned CVE. This allows the enterprise security teams to focus on hunting the broader scope of the security risks across their software assets.
Reachability Analysis is included by design in the detection rules and helps with prioritization and a full understanding of the software supply chain relationships between these discoveries.
The custom rule detection also includes comprehensive details regarding code artifacts associated with the semantic rule and shows the code patterns in pseudo-code representation.
This release adds more mitigation checks focused on hardening code, executable files, and the Linux kernel. This adds to the Weak Binaries feature that detects the usage of unsafe C/C++ functions inside the code and warns of potential Secure Development Lifecycle (SDLC) policy and Secure-by-Design practices failures.
The Weak Binaries feature will help to scope the problems related to CWE-477 (Use of Obsolete Function) and CWE-676 (Use of Potentially Dangerous Function) more proactively and fix the potential insecure places before they become exploitable vulnerabilities.
Identifying an unsafe function is meaningless if it isn’t actually present in the code or if there isn’t enough evidence to validate the findings. The presence of functions like memcpy() and other unsafe C/C++ functions does not automatically indicate presence of security vulnerabilities. However, their use introduces risk and could violate contractual SDLC requirements, which is why it’s crucial to have the capability to validate and prevent such issues proactively.
In the previous release, we introduced the first iteration of the discovery of Cryptographic Materials. This time, we are significantly improving the quality of the detection of cryptographic assets and implementing more comprehensive discovery of the cryptographic algorithms used in the code. Such functionality is critical for providing the complete Cryptographic Bill of Materials (CBOM) for software and firmware assets.
Recently, the National Institute of Standards and Technology (NIST) rolled out new guidance on Post-Quantum Encryption. So, what does this mean for enterprises and software developers? This highlights an immediate need to identify and scope software assets and cryptographic algorithms requiring replacement. To effectively address this challenge, we must leverage advanced solutions capable of analyzing binaries with deep code inspection and pinpointing at-risk software assets.
That’s why CBOM is playing one of the key roles in the Post-Quantum migration process.
The last feature relates to powerful improvements in our scanner for Docker containers. The Binarly research and product teams worked hard to improve the detection capabilities and provide more data points and evidence for effective remediation and prioritization of the most important security risks.
One of the core new features in this release is Secrets discovery. With this addition to the platform, we are able to detect exposed secrets such as 0Auth Credentials, JWT tokens, encryption keys and API credentials.
The Binarly team is always evolving and focused on delivering the best product on the market through advanced security research and continued innovations. Join us on the mission to solve the repeatable failures in software supply chain security.
.svg)
