System and methods for detecting security vulnerability fixes

Abstract

A method for detecting vulnerability fixes in software code is disclosed. A source code file containing source code is obtained. The source code file may, for example, be one of the files of a source code commit. The code changes associated with the file are determined, the code changes indicating differences between a previous version and a current version of the source code. Based on the code changes, a first code representation of the previous version of the source code and a second code representation of the current version of the source code are determined. A first embedding of the first code representation and a second embedding of the second code representation are obtained. By computing a distance between the first and second embeddings, a file-level code change representation for the source code is determined, and the source code file is classified based on the file-level code change representation.

Description

SYSTEM AND METHODS FOR DETECTING SECURITY VULNERABILITY FIXESTECHNICAL FIELD

[0001] The present application relates to computer security and, more particularly, to a system and methods for automated detection of vulnerability fixes in computer software.BACKGROUND

[0002] Early detection and repair of vulnerabilitiesthat are introduced into software is crucial for securing a computer system running the software. When a vulnerability is discovered (e.g., by a software vendor or a third-party) , it is generally disclosed to the public such that suitable steps can be taken by users of the software to prevent malicious actors from exploiting the vulnerability. In particular, a vulnerability may be disclosed immediately upon discovery (full disclosure) or disclosed only after the responsible parties have been allowed sufficient time to patch or remedy the vulnerability (coordinated disclosure) .BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Embodiments are described in detail below, with reference to the following drawings:

[0004] FIG. 1 is a schematic diagram illustrating an example configuration of a computing environment;

[0005] FIG. 2A is high-level schematic diagram of an example computing device;

[0006] FIG. 2B shows a simplified organization of software components stored in a memory of the example computing device of FIG. 2A;

[0007] FIG. 3 shows, in flowchart form, an example method for automated detection of vulnerability fixes in computer software;

[0008] FIG. 4 shows, in flowchart form, another example method for automated detection of vulnerability fixes in computer software;

[0009] FIG. 5 is a schematic diagram illustrating exemplary training and inference processes associated with automated detection of vulnerability fixes in computer software.

[0010] Like reference numerals are used in the drawings to denote like elements and features.

[0011] DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS

[0012] In an aspect, the present disclosure describes a computer-implemented method for detecting vulnerability fixes in software code. The method may include: obtaining at least one source code file containing source code; determining code changes associated with the at least one source code file, the code changes indicating differences between a previous version of the source code and a current version of the source code; determining, based on the code changes, a first code representation of the previous version of the source code and a second code representation of the current version of the source code; obtaining, via a first embedding model, a first embedding of the first code representation; obtaining, via a second embedding model, a second embedding of the second code representation; determining a file-level code change representation for the at least one source code file based on a computed distance between the first embedding and the second embedding; and performing classification of the at least one source code file based on the file-level code change representation.

[0013] In some implementations, each of the first embedding model and the second embedding model may be a text embedding model and the first embedding model may be different from the second embedding model.

[0014] In some implementations, determining the file-level code change representation for the at least one source code file may include performing element-wise vector subtraction of the first and second embeddings.

[0015] In some implementations, determining the code changes associated with the at least one source code file may include identifying at least one of: lines of code deleted from the previous version of the source code; or lines of code added in the current version of the source code.

[0016] In some implementations, determining the first and second code representations may include identifying surrounding context lines of source code associated with the at least one of the deleted code lines or added code lines, and the first code representation may comprise a combination of the deleted code lines and the surrounding context lines of source codeand the second code representation may comprise a combination of the added code lines and the surrounding context lines of source code.

[0017] In some implementations, identifying the surrounding context lines of source code may include: for each of the deleted code lines, identifying a first number of code lines preceding the deleted code line and a same number of code lines following the deleted code line in the previous version of the source code; andfor each of the added code lines, identifying the first number of code lines preceding the added code line and a same number of code lines following the added code line in the current version of the source code.

[0018] In some implementations, performing classification of the at least one source code filemay include: determining, based on the file-level code change representation, a file-level probability that the at least one source code file contains a vulnerability fix; andcomparing the probability against a defined threshold value.

[0019] In some implementations, the at least one source code file may include a plurality of files associated with a source code commit to a code repository and performing classification of the at least one source code file may include: determining the file-level probability for each of the plurality of files;  andaggregating all file-level probabilities across the plurality of files associated with the source code commit to obtain a commit-level prediction result.

[0020] In another aspect, the present disclosure describes a computer-implemented method for training a machine learning model. The method may include: determining code changes associated with an input source code file, the code changes indicating differences between a previous version of the source code and a current version of the source code; determining, based on the code changes, a first code representation of the previous version of the source code and a second code representation of the current version of the source code; obtaining, via a first embedding model, a first embedding of the first code representation; obtaining, via a second embedding model, a second embedding of the second code representation; determining a file-level code change representation for the input source code file based on a computed distance between the first embedding and the second embedding; and performing classification of the input source code file based on the file-level code change representation.

