AUTOMATED DETECTION OF KNOWN VULNERABILITYs

Abstract

A first aspect of the present disclosure relates to a computer-implemented method for the automated detection of known vulnerabilities in a static test of software, comprising: extracting a data structure from the software code; identifying one or more software components on which the software depends, based on the code, the extracted data structure, and / or the software bill of materials (SBOM); and evaluating, for at least one identified software component, whether the software component is associated with a known vulnerability, resulting in one or more potentially vulnerable software components.Applying a machine learning model to at least one potentially vulnerable piece of software, based on a description associated with the known vulnerability, wherein the machine learning model is trained and configured to determine at least one principal reason from at least the description and a prompt; and evaluating the at least one potentially vulnerable piece of software as vulnerable or as not vulnerable or, optionally, as unevaluable based on the at least one principal reason and the extracted data structure.

Description

State of the art

[0001] Software for controlling, regulating and / or monitoring technical systems, in particular cyber-physical systems such as the processing units of a vehicle, is typically highly complex. Such software frequently comprises a large number of software components such as software packages, functions and / or libraries, which are developed and provided independently of one another in organizational and / or economic terms. The number of software components, which also typically exist in different versions (sometimes also subversions), is often so large (e.g. more than 100, more than 500 or more than 1000 software components), that it is challenging for individual software engineers and even for entire software development departments to maintain an overview of the various software components throughout the software lifecycle (development, testing, production and maintenance). Software and its software components can be error-prone.Software and / or its software components can be tested for errors, for example, using static software tests. Unlike dynamic software tests, the software is not executed. In the context of this invention, errors or vulnerabilities that impair or even endanger the security of the software, and thus of the technical system controlled, regulated, and / or monitored by it, are particularly problematic. In practice, such security vulnerabilities (vulnerabilities for short) of individual software components are often only detected after a certain period of time, despite thorough testing. Therefore, throughout the life cycle of a software, its software components must be continuously monitored, and any vulnerabilities that arise must be addressed. Generally known vulnerabilities are particularly critical, as they can easily be exploited by attackers.

[0002] Constantly updated and accessible lists and / or databases of common vulnerabilities are known. One example is the Common Vulnerabilities and Exposures (CVE), a referencing system managed by the US National Cybersecurity FFRDC and maintained by the Mitre Corporation. Its goal is to establish a uniform naming convention for security vulnerabilities and other vulnerabilities in computer systems.

[0003] Often, the individual software components of a software are sufficiently complex, so it's important to carefully differentiate whether a known vulnerability associated with that software component actually represents a security risk. For example, a large software program can have hundreds or thousands of vulnerabilities (many of which are so-called false positives) related to the software components used in the software, but only approximately 3-10% of these actually pose a security risk to the software (so-called true positives).

[0004] The invention is therefore based on the problem of providing an automated but nevertheless reliable detection of relevant vulnerabilities, in particular whereby the number of false positives is to be reduced or eliminated. Disclosure of the invention

[0005] A first general aspect of the present disclosure relates to a computer-implemented method for the automated detection of known vulnerabilities in a static test of software. The method may comprise extracting a data structure of a code of the software. The method further comprises identifying one or more software parts on which the software depends, based on the code, the extracted data structure, and / or the Software Bill of Materials (SBOM) of the software. The method further comprises assessing, for at least one identified software part, whether the software part is associated with a known vulnerability, resulting in one or more potentially vulnerable software parts.The method further comprises applying, for at least one potentially vulnerable piece of software, a machine learning model to a description associated with the known vulnerability, wherein the machine learning model is trained and configured to determine at least one root cause from at least the description and a prompt.

[0006] The method further comprises evaluating the at least one potentially vulnerable software part as vulnerable or as not vulnerable or, optionally, as unassessable based on the at least one main reason and the extracted data structure (and / or code).

[0007] The software can be designed to control, regulate, and / or monitor a technical system, in particular a cyber-physical system, in particular at least one computing unit of a vehicle. The method can be executed in an electronic programming environment. The method can include outputting at least one software component assessed as vulnerable, optionally via a user interface.

