Search

US-12625972-B2 - Comparative analysis of binaries for software supply chain security

US12625972B2US 12625972 B2US12625972 B2US 12625972B2US-12625972-B2

Abstract

Comparing how behaviors, functions, and other features have changed between different software versions, embodiments determine how the software has changed between versions and make an assessment as to whether or not the newer version of the software has unintended functionality.

Inventors

  • Andrew Aarne Hendela
  • Eric Hyunjoon LEE, JR.

Assignees

  • KARAMBIT.AI INC.

Dates

Publication Date
20260512
Application Date
20231120

Claims (18)

  1. 1 . A method for identifying a risk level associated with an update to a software product, the method comprising: extracting one or more first features from a first version of the software product; identifying one or more first behaviors, associated with the extracted one or more first features, that can occur when the first version of the software product is executed on a computing device; extracting one or more second features from a second version of the software product; identifying one or more second behaviors, associated with the extracted one or more second features, that can occur when the second version of the software product is executed; comparing the one or more first behaviors with the one or more second behaviors to identify one or more behavioral differences between the first version of the software product and the second version of the software product, wherein the step of comparing the one or more first behaviors with the one or more second behaviors to identify one or more behavioral differences between the first version of the software product and the second version of the software product comprises performing function alignment between functions identified in the first version of the software product and functions identified in the second version of the software product; identifying a risk level associated with the one or more behavioral differences; and outputting an indication of the risk level associated with the second version of the software product to a user; wherein the step of identifying a risk level associated with the one or more behavioral differences further comprises: scoring the one or more behavioral differences by one or both of: (a) reducing a score for each new behavior found in the second version of the software product which was not found in the first version of the software by: (i) a first value if the new behavior is listed in one of one or more malware behavior libraries; or (ii) a second value if the new behavior is not listed in the one of one or more malware behavior libraries; and (b) reducing the score by a third value for each additional instance of the new behavior found in the second version of the software product.
  2. 2 . The method of claim 1 , wherein the first version of the software product is an aggregate of multiple versions of the software product or an aggregate of multiple versions of multiple software products.
  3. 3 . The method of claim 1 , wherein the one or more first features and the one or more second features include one or more of systems calls, strings, arguments to function calls, instructions, and file sections.
  4. 4 . The method of claim 1 , wherein the step of identifying a risk level associated with the one or more behavioral differences further comprises: determining whether the one or more behavioral differences are intended or unintended.
  5. 5 . The method of claim 4 , wherein the step of determining whether the one or more behavioral differences are intended or unintended includes one or both of (a) determining that a behavior is unintended because historic behaviors of the software product do not include this behavior; and (b) comparing a behavior to one or more libraries of malware behaviors.
  6. 6 . The method of claim 1 , wherein the step of identifying a risk level associated with the one or more behavioral differences further comprises: performing an anomaly detection procedure on the one or more second behaviors.
  7. 7 . The method of claim 1 , wherein the step of identifying a risk level associated with the one or more behavioral differences further comprises: performing a lineage analysis of previous versions of the software product and using output from the lineage analysis to score the risk level.
  8. 8 . The method of claim 1 , wherein the step of identifying a risk level associated with the one or more behavioral differences further comprises: performing a cluster analysis of previous versions of the software product and using output from the cluster analysis to score the risk level.
  9. 9 . A non-transitory, computer-readable medium containing computer-readable program code which, when executed on one or more processors, performs the steps of: extracting one or more first features from a first version of the software product; identifying one or more first behaviors, associated with the extracted one or more first features, that will can occur when the first version of the software product is executed on a computing device; extracting one or more second features from a second version of the software product; identifying one or more second behaviors, associated with the extracted one or more second features, that can occur when the second version of the software product is executed; comparing the one or more first behaviors with the one or more second behaviors to identify one or more behavioral differences between the first version of the software product and the second version of the software product, wherein the step of comparing the one or more first behaviors with the one or more second behaviors to identify one or more behavioral differences between the first version of the software product and the second version of the software product comprises performing function alignment between functions identified in the first version of the software product and functions identified in the second version of the software product; identifying a risk level associated with the one or more behavioral differences; and outputting an indication of the risk level associated with the second version of the software product to a user; wherein the step of identifying a risk level associated with the one or more behavioral differences further comprises: scoring the one or more behavioral differences by one or both of: (a) reducing a score for each new behavior found in the second version of the software product which was not found in the first version of the software by: (i) a first value if the new behavior is listed in one of one or more malware behavior libraries; or (ii) a second value if the new behavior is not listed in the one of one or more malware behavior libraries; and (b) reducing the score by a third value for each additional instance of the new behavior found in the second version of the software product.
  10. 10 . The non-transitory, computer-readable medium of claim 9 , wherein the first version of the software product is an aggregate of multiple versions of the software product or an aggregate of multiple versions of multiple software products.
  11. 11 . The non-transitory, computer-readable medium of claim 9 , wherein the one or more first features and the one or more second features include one or more of systems calls, strings, arguments to function calls, instructions, and file sections.
  12. 12 . The non-transitory, computer-readable medium of claim 9 , wherein the step of identifying a risk level associated with the one or more behavioral differences further comprises: determining whether the one or more behavioral differences are intended or unintended.
  13. 13 . The non-transitory, computer-readable medium of claim 12 , wherein the step of determining whether the one or more behavioral differences are intended or unintended includes one or both of (a) determining that a behavior is unintended because historic behaviors of the software product do not include this behavior; and (b) comparing a behavior to one or more libraries of malware behaviors.
  14. 14 . The non-transitory, computer-readable medium of claim 9 , wherein the step of identifying a risk level associated with the one or more behavioral differences further comprises: performing an anomaly detection procedure on the one or more second behaviors.
  15. 15 . The non-transitory, computer-readable medium of claim 9 , wherein the step of identifying a risk level associated with the one or more behavioral differences further comprises: performing a lineage analysis of previous versions of the software product and using output from the lineage analysis to score the risk level.
  16. 16 . The non-transitory, computer-readable medium of claim 9 , wherein the step of identifying a risk level associated with the one or more behavioral differences further comprises: performing a cluster analysis of previous versions of the software product and using output from the cluster analysis to score the risk level.
  17. 17 . A method for identifying a risk level associated with an update to a software product, the method comprising: extracting one or more first features from a first version of the software product; identifying one or more first behaviors, associated with the extracted one or more first features, that can occur when the first version of the software product is executed on a computing device; extracting one or more second features from a second version of the software product; identifying one or more second behaviors, associated with the extracted one or more second features, that can occur when the second version of the software product is executed; comparing the one or more first behaviors with the one or more second behaviors to identify one or more behavioral differences between the first version of the software product and the second version of the software product; identifying a risk level associated with the one or more behavioral differences; and outputting an indication of the risk level associated with the second version of the software product to a user; wherein the step of comparing the one or more first behaviors with the one or more second behaviors to identify one or more behavioral differences between the first version of the software product and the second version of the software product further comprises: performing function alignment between functions identified in the first version of the software product and functions identified in the second version of the software product by: generating a Term Frequency-Inverse Document Frequency (TF-IDF) vector from position-independent code hashes of each function and each block, position dependent code hashes of each function and each block, function name, function identifier, number of blocks in the function, and the number of instructions in the function; and using k-nearest neighbors with cosine similarity to determine which functions between the first version and the second version are most alike.
  18. 18 . A non-transitory, computer-readable medium containing computer-readable program code which, when executed on one or more processors, performs the steps of: extracting one or more first features from a first version of the software product; identifying one or more first behaviors, associated with the extracted one or more first features, that can occur when the first version of the software product is executed on a computing device; extracting one or more second features from a second version of the software product; identifying one or more second behaviors, associated with the extracted one or more second features, that can occur when the second version of the software product is executed; comparing the one or more first behaviors with the one or more second behaviors to identify one or more behavioral differences between the first version of the software product and the second version of the software product; identifying a risk level associated with the one or more behavioral differences; and outputting an indication of the risk level associated with the second version of the software product to a user wherein the step of comparing the one or more first behaviors with the one or more second behaviors to identify one or more behavioral differences between the first version of the software product and the second version of the software product further comprises: performing function alignment between functions identified in the first version of the software product and functions identified in the second version of the software product by: generating a Term Frequency-Inverse Document Frequency (TF-IDF) vector from position-independent code hashes of each function and each block, position dependent code hashes of each function and each block, function name, function identifier, number of blocks in the function, and the number of instructions in the function; and using k-nearest neighbors with cosine similarity to determine which functions between the first version and the second version are most alike.