[0021] In another aspect, a computing system is disclosed. The computing system includes a processor and memory coupled to the processor. The memory stores computer-executable instructions that, when executed by the processor, configure the processor to: obtain a source code file containing source code; determine code changes associated with the source code file, the code changes indicating differences between a previous version of the source code and a current version of the source code; determine, based on the code changes, a first code representation of the previous version of the source code and a second code representation of the current version of the source code; obtain, via a first embedding model, a first embedding of the first code representation; obtain, via a second embedding model, a second embedding of the second code representation; determine a file-level code change representation for the source code file based on a computed distance between the first embedding and the second embedding; and perform classification of the source code file based on the file-level code change representation.

[0022] In another aspect, embodiments of this disclosure provide a computer readable storage medium, comprising one or more instructions, wherein when the one or more instructions are run on a computer, the computer performs any of the methods disclosed herein.

[0023] In another aspect, embodiments of this disclosure provide a non-transitory computer-readable medium storing instruction the instructions causing a processor in a device to implement any of the methods disclosed herein.

[0024] In another aspect, embodiments of this disclosure provide a device configured to perform any of the methods disclosed herein.

[0025] In another aspect, embodiments of this disclosure provide a processor, configured to execute instructions to cause a device to perform any of the methods disclosed herein.

[0026] In another aspect, embodiments of this disclosure provide an integrated circuit configure to perform any of the methods disclosed herein.

[0027] According to one aspect of this disclosure, there is provided a module comprising: one or more circuits for performing any of the methods disclosed herein.

[0028] According to one aspect of this disclosure, there is provided an apparatus comprising: one or more processors functionally connected to one or more memories for performing any of the methods disclosed herein.

[0029] According to one aspect of this disclosure, there is provided an apparatus configured to perform any of the methods disclosed herein.

[0030] In some embodiments the apparatus comprises one or more units configured to perform the above-described method.

[0031] According to one aspect of this disclosure, there is provided one or more non-transitory, computer-readable storage media comprising computer-executable instructions, wherein the instructions, when executed, cause at least one processing unit, at least one processor, or at least one circuits to perform any of the methods disclosed herein.

[0032] According to one aspect of this disclosure, there is provided one or more computer-readable storage media storing a computer program, wherein, when the computer program is executed by an apparatus, the apparatus is enabled to implement any of the methods disclosed herein.

[0033] According to one aspect of this disclosure, there is provided a computer program product including one or more instructions, wherein, when the instructions are executed by an apparatus, the apparatus is enabled to implement any of the methods disclosed herein.

[0034] According to one aspect of this disclosure, there is provided a computer program, wherein, when the computer program is executed by a computer, an apparatus is enabled to implement any of the methods disclosed herein.

[0035] According to one aspect of this disclosure, there is provided a system comprising a node for performing any of the methods disclosed herein.

[0036] Other aspects and features of the present application will be understood by those of ordinary skill in the art from a review of the following description of examples in conjunction with the accompanying figures. Example embodiments of the present application are not limited to any particular operating system, system architecture, mobile device architecture, server architecture, or computer programming language.

[0037] In the present application, the term “and / or” is intended to cover all possible combinations and sub-combinations of the listed elements, including any one of the listed elements alone, any sub-combination, or all of the elements, and without necessarily excluding additional elements.

[0038] In the present application, the phrase “at least one of …or…” is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any sub-combination, or all of the elements, without necessarily excluding any additional elements, and without necessarily requiring all of the elements.

[0039] Coordinated vulnerability disclosure (CVD) is a vulnerability disclosure model in which a vulnerability, such as a hardware or software bug, is disclosed to the public only after the responsible parties (e.g., a vendor, researchers, etc. ) have been given the opportunity to diagnose and offer fully tested updates,  workarounds, or other corrective measures. The involved parties may coordinate and negotiate a reasonable period of time for fixing the vulnerability. The existence of the vulnerability and its mitigations are disclosed to various stakeholders, including the general public.

[0040] In the context of open-source software (OSS) , CVD generally includes three phases. In the first phase, an identified vulnerability is fixed silently and secretly. The vulnerability fix is committed to a public code repository associated with the OSS. After the fix is integrated into a new release of the OSS, the vulnerability is disclosed via published security advisories, in the second phase. For example, security vulnerabilities in open-source software projects may be reported on a vulnerability disclosure platform (or other public sources of vulnerability information) . Users of the OSS, including entities that provide software products with open-source dependencies, rely on the advisories to learn of vulnerabilities and their fixes. In particular, OSS users may monitor the disclosure platform for information on new vulnerabilities. In the third phase, a vulnerability fix (e.g., a software patch) is applied to products or services having dependencies on software with the identified vulnerability. Failure to timely address a vulnerability can result in serious consequences for OSS users.

[0041] A silent fix of a vulnerability often goes unnoticed or ignored initially. OSS users typically do not monitor every source code commit to a code repository or undertake to identify silent fixes by analyzing code changes associated with commits. As a result, software patches for repairing a vulnerability may be applied to products / services only after public disclosure of the vulnerability. This creates the potential for malicious actors to “attack” software that have open-source dependencies. For example, a third-party attacker may infer a vulnerability in an open-source software project by monitoring source code commits made to a public repository associated with the project. If the attacker detects a vulnerability fix in the code changes of a commit, they may exploit the vulnerability by launching an attack, such as a denial-of-service attack, malware injection, privilege escalation, etc., on a software product or service. The time window between a commit of vulnerability-fixing source code and the eventual application of a software patch by OSS users represents a period of time during which the software product / service is exposed to attack.