[0008] A second general aspect of the present disclosure relates to a computer system configured to execute the computer-implemented method for the automated detection of known vulnerabilities in a static test of software according to the first general aspect (or an embodiment thereof).

[0009] A third general aspect of the present disclosure relates to a computer program configured to execute the computer-implemented method for the automated detection of known vulnerabilities in a static test of software according to the first general aspect (or an embodiment thereof).

[0010] A fourth general aspect of the present disclosure relates to a computer-readable medium or signal storing and / or containing the computer program according to the third general aspect (or an embodiment thereof).

[0011] The method proposed in this disclosure according to the first aspect (or an embodiment thereof) is directed toward the automated detection of known vulnerabilities in software. This allows known vulnerabilities relevant to the software (or its software components) to be (better) identified. In particular, false positives can be significantly reduced or even eliminated entirely. This is an advantage in practice, among other things, because, due to the typically high complexity of the software and its software components, a large number (even several hundred thousand) of false positives can occur, which would be difficult to analyze in detail and identify as false positives with reasonable effort. Thanks to the automated and reliable detection disclosed here, (almost) only true positives are identified, which can then be addressed by modifying the software.This can improve the security of the software and, for example, the technical system controlled, regulated and / or monitored by the software, such as a vehicle. Short description of the characters Fig. 1a-b schematically illustrate computer-implemented methods for the automated detection of known vulnerabilities in a static test of a software. Fig. Figure 2 schematically illustrates a data structure extracted from the software code, e.g., a control flow graph. Detailed description

[0012] The method proposed in this disclosure is directed to the automated detection of known vulnerabilities of a software.

[0013] A computer-implemented method 100 is disclosed, schematically illustrated in Fig. 1a-b for the automated detection of known (ie known at least at the time of execution of the method 100) vulnerabilities in a static test of a software.

[0014] The method 100 may comprise extracting 110 a data structure 10 of a code of the software, wherein the data structure 10 is suitable, for example, for static testing of the software. The data structure 10 may be suitable for static testing of the software if it represents a logic of the code. Alternatively or additionally, the data structure 10 may be suitable for static testing of the software if it is in a standard form, in particular in a parsable standard form. A data structure 10 may be a standard form if it is independent of the programming language in which the code was written. Alternatively or additionally, a data structure 10 may be a standard form if it is independent of the target platform on which the code is executed. Alternatively or additionally, a data structure 10 may be a standard form if it is independent of compiler specifications.Alternatively or additionally, data structure 10 may be suitable for static testing of the software if it contains less information than the code. An example data structure 10 (abstract syntax tree) is shown in . Fig. 2 is shown schematically.

[0015] The method 100 may include receiving the code of the software.

[0016] The method 100 further includes identifying 120 one or more software parts on which the software depends, based on the code, the extracted 110 data structure 10, and / or the software's software bill of materials (SBOM). For example, identifying 120 the one or more software parts may be based on the code. Alternatively or additionally, identifying 120 the one or more software parts may be based on the extracted 110 data structure 10. Alternatively or additionally, identifying 120 the one or more software parts may be based on the software's software bill of materials (SBOM). The one or more software parts may, for example, be external software parts.Identification based on code can be performed starting from source code, for example via a standard package manager, and starting from compiled binary code, for example via analysis of the included system files and / or the included executable files.

[0017] The method 100 further comprises assessing 130, for at least one identified 120 software part, whether the software part is associated with a known vulnerability, resulting in one or more potentially vulnerable software parts. The method 100 may comprise assessing, for each identified 120 software part, whether the software part is associated with a known vulnerability. The assessing 130 may, for example, comprise retrieving and comparing known vulnerabilities from a public and / or private database. For example, the Common Vulnerabilities and Exposures (CVE) are publicly accessible as a referencing system under the US National Cybersecurity FFRDC and maintained by the Mitre Corporation. An exemplary excerpt from a list of known vulnerabilities is reproduced below.