Description

RELATED APPLICATION This application claims priority from, and incorporates by reference, U.S. Provisional Patent Application No. 63/427,965, entitled “Comparative Analysis of Binaries for Software Supply Chain Security”, filed on Nov. 25, 2022. TECHNICAL FIELD Some embodiments of the subject matter disclosed herein generally relate to methods and systems for performing comparative analysis of software to determine whether, for example, updates or new versions of software are malicious or benign. BACKGROUND The SolarWinds software supply chain attack compromised 18,000 organizations of all sizes and caused billions of dollars in damage. This attack exploited the trust consumers have in their third-party suppliers. The attackers added malicious code, not in the software repository, but within a compromised build system. The current state of the art in this area focuses on finding vulnerabilities, understanding the composition of the software, or prohibitively expensive manual analysis. Methods to understand the composition of software, known as Software Composition Analysis (SCA), lead to the creation of a Software Bill of Materials (SBOM). Current cyber risk management policies revolve around SBOM. An SBOM is a list of components in a piece of software, analogous to the ingredients list for food products. Executive Order 14028 and FDA requirements (FDA 2023) mandate the adoption and production of SBOMs for federal government vendors and internet-connected medical device manufacturers, respectively. Yet, the basic level of understanding provided by SBOM techniques has severe limitations. For example, SBOMs provide a list of components but not the other information required for cyber risk assessment. Critically, SBOMs are incapable of answering the cyber risk question posed above: simply knowing the present vulnerabilities and software components cannot determine the live impact of the final software deliverable. Further necessary information would include those components' vulnerability, functionality, and behavior information. Understanding vulnerability information is a use case for SBOMs and the related concept of the Vulnerability Exploitability exchange (VEX). By linking known vulnerabilities with SBOMs, end users can know the potential harm of a software exploit. However, only linking with known vulnerability databases often leads to false positives that waste precious cyber analyst time and attention. For example, the 60 known false positives within Grype in August 2023, the open-source vulnerability scanner, show this problem with false positives using conventional techniques. The SolarWinds attack mentioned above is another salient example of the deficiencies of SBOM and vulnerability approaches since SBOMs and vulnerability analysis only provide knowledge of vulnerabilities that may be exploited by an attacker. Accordingly, it would be desirable to create systems, devices, methods, and software applications that overcome these, and other, drawbacks and problems associated with conventional software analysis. SUMMARY According to an embodiment, comparing how behaviors, functions, and other features have changed between different software versions, embodiments determine how the software has changed between versions and make an assessment as to whether or not the newer version of the software has unintended functionality. According to an embodiment, a method for identifying a risk level associated with an update to a software product includes extracting one or more first features from a first version of the software product; identifying one or more first behaviors, associated with the extracted one or more first features, that can occur when the first version of the software product is executed on a computing device; extracting one or more second features from a second version of the software product; identifying one or more second behaviors, associated with the extracted one or more second features, that can occur when the second version of the software product is executed; comparing the one or more first behaviors with the one or more second behaviors to identify one or more behavioral differences between the first version of the software product and the second version of the software product; identifying a risk level associated with the one or more behavioral differences; and outputting an indication of the risk level associated with the second version of the software product to a user. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments. In the drawings: FIG. 1 is a block diagram depicting a method and a system for comparative analysis of binaries according to embodiments; FIGS. 2A-2D illustrate various aspects associated with feature and behavior extraction from a good or known sample of a software product according to embo