[0042] Previous approaches to mining silent vulnerability fixes have produced mixed results. The existing solutions use either insufficient information (e.g., only the added and removed code of a commit, without consideration of surrounding context code) or redundant information (e.g., multiple granularities of code changes) to learn code change patterns from source code commits. Furthermore, these solutions oversimplify the task of representing code changes of commits. For example, code changes may be represented as a combination (e.g., concatenation) of added and removed code into a single sequence. Such representations are not well-suited to capture nuanced information from the code changes.

[0043] The present application discloses a system for automated detection of vulnerability fixes in software. More particularly, a machine learning model that is capable of identifying silent vulnerability fixes in source code with improved accuracy rate is proposed. The proposed vulnerability fix detection model can be deployed in various products and services to enhance the security of software projects relying on open-source dependencies. For example, the vulnerability fix detection model may be integrated into a dependency management system for an organization’s software projects. The dependency management system may include a module that automatically scans the dependencies associated with a project (for example, dependencies listed in the project’s configuration files) . Upon detecting updates or changes in the dependencies, the module may  identify code changes associated with the updates from the relevant open-source repositories. The model captures the nuanced changes in the source code and classifies them to determine whether they constitute a vulnerability fix. If a potential vulnerability fix is detected, the dependency management system is configured to notify the development team such that they may review and address the issue before integrating the update into their product.

[0044] Additionally, or alternatively, the vulnerability fix detection model may be deployed as part of a standalone security monitoring service that continuously monitors open-source repositories for silent vulnerability fixes. The security monitoring service may operate independently of an organization’s internal development processes, focussing on the broader ecosystem of open-source projects that might be used as dependencies. The service regularly scans commits in open-source repositories, identifying code changes and classifying the changes to detect potential vulnerability fixes. When a silent vulnerability fix is identified, the service may update its database and alert subscribing organizations whose products depend on the affected open-source components. In this way, the service provides a proactive layer of security, enabling organizations to timely respond to vulnerabilities in their dependencies without needing to integrate a vulnerability detection algorithm directly into their CI / CD pipelines.

[0045] Training data for the vulnerability fix detection model comprises input files containing source code. When an input source code file is processed, file-level code changes to the source code are determined. The code changes are in the form of added code (i.e., code that has been added in the current version of the source code) and / or removed code (i.e., code that was deleted from the previous version of the source code) . Using the code change information, context-preserving code change constructions are generated. Specifically, the context-preserving code change constructions include a first code representation that represents the source code before the code changes and a second code representation that represents the source code after the code changes.

[0046] In at least some implementations, the first and second code representations each include an indication of specific code changes (i.e., code lines removed and / or added) as well as surrounding context source code. For each instance of code change in the source code, the surrounding context source code comprises a defined number of lines of code preceding and following the code change. The number of lines, or “context size” , may be manually set prior to training.

[0047] The context-preserving code change constructions are used to train the vulnerability fix detection model. In particular, the first code representation and the second code representation are used to obtain a “code delta representation” which captures the differences between the previous and current versions of the source code based on their latent space characteristics. In at least some implementations, each of the first and second code representations are inputted to a respective code embedding model, such as a text embedding model (e.g., Word2Vec) , to obtain a first and second embedding, respectively. Two separate code embedding models are employed, one for each of the first and second code representations. The use of separate embedding models increases the number of parameters that can be tuned and allows each model to specialize without interference, thereby enhancing the nuance capture between the code representations. The code delta representation may be obtained by computing a distance between the first and second embeddings using a suitable distance metric. For example, the code delta representation may be derived based on performing element-wise subtraction of  the first and second embeddings. The semantic relationship of the code changes can be captured using vector subtraction in the embedding space.

[0048] The code delta representation that is obtained based on the first and second embeddings is then provided as input to a neural network (e.g., a feed-forward network) which connects to a classification head. The vulnerability detection model’s code embedding and classifier may be trained simultaneously to optimize performance. The vulnerability fix detection model is trained on file-level, but supports both file-and commit-level detection of vulnerabilities. In particular, for any commits that contains multiple source code files, an aggregation algorithm may be implemented to combine all of the file-level vulnerability fix prediction results for the purpose of making a commit-level prediction.

[0049] Reference is first made to FIG. 1, which is a schematic diagram illustrating an example configuration of an operating environment. FIG. 1 illustrates exemplary components of a computing system 100 for managing security of software projects. As a specific example, the computing system 100 may comprise a dependency management system for monitoring and managing open-source dependencies within an organization’s software projects. As another example, the computing system 100 may comprise a security monitoring service that is configured to monitor public code (e.g., open-source) repositories and notify organizations regarding potential vulnerabilities in their dependencies.

[0050] The computing system 100 includes client devices 110, a version control server 130, a data store 135 associated with the version control server 130, and a security management system 140. As shown in FIG. 1, the computing system 100 includes a version control server 130. The version control server 130 is associated with a specific software project (or projects) , and tracks and manages changes made to source code and other files associate with the project (s) . In particular, the version control server 130 is associated with a version control system that automates control of computer files, primarily source code text files, and versions of files. The version control server 130 automates revision control operations (such as file locking, version merging, and the like) , tracks changes to configuration files, accounts for ownership of changes to code, etc. The version control server 130 may use either a distributed model or a centralized model.