[0018] The method 100 further comprises applying 140, for at least one potentially vulnerable software part, a machine learning model based on a description associated with the known vulnerability (associated with the potentially vulnerable software part), wherein the machine learning model is trained and configured to determine at least one root cause from at least the description and a prompt. The method 100 may comprise applying, for each potentially vulnerable software part, a machine learning model based on a respective description associated with the known vulnerability (associated with the respective potentially vulnerable software part). The description and / or the prompt may, for example, be in English. Alternatively, the description and / or the prompt may also be in another language, such as German or Chinese.The use of English can be advantageous because it is a key language for programming. Furthermore, CVEs, for example, are published in English. Furthermore, a large language model included in a machine learning model can usually handle English well because a large portion of the training data used to train the large language model was often already in English. The prompt can include syntax specifications, e.g. regarding input (e.g. format of vulnerability entries) and / or output data (e.g. format of the main reason(s)) to the machine learning model. Syntax specifications can be advantageous for further machine processing. An example prompt with syntax specifications is shown below.

[0019] The method 100 comprises evaluating 150 the at least one potentially vulnerable software part as vulnerable or as not vulnerable or, optionally, as unassessable based on the at least one main reason and the extracted 110 data structure 10 and / or on the code. The evaluation 150 based on the at least one main reason and the extracted 110 data structure 10 (instead of the code) can be advantageous, for example, if the data structure 10 is a standard form, in particular a parsable standard form, and if necessary, a main reason (e.g., a function) can be reliably found therein. Alternatively, the evaluation 150 can be based on the at least one main reason and the code (instead of the data structure 10). In such a case, it may be possible (e.g.,although the step of identifying 120 the one or more software parts is also not based on the data structure 10), omitting the step of extracting 110 the data structure of the code of the software (unlike in . Fig. 1a-b).

[0020] The software can be designed to control, regulate, and / or monitor a technical system. The technical system can be, for example, a cyber-physical system. Alternatively or additionally, the technical system can comprise at least one computing unit (e.g., a control unit) of a vehicle. For example, the technical system can be a braking system of a vehicle.

[0021] The method 100 can be executed in an electronic programming environment. This allows, for example, a user of the electronic programming environment, e.g., a software engineer, to initiate a measure regarding a piece of software assessed as vulnerable. Alternatively or additionally, a further automated analysis can also be performed in the electronic programming environment.

[0022] The method 100 may, as in Fig. 1b, the output 160 of at least one software part assessed as vulnerable 150 can be performed, for example, via a user interface. The user interface can, for example, comprise a screen and at least one input interface (keyboard, mouse, touch screen). Alternatively or additionally, the output 160 of the at least one software part assessed as vulnerable 150 can be performed, for example, via an output file. Thanks to the output 160 of the at least one software part assessed as vulnerable 150, a user – e.g., a software engineer – can take a measure such that the vulnerability in the software is eliminated. This can improve the reliability and / or security of the software and the technical system as a whole, in particular the cyber-physical system that is controlled, regulated, and / or monitored by the software.A mitigation measure could, for example, include removing the 150 software components assessed as vulnerable. This could, for example, involve replacing the software components with a new (improved) version. Alternatively or additionally, the mitigation measure could, for example, include adapting the 150 software components assessed as vulnerable.

[0023] The code may include or be source code. Alternatively or additionally, the code may include or be compiled binary code.

[0024] The data structure may include an abstract syntax tree or be an abstract syntax tree. An abstract syntax tree may be a hierarchical representation of a decomposition of the code as text. Alternatively or additionally, the data structure may, for example, Fig. 2, a control flow graph can comprise a control flow graph or be a control flow graph. A control flow graph can be a directed graph used to describe the program flow of a computer program (here: the software). For example, starting from source code or compiled binary code, a p-code (instruction set of a pseudo-machine, i.e., a virtual CPU) can be generated, and from this, the control flow graph can be generated.

[0025] Extracting 110 the data structure 10 of the code may include generating an abstract syntax tree of the code (or a portion thereof) and generating the control flow graph from the abstract syntax tree. Such a procedure may be chosen, for example, when extracting 110 the data structure 10 from source code.