[0051] The version control server 130 is communicably coupled to a data store 135. The data store 135 is a data structure that stores metadata for a set of files or directory structure. In at least some implementations, the data store 135 comprises a source code repository. The data store 135 may be a storage location for code and other software development assets, such as documentation, tests, and scripts. The data store 135 may contain, inter alia, a historical record of changes in the data store 135, a set of commit objects, and a set of references to commit objects (i.e., heads) .

[0052] The security management system 140 is a computer system associated with an organization and its software projects. In particular, the security management system 140 is configured to perform operations relating to assuring security in software development. By way of illustration, the security management system 140 may implement vulnerability detection and repair, code and dependencies (e.g., open-source frameworks, libraries, etc. ) monitoring, automated code audit, encryption, and the like.

[0053] The code processing module 142 processes source code associated with the organization’s software projects. The code processing module 142 may perform automated reviews and / or audits of the source code in order to identify potential security vulnerabilities with the software projects.

[0054] The embeddings module 144 creates vector representations of data. Embeddings are computed using machine learning models. The embeddings module 144 is configured to implement one or more embedding models for processing different types of data. Examples of pre-trained embedding models which may be implemented include: Word2Vec, Doc2Vec, Universal Sentence Encoder, Global Vectors (GloVe) , Embeddings from Language Models (ELMo) , FastText, MobileNet v2, SentenceBERT, InferSent, etc.

[0055] The scanner module 146 monitors external data sources, such as third-party libraries and framework, and changes therein. In at least some implementations, the scanner module 146 performs scans of open-source repositories. The scanner module 146 may detect updates to dependencies and identify code changes associated with commits to the open-source repositories. The code changes may be further processed in order to determine whether they are indicative of vulnerability fixes in the software dependencies. More specifically, as will be explained in greater detail below, the detected code changes of commits may be input to a trained machine learning model in order to obtain predictions of file-and / or commit-level vulnerability fixes.

[0056] The client devices 110, the version control server 130, and the security management system 140 may be in geographically disparate locations. Put differently, the version control server 130 may be remote from the client devices 110 and the security management system 140. As explained herein, the client devices 110, the version control server 130, and the security management system 140 are computer systems.

[0057] The network 120 is a computer network. In some implementations, the network 120 may be an internetwork such as may be formed of one or more interconnected computer networks. For example, the network 120 may be or may include an Ethernet network, an asynchronous transfer mode network, a wireless network, or the like.

[0058] FIG. 2A is a high-level operation diagram of an example computing device 105. In at least some implementations, the example computing device 105 may be exemplary of the client devices 110, the version control server 130, and the security management system 140. The example computing device 105 includes a variety of modules. For example, the example computing device 105, may include a processor 200, a memory 210, an input interface module 220, an output interface module 230, and a communications module 240. As illustrated, the foregoing example modules of the example computing device 105 are in communication over a bus 250.

[0059] The processor 200 is a hardware processor. For example, the processor 200 may comprise one or more ARM, Intel x86, PowerPC processors or the like.

[0060] The memory 210 allows data to be stored and retrieved. The memory 210 may include, for example, random access memory, read-only memory, and persistent storage. Persistent storage may be, for example, flash memory, a solid-state drive or the like. Read-only memory and persistent storage are a computer-readable medium. A computer-readable medium may be organized using a file system such as may be administered by an operating system governing overall operation of the example computing device 105.

[0061] The input interface module 220 allows the example computing device 105 to receive input signals. Input signals may, for example, correspond to input received from a user. The input interface module 220 may serve to interconnect the example computing device 105 with one or more input devices. Input signals may be received from input devices by the input interface module 220. Input devices may, for example, include one or more of a touchscreen input, keyboard, trackball or the like. In some implementations, all or a portion of the  input interface module 220 may be integrated with an input device. For example, the input interface module 220 may be integrated with one of the aforementioned examples of input devices.

[0062] The output interface module 230 allows the example computing device 105 to provide output signals. Some output signals may, for example allow provision of output to a user. The output interface module 230 may serve to interconnect the example computing device 105 with one or more output devices. Output signals may be sent to output devices by output interface module 230. Output devices may include, for example, a display screen such as, for example, a liquid crystal display (LCD) , a touchscreen display. Additionally, or alternatively, output devices may include devices other than screens such as, for example, a speaker, indicator lamps (such as for, example, light-emitting diodes (LEDs) ) , and printers. In some implementations, all or a portion of the output interface module 230 may be integrated with an output device. For example, the output interface module 230 may be integrated with one of the aforementioned example output devices.

[0063] The communications module 240 allows the example computing device 105 to communicate with other electronic devices and / or various communications networks. For example, the communications module 240 may allow the example computing device 105 to send or receive communications signals. Communications signals may be sent or received according to one or more protocols or according to one or more standards. For example, the communications module 240 may allow the example computing device 105 to communicate via a cellular data network, such as for example, according to one or more standards such as, for example, Global System for Mobile Communications (GSM) , Code Division Multiple Access (CDMA) , Evolution Data Optimized (EVDO) , Long-term Evolution (LTE) or the like.

[0064] Additionally, or alternatively, the communications module 240 may allow the example computing device 105 to communicate using near-field communication (NFC) , via Wi-FiTM, using BluetoothTM or via some combination of one or more networks or protocols. Contactless payments may be made using NFC. In some implementations, all or a portion of the communications module 240 may be integrated into a component of the example computing device 105. For example, the communications module may be integrated into a communications chipset.

[0065] Software comprising instructions is executed by the processor 200 from a computer-readable medium. For example, software may be loaded into random-access memory from persistent storage of memory 210. Additionally, or alternatively, instructions may be executed by the processor 200 directly from read-only memory of memory 210.

[0066] FIG. 2B depicts a simplified organization of software components stored in memory 210 of the example computing device 105. As illustrated, these software components include application software 270 and an operating system 280.

[0067] The application software 270 adapts the example computing device 105, in combination with the operating system 280, to operate as a device performing a particular function. The operating system 280 is software. The operating system 280 allows the application software 270 to access the processor 200, the memory 210, the input interface module 220, the output interface module 230 and the communications module 240. The operating system 280 may be, for example, Apple iOSTM, Google’s AndroidTM, LinuxTM, Microsoft WindowsTM, or the like.

[0068] Reference is now made to FIG. 3, which shows, in flowchart form, an example method 300 for automated detection of vulnerability fixes in computer software. The operations of method 300 may be performed as part of software security management. In at least some embodiments, the method 300 may be implemented by a computer system that is configured to scan dependencies, such as open-source dependencies, of a software project and assess the likelihood of vulnerability fixes in updates or changes in the dependencies. For example, the operations of method 300 may be performed by a computing system (such as the security management system 140 of FIG. 1) when executing software dependency management or security monitoring operations.

[0069] In operation 302, the computing system obtains at least one source code file containing source code. The source code file may, for example, be a file that is part of a software project and included in a commit of source code to a repository, such as an open-source repository. In particular, the source code file may contain the latest version of the source code that is committed to the repository. The source code file may be obtained by, for example, decomposing a source code commit into file-level.

[0070] In operation 304, the computing system determines code changes associated with the source code file. The code changes indicate differences between the previous version of the source code contained in the source code file and the current version of the source code. In at least some implementations, the computing system is configured to identify lines of code that have been deleted from the previous version of the source code and / or lines of code that are added in the current version of the source code. That is, the computing system determines the differences between two successive versions of the source code in the repository, and labels the differences as either added code or deleted code.

[0071] The computing system constructs context-preserving code change representations based on the code changes associated with the source code file. More specifically, the computing system determines, based on the code changes, a first code representation of the previous version of the source code and a second code representation of the current version of the source code (operation 306) . The first code representation comprises text data representing the source code prior to the code changes and the second code representation comprises text data representing the source code following the code changes.

[0072] The context-preserving code constructions include surrounding code fragments as proxy for context. In particular, the computing system identifies surrounding context lines of source code associated with at least one of the deleted code lines or added code lines. For each of the deleted code lines, the computing system identifies, in the previous version of the source code, a first number of code lines preceding the deleted code line and a same number of code lines following the deleted code line. The number of lines, or “context size” , may be manually set. In a similar manner, for each of the added code lines, the computing system identifies, in the current version of the source code, the first number of code lines preceding the added code line and a same number of code lines following the added code line. The first code representation may then be obtained by combining the deleted code lines and the surrounding context lines of source code associated with the deleted code lines. Similarly, the second code representation may be obtained by combining the added code lines and the surrounding context lines of source code associated with the added code lines.

[0073] In operation 308, the computing system obtains, via a first code embedding model, a first embedding of the first code representation. The first code embedding model may, for example, be a word  embedding model, such as Word2Vec. The first code embedding model takes the first code representation as an input and outputs a vector embedding in a continuous vector space.

[0074] In operation 310, the computing system obtains, via a second code embedding model, a second embedding of the second code representation. The second code embedding model may be a word embedding model, such as Word2Vec. The second code embedding model takes the second code representation as an input and outputs a vector embedding in a continuous vector space. In at least some implementations, the first code embedding model is different from and independent of the second code embedding model. Two separate embedding models are employed, in order to enhance the nuance capture between the first and second embeddings. Each code embedding model is thus allowed to specialize without interference from the other one of the models.

[0075] The computing system determines a file-level code change representation for the source code file based on a computed distance between the first embedding and the second embedding (operation 312) . The file-level code change representation captures the differences between two consecutive versions of the source code based on their latent space characteristics. In at least some implementations, the file-level code change representation is determined based on performing element-wise vector subtraction of the first and second embeddings. This approach is inspired by Word2Vec’s method of capturing relationships between words through vector subtraction, aiming to encapsulate the semantic relationship of the code changes.

[0076] In operation 314, the computing system performs classification of the source code file based on the file-level code change representation. In particular, the computing system may determine, based on the file-level code change representation, a file-level probability that the source code file contains a vulnerability fix. The probability may then be compared against a defined threshold value. If the probability exceeds the threshold value, the file-level prediction for the source code file is that it contains at least one vulnerability fix. On the other hand, if the probability does not exceed the threshold value, the file-level prediction is that it contains no vulnerability fix.