[0026] A software part may comprise a software package. Alternatively or additionally, a software part may comprise a function. Alternatively or additionally, a software part may comprise a library. A (or each) software part may comprise one or more identifiers. Alternatively or additionally, a (or each) software part may comprise metadata. An identifier may, for example, comprise a unique name of a software package, a function, and / or a library. The metadata may, for example, comprise a version number. Alternatively or additionally, the metadata may comprise a usage type. Alternatively or additionally, the metadata may comprise a configuration. Alternatively or additionally, the metadata may comprise a build option.

[0027] The evaluation 130, for at least one identified software component, of whether the software component is associated with a known vulnerability can be based on a comparison of identifiers and / or metadata. In particular, the evaluation 130, for each identified 120 software component, of whether the respective software component is associated with a known vulnerability can be based on a comparison of identifiers and / or metadata. In particular, each software component can, for example, have a unique name and be available in a single version (possibly with Subversion). During the evaluation 130, the names and versions can then be compared, for example.

[0028] The machine learning model can include a foundation model or be a foundation model. A foundation model can be a large machine learning model that has been trained on a large dataset at scale (often through self-supervised learning or semi-supervised learning), allowing it to be adapted to a wide range of downstream tasks. In particular, the machine learning model can include a large language model (LLM) or be a large language model.

[0029] A large language model can be a language model characterized by its size. In particular, the large language model can be a chatbot or have chatbot functionality.

[0030] Google BERT, for example, can be used as a large language model. Alternatively or additionally, OpenAl ChatGPT (e.g., version from May 24, 2023) can be used as a large language model. Alternatively or additionally, Hugging Face Bloom can be used as a large language model.

[0031] Alternatively or additionally, the machine learning model can include or be a multi-domain model. For example, OpenAI GPT-4 (e.g., version dated March 14, 2023) can be used in this case.

[0032] The at least one main reason may, for example, be an (affected, i.e., relevant to the associated known vulnerability) function, in particular, wherein the function may be included in the description (associated with the known vulnerability). Determining the at least one main reason may comprise filtering out the (at least one) function from the description.

[0033] The prompt can include (or be) an instruction to the machine learning model (e.g., the Foundation Model) aimed at extracting one or more main reasons from the description (or outputting that a main reason cannot be extracted). For example, the prompt can include (or be) a linguistic instruction to the Large Language Model (LLM) aimed at extracting one or more main reasons from the description (or outputting that a main reason cannot be extracted). In other words, the machine learning model (here, the LLM) does not have to have been specifically trained to extract the main reason.It may already be sufficient that the machine learning model has been trained in general to a certain level of understanding, in particular to a certain level of language understanding, so that the prompt, in particular the linguistic instruction, is understood by the machine learning model and the machine learning model is thereby enabled to extract the main reason(s) from a description.

[0034] Evaluating 150 the at least one potentially vulnerable software part as vulnerable or as not vulnerable or, optionally, as unevaluable based on the at least one main reason and the extracted 110 data structure 10 may include checking whether the function associated with the at least one main reason is included (and actually used) in the extracted 110 data structure 10.

[0035] A concrete example is described in more detail below. From the source code (see example below) or the compiled binary code (see example below) of a software, a p-code (see example below) can be generated, on the basis of which a control flow graph, comparable to the illustrative representation in Fig. 2, can be generated. For example, based on the source code or other development work, the included packages can be identified, and these findings can be used to generate a (complete) list of all possible vulnerabilities. For each vulnerability found, a call can then be made, such as in Open Al ChatGPT (see example prompt below), to identify at least one root cause. This root cause can then be used, for example, to check the control flow graph to see whether this function is included and used.

[0036] An example source code is shown below: "#include<stdio.h> int loop(int i) { for(int a=0; a < i ; a++){ printf("%d \n",a);}} int main() { printf("Start IDA Tracing\n"); int i=2; / / change this to increase or decrease the trace size int x=loop(i); printf("Stop IDA Tracing\n"); return 0;}"

[0037] The following is an example (compiled) binary code: "01 00 02 00 25 64 20 0a 00 53 74 61 72 74 20 49 44 41 20 54 72 61 63 69 6e 67 00 53 74 6f 70 20 49 44 41 20 54 72 61 63 69 6e 67 00 01 1b 03 3b"

[0038] An example p-code is shown below:

[0039] The following is an example extract from a list of known vulnerabilities in English: „A memory leak in the mlx5_fpga_conn_create_cq() function in drivers / net / ethernet / mellanox / mlx5 / core / fpga / conn.c in the Linux kernel before 5.3.11 allows attackers to cause a denial of service (memory consumption) by triggering mlx5_vector2eqn() failures, aka CID-c8c2a057fdc7 A flaw was discovered in OpenLDAP before 2.4.57 leading to a double free and slapd crash in the saslAuthzTo processing, resulting in denial of service ..."

[0040] Nachfolgend wird ein Beispiel umfassend einen exemplarischen Prompt auf Englisch sowie die von dem Maschinenlernmodell generierten Antworten je Beschreibung wiedergegeben: „You are expected to deliver answers as a security engineer. As such I want you to extract the root cause of a CVE from its description. Answer as concisely as possible. CVE: {cve} => Answer: {answer} CVE: A memory leak in the mlx5_fpga_conn_create_cq() function in drivers / net / ethernet / mellanox / mlx5 / core / fpga / conn.c in the Linux kernel before 5.3.11 allows attackers to cause a denial of service (memory consumption) by triggering mlx5_vector2eqn() failures, aka CID-c8c2a057fdc7. => Answer: - mlx5_fpga_conn_create_cq() - mlx5_vector2eqn() CVE: A heap out-of-bounds read / write vulnerability in the Linux Kernel traffic control (QoS) subsystem can be exploited to achieve local privilege escalation. The qfq_change_class function does not properly limit the Imax variable which can lead to out-of-bounds read / write. If the TCA_QFQ_LMAX value is not offered through nlattr, Imax is determined by the MTU value of the network device. The MTU of the loopback device can be set up to 2^31-1 and as a result, it is possible to have an Imax value that exceeds QFQ_MIN_LMAX. We recommend upgrading past commit 3037933448f60f9acb705997eae62013ecb81 e0d. => Answer: - qfq_change_class() CVE: „managed-keys“ is a feature which allows a BIND resolver to automatically maintain the keys used by trust anchors which operators configure for use in DNSSEC validation. Due to an error in the managed-keys feature it is possible for a BIND server which uses managed-keys to exit due to an assertion failure if, during key rollover, a trust anchor's keys are replaced with keys which use an unsupported algorithm. Versions affected: BIND 9.9.0 -> 9.10.8-P1, 9.11.0 -> 9.11.5-P1, 9.12.0 -> 9.12.3-P1, and versions 9.9.3-S1 -> 9.11.5-S3 of BIND 9 Supported Preview Edition. Versions 9.13.0 -> 9.13.6 of the 9.13 development branch are also affected. Versions prior to BIND 9.9.0 have not been evaluated for vulnerability to CVE-2018-5745. => Answer: root cause not identifiable CVE: A use-after-free in Busybox's awk applet leads to denial of service and possibly code execution when processing a crafted awk pattern in the hash_init function => Answer: - hash_init() CVE: A memory leak in the mlx5_fpga_conn_create_cq() function in drivers / net / ethernet / mellanox / mlx5 / core / fpga / conn.c in the Linux kernel before 5.3.11 allows attackers to cause a denial of service (memory consumption) by triggering mlx5_vector2eqn() failures, aka CID-c8c2a057fdc7 => Answer: - mlx5_fpga_conn_create_cq() CVE: A flaw was discovered in OpenLDAP before 2.4.57 leading to a double free and slapd crash in the saslAuthzTo processing, resulting in denial of service => Answer: - saslAuthzTo()"

[0041] For example, the machine learning model for the prompt "You are expected to deliver answers as a security engineer. As such I want you to extract the root cause of a CVE from its description. Answer as concisely as possible. CVE: {cve} => Answer: {answer}" and the description "A flaw was discovered in OpenLDAP before 2.4.57 leading to a double free and slapd crash in the saslAuthzTo processing, resulting in denial of service" gives the main reason “saslAuthzTo()”.

[0042] Also disclosed is a computer system configured to execute the computer-implemented method 100 for the automated detection of known vulnerabilities in a static test of a software. The computer system may include a processor and / or a memory.