[0077] In some implementations, a source code commit to a code repository may comprise a plurality of source code files. The classification of a source code commit may be performed by determining the file-level probability (of vulnerability fix) for each of the plurality of files and aggregating all file-level probabilities across the plurality of files associated with the source code commit to obtain a commit-level prediction result. A suitable probability distribution may be used for the aggregation. For example, in some implementations, mean-pooling may be used to compute a mean of the probabilities associated with the plurality of files.

[0078] Reference is now made to FIG. 4, which shows, in flowchart form, another example method 400 for automated detection of vulnerability fixes in computer software. The operations of method 400 may be performed as part of software security management. In at least some embodiments, the method 400 may be implemented by a computer system that is configured to scan dependencies, such as open-source dependencies, of a software project and assess the likelihood of vulnerability fixes in updates or changes in the dependencies. For example, the operations of method 400 may be performed by a computing system (such as the security management system 140 of FIG. 1) when executing software dependency management or security monitoring operations. The operations of method 400 may be performed in addition to, or as alternatives of, one or more of the operations of method 300.

[0079] As illustrated in FIG. 5, a machine learning model that is trained on training data comprising input source code files may be deployed for making file-and commit-level predictions relating to presence of vulnerability fixes in source code. The embeddings and file-level code change representation described with reference to FIG. 3 may be used in a training process for making file-level predictions. At the inference stage, a source code commit can be decomposed to its constituent files, and file-level predictions can be made using the trained machine learning model. The probability of vulnerability fix can be aggregated across all files of the source code commit to generate a commit-level prediction result. The trained machine learning model may be integrated into various tools for software security management, enabling real-time vulnerability detection and alerting capabilities.

[0080] The computing system monitors a third-party code repository (operation 402) . The code repository may, for example, be an open-source repository. The computing system may scan the code repository continuously, at predefined times or regular intervals, or on demand.

[0081] The computing system detects code changes associated with a source code commit based on the monitoring, in operation 404. The code changes across the commit files indicate differences between the previous version of the source code contained in the source code files and the current version of the source code. In at least some implementations, the computing system is configured to identify lines of code that have been deleted from the previous version of the source code and / or lines of code that are added in the current version of the source code.

[0082] In operation 406, the computing system constructs context-preserving code change representations for source code files containing the modified code. As described above, the context-preserving code change representations may be in the form of a first code representation of the previous version of the source code and a second code representation of the current version of the source code. The first code representation comprises text data representing the source code prior to the code changes and the second code representation comprises text data representing the source code following the code changes.

[0083] The computing system then determines, using a trained machine learning model, file-level probabilities of a vulnerability fix (operation 408) . The machine learning model is trained on training data comprising input source code files in accordance with the method described with reference to FIG. 3. The context-preserving code change constructions that are obtained based on the one or more source code files of the commit are provided as input to the trained model. The output of the trained model comprises file-level predictions of vulnerability fix across the source code files.

[0084] In operation 410, the computing system aggregates the probabilities across all of the files of the source code commit in order to generate a commit-level prediction result. If, in operation 412, the computing system determines that no potential vulnerability fix is detected in the modified code of the committed source code files, the method proceeds back to operation 402, i.e., repository monitoring for updates or changes to source code. However, if the commit-level prediction result suggests that there may be potential vulnerability fix, the computing system may be configured to alert responsible parties by providing a suitable message. In operation 414, the computing system generates a message identifying the potential vulnerability fix. The message may indicate the affected software dependencies, information regarding the vulnerability, and a description of the fix or repair for the vulnerability. The message can be transmitted to one or more subscribing  entities, such as an organization with a product or service with the affected software dependencies, in operation 416.

[0085] The methods and / or processes described above, and steps thereof, may be realized in hardware, software or any combination of hardware and software suitable for a particular application. The hardware may include a general-purpose computer and / or dedicated computing device or specific computing device or particular aspect or component of a specific computing device. The processes may be realized in one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors or other programmable devices, along with internal and / or external memory. The processes may also, or instead, be embodied in an application specific integrated circuit, a programmable gate array, programmable array logic, or any other device or combination of devices that may be configured to process electronic signals. It will further be appreciated that one or more of the processes may be realized as a computer executable code capable of being executed on a machine-readable medium.

[0086] The computer executable code may be created using a structured programming language such as C, an object oriented programming language such as C++, or any other high-level or low-level programming language (including assembly languages, hardware description languages, and database programming languages and technologies) that may be stored, compiled or interpreted to run on one of the above devices, as well as heterogeneous combinations of processors, processor architectures, or combinations of different hardware and software, or any other machine capable of executing program instructions.

[0087] Thus, in one aspect, each method described above, and combinations thereof may be embodied in computer executable code that, when executing on one or more computing devices, performs the steps thereof. In another aspect, the methods may be embodied in systems that perform the steps thereof and may be distributed across devices in a number of ways, or all of the functionality may be integrated into a dedicated, standalone device or other hardware. In another aspect, the means for performing the steps associated with the processes described above may include any of the hardware and / or software described above. All such permutations and combinations are intended to fall within the scope of the present disclosure.

[0088] In the present disclosure, the terms “a” , “an” and “one” are defined to mean “at least one” , that is, these terms do not exclude a plural number of items, unless stated otherwise.

[0089] In the present disclosure, terms such as “substantially” , “generally” and “about” , which modify a value, condition or characteristic of a feature of an example embodiment, should be understood to mean that the value, condition or characteristic is defined within tolerances that are acceptable for the proper operation of this example embodiment for its intended application.

[0090] In the present disclosure, unless stated otherwise, the terms “connected” and “coupled” , and derivatives and variants thereof, refer herein to any structural or functional connection or coupling, either direct or indirect, between two or more elements. For example, the connection or coupling between the elements can be acoustical, mechanical, optical, electrical, thermal, logical, or any combinations thereof.

[0091] In the present disclosure, expressions such as “match” , “matching” and “matched” , including variants and derivatives thereof, are intended to refer herein to a condition in which two or more elements are either the same or within some predetermined tolerance of each other. That is, these terms are meant to encompass not only “exactly” or “identically” matching the two elements but also “substantially” ,  “approximately” or “subjectively” matching the two or more elements, as well as providing a higher or best match among a plurality of matching possibilities.

[0092] In the present disclosure, the expression “based on” is intended to mean “based at least partly on” , that is, this expression can mean “based solely on” or “based partially on” , and so should not be interpreted in a limited manner. More particularly, the expression “based on” could also be understood as meaning “depending on” , “representative of” , “indicative of” , “associated with” or similar expressions.

[0093] In the present disclosure, the terms "system" and "network" may be used interchangeably in embodiments of this application. "At least one" means one or more, and "a plurality of" means two or more. The term "and / or" describes an association relationship of associated objects, and indicates that three relationships may exist. For example, A and / or B may indicate the following three cases: Only A exists, both A and B exist, and only B exists, where A and B may be singular or plural. The character " / " indicates an "or" relationship between associated objects. "At least one of the following items (pieces) " or a similar expression thereof indicates any combination of these items, including a single item (piece) or any combination of a plurality of items (pieces) . For example, "at least one of A, B, or C" includes: only A; only B; only C; A and B; A and C; B and C; or A, B, and C, and "at least one of A, B, and C" may also be understood as including: only A; only B; only C; A and B; A and C; B and C; or A, B, and C. In addition, unless otherwise specified, ordinal numbers such as "first" and "second" in embodiments of this application are used to distinguish between a plurality of objects, and are not used to limit a sequence, a time sequence, priorities, or importance of the plurality of objects.

[0094] A person skilled in the art should understand that embodiments of this application may be provided as a method, an apparatus (or system) , computer-readable storage medium, or a computer program product. Therefore, this application may use a form of a hardware-only embodiment, a software-only embodiment, or an embodiment with a combination of software and hardware. Moreover, this application may use a form of a computer program product that is implemented on one or more computer-usable storage media (including but not limited to a disk memory, an optical memory, and the like) that include computer-usable program code.

[0095] This application is described with reference to the flowcharts and / or block diagrams of the method, the device (system) , and the computer program product according to this application. It should be understood that computer program instructions may be used to implement each process and / or each block in the flowcharts and / or the block diagrams and a combination of a process and / or a block in the flowcharts and / or the block diagrams. The computer program instructions may be provided for a general-purpose computer, a dedicated computer, an embedded processor, or a processor of another programmable data processing device to generate a machine, so that the instructions executed by the computer or the processor of the another programmable data processing device generate an apparatus for implementing a specific function in one or more procedures in the flowcharts and / or in one or more blocks in the block diagrams.

[0096] The computer program instructions may alternatively be stored in a computer-readable memory that can indicate a computer or another programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate an artifact that includes an instruction apparatus. The instruction apparatus implements a specific function in one or more procedures in the flowcharts and / or in one or more blocks in the block diagrams.

[0097] The computer program instructions may alternatively be loaded onto a computer or another programmable data processing device, so that a series of operations and steps are performed on the computer or the another programmable device, so that computer-implemented processing is generated. Therefore, the instructions executed on the computer or the another programmable device provide steps for implementing a specific function in one or more procedures in the flowcharts and / or in one or more blocks in the block diagrams.

[0098] It is clear that a person skilled in the art can make various modifications and variations to this application without departing from the scope of this application. This application is intended to cover these modifications and variations of this application provided that they fall within the scope of protection defined by the following claims and their equivalent technologies.

Claims