[0043] Also disclosed is a computer program designed to execute the computer-implemented method 100 for the automated detection of known vulnerabilities in a static software test. The computer program can be in interpretable or compiled form, for example. It can be loaded (even in parts) into the RAM of a computer for execution, for example, as a bit or byte sequence.

[0044] Further disclosed is a computer-readable medium or signal that stores and / or contains the computer program. The medium may, for example, comprise one of RAM, ROM, EPROM, HDD, SSD, etc., on / in which the signal is stored.

Claims

[1] A computer-implemented method (100) for the automated detection of known vulnerabilities in a static test of a software, comprising: - extracting (110) a data structure (10) of a code of the software; - identifying (120) one or more software parts on which the software depends, based on the code, on the extracted (110) data structure (10) and / or on the software bill of materials (SBOM); - Evaluating (130), for at least one identified (120) software part, whether the software part is associated with a known vulnerability, resulting in one or more potentially vulnerable software parts; - applying (140), for at least one potentially vulnerable piece of software, a machine learning model to a description associated with the known vulnerability, the machine learning model being trained and configured to determine at least one primary cause from at least the description and a prompt; - Evaluating (150) the at least one potentially vulnerable software part as vulnerable or as not vulnerable or, optionally, as unevaluable based on the at least one main reason and the extracted (110) data structure (10). [2] Method (100) according to claim 1, wherein the software is designed to control, regulate and / or monitor a technical system, in particular a cyber-physical system, in particular at least one computing unit of a vehicle. [3] The method (100) of claim 1 or 2, wherein the method (100) is executed in an electronic programming environment. [4] Method (100) according to one of the preceding claims, comprising: - Outputting (160) at least one piece of software assessed as vulnerable (150), optionally via a user interface. [5] Method (100) according to one of the preceding claims, wherein the code comprises source code. [6] The method (100) of any preceding claim, wherein the code comprises compiled binary code. [7] Method (100) according to one of the preceding claims, wherein the data structure comprises an abstract syntax tree. [8] Method (100) according to one of the preceding claims, wherein the data structure comprises a control flow graph. [9] Method (100) according to one of the preceding claims, wherein extracting the data structure (10) of the code comprises generating an abstract syntax tree of the code and generating the control flow graph from the abstract syntax tree. [10] Method (100) according to one of the preceding claims, wherein a software part comprises a software package, a function and / or a library. [11] Method (100) according to one of the preceding claims, wherein the evaluation (130), for at least one identified software part, of whether the software part is associated with a known vulnerability is based on a comparison of identifiers and / or metadata. [12] The method (100) of claim 11, wherein an identifier comprises a unique name of a software package, a function and / or a library. [13] The method (100) of claim 11 or 12, wherein the metadata comprises a version number, a usage type, a configuration and / or a build option. [14] Method (100) according to one of the preceding claims, wherein the machine learning model comprises a foundation model. [15] The method (100) of any preceding claim, wherein the prompt comprises an instruction to the machine learning model directed to extract one or more primary reasons from the description. [16] The method (100) of claim 14 or 15, wherein the machine learning model comprises a Large Language Model (LLM). [17] Method (100) according to one of the preceding claims, wherein the at least one main reason is a function, in particular wherein the function is included in the description. [18] The method (100) of claim 16 or 17, wherein the prompt comprises a linguistic instruction to the Large Language Model (LLM) directed to extract one or more main reasons from the description. [19] The method (100) of claim 17 or 18, wherein the evaluating (150) of the at least one potentially vulnerable software part as vulnerable or as not vulnerable or, optionally, as unassessable based on the at least one main reason and the extracted (110) data structure (10) comprises checking whether the function associated with the at least one main reason is contained in the extracted (110) data structure (10). [20] A computer system adapted to execute the computer-implemented method (100) for the automated detection of known vulnerabilities in a static test of software according to any one of the preceding claims. [21] A computer program adapted to execute the computer-implemented method (100) for the automated detection of known vulnerabilities in a static test of a software according to any one of claims 1 to 19. [22] A computer-readable medium or signal storing and / or containing the computer program of claim 21.

Images