1.A computer-implemented method for detecting vulnerability fixes in software code, the method comprising:obtaining at least one source code file containing source code;determining code changes associated with the at least one source code file, the code changes indicating differences between a previous version of the source code and a current version of the source code;determining, based on the code changes, a first code representation of the previous version of the source code and a second code representation of the current version of the source code;obtaining, via a first embedding model, a first embedding of the first code representation;obtaining, via a second embedding model, a second embedding of the second code representation;determining a file-level code change representation for the at least one source code file based on a computed distance between the first embedding and the second embedding; andperforming classification of the at least one source code file based on the file-level code change representation.2.The method of claim 1, wherein each of the first embedding model and the second embedding model is a text embedding model and wherein the first embedding model is different from the second embedding model.3.The method of claim 1, wherein determining the file-level code change representation for the at least one source code file comprises performing element-wise vector subtraction of the first and second embeddings.4.The method of claim 1, wherein determining the code changes associated with the at least one source code file comprises identifying at least one of:lines of code deleted from the previous version of the source code; orlines of code added in the current version of the source code.5.The method of claim 4, wherein determining the first and second code representations comprises identifying surrounding context lines of source code associated with the at least one of the deleted code lines or added code lines and wherein:the first code representation comprises a combination of the deleted code lines and the surrounding context lines of source code; andthe second code representation comprises a combination of the added code lines and the surrounding context lines of source code.6.The method of claim 5, wherein identifying the surrounding context lines of source code comprises:for each of the deleted code lines, identifying a first number of code lines preceding the deleted code line and a same number of code lines following the deleted code line in the previous version of the source code; andfor each of the added code lines, identifying the first number of code lines preceding the added code line and a same number of code lines following the added code line in the current version of the source code.7.The method of claim 1, wherein performing classification of the at least one source code file comprises:determining, based on the file-level code change representation, a file-level probability that the at least one source code file contains a vulnerability fix; andcomparing the probability against a defined threshold value.8.The method of claim 7, wherein the at least one source code file comprises a plurality of files associated with a source code commit to a code repository and wherein performing classification of the at least one source code file comprises:determining the file-level probability for each of the plurality of files; andaggregating all file-level probabilities across the plurality of files associated with the source code commit to obtain a commit-level prediction result.9.A computer-implemented method for training a machine learning model, the method comprising:determining code changes associated with an input source code file, the code changes indicating differences between a previous version of the source code and a current version of the source code;determining, based on the code changes, a first code representation of the previous version of the source code and a second code representation of the current version of the source code;obtaining, via a first embedding model, a first embedding of the first code representation;obtaining, via a second embedding model, a second embedding of the second code representation;determining a file-level code change representation for the input source code file based on a computed distance between the first embedding and the second embedding; andperforming classification of the input source code file based on the file-level code change representation.10.The method of claim 9, wherein each of the first embedding model and the second embedding model is a text embedding model and wherein the first embedding model is different from the second embedding model.11.The method of claim 9, wherein determining the file-level code change representation for the input source code file comprises performing element-wise vector subtraction of the first and second embeddings and wherein the method further comprises providing the file-level code change representation to a classification head.12.The method of claim 9, wherein determining the code changes associated with the input source code file comprises identifying at least one of:lines of code deleted from the previous version of the source code; orlines of code added in the current version of the source code.13.The method of claim 12, wherein determining the first and second code representations comprises identifying surrounding context lines of source code associated with the at least one of the deleted code lines or added code lines and wherein:the first code representation comprises a combination of the deleted code lines and the surrounding context lines of source code; andthe second code representation comprises a combination of the added code lines and the surrounding context lines of source code.14.The method of claim 13, wherein identifying the surrounding context lines of source code comprises:for each of the deleted code lines, identifying a first number of code lines preceding the deleted code line and a same number of code lines following the deleted code line in the previous version of the source code; andfor each of the added code lines, identifying the first number of code lines preceding the added code line and a same number of code lines following the added code line in the current version of the source code.15.A computing system, comprising:a processor; andmemory coupled to the processor, the memory storing computer-executable instructions that, when executed by the processor, configure the processor to:obtain a source code file containing source code;determine code changes associated with the source code file, the code changes indicating differences between a previous version of the source code and a current version of the source code;determine, based on the code changes, a first code representation of the previous version of the source code and a second code representation of the current version of the source code;obtain, via a first embedding model, a first embedding of the first code representation;obtain, via a second embedding model, a second embedding of the second code representation;determine a file-level code change representation for the source code file based on a computed distance between the first embedding and the second embedding; andperform classification of the source code file based on the file-level code change representation.16.The computing system of claim 15, wherein each of the first embedding model and the second embedding model is a text embedding model and wherein the first embedding model is different from the second embedding model.17.The computing system of claim 15, wherein determining the code changes associated with the at least one source code file comprises identifying at least one of:lines of code deleted from the previous version of the source code; orlines of code added in the current version of the source code.18.The computing system of claim 17, wherein determining the first and second code representations comprises identifying surrounding context lines of source code associated with the at least one of the deleted code lines or added code lines and wherein:the first code representation comprises a combination of the deleted code lines and the surrounding context lines of source code; andthe second code representation comprises a combination of the added code lines and the surrounding context lines of source code.19.The computing system of claim 18, wherein identifying the surrounding context lines of source code comprises:for each of the deleted code lines, identifying a first number of code lines preceding the deleted code line and a same number of code lines following the deleted code line in the previous version of the source code; andfor each of the added code lines, identifying the first number of code lines preceding the added code line and a same number of code lines following the added code line in the current version of the source code.20.The computing system of claim 11, wherein performing classification of the at least one source code file comprises:determining, based on the file-level code change representation, a file-level probability that the at least one source code file contains a vulnerability fix; andcomparing the probability against a defined threshold value.

Images