Automatic identification of known vulnerabilities

Abstract

A first aspect of the present disclosure relates to a computer-implemented method for automatically identifying known vulnerabilities in static testing of software, comprising extracting a data structure of a code of the software; identifying one or more software parts based on the code, the extracted data structure, and / or a software material list of software, the software relating to the one or more software parts; evaluating, for at least one identified software portion, whether the software portion is associated with a known vulnerability, wherein one or more potentially vulnerable software portions are derived; applying, for at least one potentially vulnerable software portion, a machine learning model to a description assigned to a known vulnerability, where the machine learning model is trained and configured to determine at least one major cause from at least the description and cues; the at least one potentially vulnerable software portion is evaluated as vulnerable or not vulnerable or optionally non-evaluable based on the at least one primary cause and the extracted data structure.

Description

Background Art

[0001] Software for controlling, regulating and / or monitoring technical systems (especially information-physical systems such as computing units of vehicles) usually has high complexity. Such software often includes a large number of software parts, such as software packages, functions and / or libraries that are developed and provided independently of each other organizationally and / or economically. In addition, a large number of software parts that usually exist in different versions (sometimes also sub-versions) are often so many (for example, more than 100, more than 500 or more than 1000 software parts) that it is challenging for individual software engineers and even for the entire software development department to keep an overview of the various software parts during the life cycle (development, testing, production and maintenance) of the software. Software and its software parts may be prone to errors. For example, errors in software and / or its software parts can be checked by static software testing, wherein compared with dynamic software testing, the software is not executed. In the context of the present invention, the problematic ones are especially errors or weaknesses that damage or even endanger the safety of the software, and therefore damage or even endanger the safety of the technical system controlled, regulated and / or monitored by the software. In practice, despite exhaustive testing, such security holes (vulnerabilities for short) in individual software parts are not uncommonly identified only after a certain period of time. Therefore, during the life cycle of the software, the software parts of the software must be continuously monitored and the resulting vulnerabilities must be addressed. Well-known vulnerabilities are particularly critical, since they can be easily exploited by attackers.

[0002] Continuously updated and callable lists and / or databases of general vulnerabilities are known. An example of this is Common Vulnerabilities and Exposures (CVE), which is a reference system affiliated with the U.S. National Cybersecurity FFRDC and maintained by Mitre Corporation, with the goal of introducing a unified naming convention for security holes and other weaknesses in computer systems.

[0003] Individual software parts of software often also have a sufficiently large complexity that it should be accurately distinguished whether a known vulnerability assigned to this software part is also actually a security risk. In the case of large software, for example, hundreds or thousands of vulnerabilities associated with software parts used in the software may be generated (many of which are so-called false positives), but only about 3-10% of them are actually associated with security risks of the software (so-called true positives).

[0004] The invention is therefore based on the problem of providing an automatic but nevertheless reliable identification of relevant vulnerabilities, in particular wherein the number of false positives should be reduced or eliminated. Summary of the invention

[0005] A first general aspect of the present disclosure relates to a computer-implemented method for automatically identifying known vulnerabilities in static testing of software. The method may include extracting a data structure of the code of the software. The method further includes identifying one or more software parts based on the code, the extracted data structure and / or a software bill of materials (SBOM) of the software, the software being related to the one or more software parts. The method further includes, for at least one identified software part, evaluating whether to associate the software part with a known vulnerability, wherein one or more potentially vulnerable software parts are derived. The method further includes, for at least one potentially vulnerable software part, applying a machine learning model to a description assigned to the known vulnerability, wherein the machine learning model is trained and configured to determine at least one primary cause from at least the description and the hint. The method further includes evaluating at least one potentially vulnerable software part as vulnerable or not vulnerable or optionally not evaluable based on at least one primary cause and the extracted data structure (and / or code).

[0006] The software may be designed for controlling, regulating and / or monitoring a technical system, in particular a cyber-physical system, in particular at least one computing unit of a vehicle. The method may be performed in an electronic programming environment. The method may include outputting at least one software part evaluated as vulnerable, optionally via a user interface.

[0007] A second general aspect of the present disclosure relates to a computer system designed to perform a computer-implemented method for automatically identifying known vulnerabilities in static testing of software according to the first general aspect (or its embodiments).

[0008] A third general aspect of the present disclosure relates to a computer program designed to perform a computer-implemented method for automatically identifying known vulnerabilities in static testing of software according to the first general aspect (or its embodiments).

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

[0010] The method according to the first aspect (or its embodiment) proposed in the present disclosure is intended to automatically identify known vulnerabilities of software. It is thus possible to (better) identify known vulnerabilities related to the software (or its software parts). In particular, false positives can be significantly reduced or even completely eliminated. Therefore, in practice, this is particularly advantageous, because due to the usually high complexity of the software and its software parts, a large number of (absolutely also reaching hundreds of thousands) false positives may occur, which are difficult to be analyzed in depth with reasonable cost and identified as false positives. Due to the automatic and reliable identification disclosed here, (almost) only true positives are identified, which can then be solved by changing the software. The safety of the software can be improved thereby, as well as the safety of technical systems (such as vehicles) that are, for example, controlled, regulated and / or monitored by the software. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1a -b schematically illustrates a computer-implemented method for automatically identifying known vulnerabilities in static testing of software.

[0012] Figure 2 The data structure extracted from the software code, such as a control flow graph, is schematically shown. DETAILED DESCRIPTION

[0013] The method proposed in this disclosure aims to automatically identify known vulnerabilities of software.

[0014] To this end, a computer-implemented method 100 is disclosed, such as Figure 1a -b is schematically shown for automatically identifying known vulnerabilities (ie, known at least at the time of executing method 100) in static testing of software.

[0015] The method 100 may comprise extracting 110 a data structure 10 of the 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 the 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. The data structure 10 may be in a standard form if it is independent of the programming language in which the code is written. Alternatively or additionally, the data structure 10 may be in a standard form if it is independent of the target platform on which the code is executed. Alternatively or additionally, the data structure 10 may be in a standard form if it is independent of compiler instructions. Alternatively or additionally, the data structure 10 may be suitable for static testing of the software if it contains less information content than the code. In Figure 2 An exemplary data structure 10 (abstract syntax tree) is schematically shown in FIG.

[0016] Method 100 may include receiving code for software.

[0017] The method 100 further comprises identifying 120 one or more software parts based on the code, the extracted 110 data structure 10 and / or the software bill of materials (SBOM) of the software, the software being related to the one or more software parts. For example, identifying 120 one or more software parts can be based on the code. Alternatively or additionally, identifying 120 one or more software parts can be based on the extracted 110 data structure 10. Alternatively or additionally, identifying 120 one or more software parts can be based on the software bill of materials (SBOM) of the software. The one or more software parts can be, for example, external software parts. Code-based identification 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 included system files and / or included executable files.

[0018] The method 100 further comprises evaluating 130 for at least one identified 120 software portion whether the software portion is associated with a known vulnerability, wherein one or more potentially vulnerable software portions are derived. The method 100 may comprise evaluating for each identified 120 software portion whether the software portion is associated with a known vulnerability. The evaluation 130 may, for example, comprise calling a known vulnerability from a public database and / or a private database and comparing it with a known vulnerability. For example, the Common Vulnerabilities and Exposures (CVE) is publicly accessible as a reference system affiliated with the U.S. National Cybersecurity FFRDC and maintained by Mitre Corporation. An exemplary excerpt from a list of known vulnerabilities is reproduced below.

[0019] The method 100 further comprises, for at least one potentially vulnerable software, applying 140 a machine learning model to a description assigned to a known vulnerability (associating the known vulnerability with the potentially vulnerable software), wherein the machine learning model is trained and configured to determine at least one main cause from at least the description and the hint. The method 100 may comprise, for each potentially vulnerable software portion, applying the machine learning model to a description assigned to a known vulnerability (associating the known vulnerability with the corresponding potentially vulnerable software). For example, the description and / or the hint may be in English. Alternatively, the description and / or the hint may also be in other languages, such as German or Chinese. Using English may be advantageous because English is a programming-determining language. Furthermore, for example, CVE is published in English. Furthermore, a large language model comprised by the machine learning model may generally work well with English because a large portion of the training data utilized for training the large language model is generally already in English. The hint may comprise, for example, grammatical presets regarding input data (e.g., the format of an entry for a vulnerability) and / or output data (e.g., the format of one or more main causes) to the machine learning model. The grammatical presets may be advantageous for further machine processing. An exemplary prompt with grammatical presuppositions is reproduced below.

[0020] The method 100 comprises evaluating 150 at least one potentially vulnerable software part as vulnerable or not vulnerable or optionally as not evaluable, based on at least one main cause and the extracted 110 data structure 10 and / or based on the code. It may be advantageous to evaluate 150 based on at least one main cause and the extracted 110 data structure 10 (instead of the code) if the data structure 10 is in a standard form, in particular a parsable standard form, and if necessary the main causes (e.g. functions) can be reliably found therein. Alternatively, the evaluation 150 may be based on at least one main cause and the code (instead of the data structure 10). In such a case, it may be possible to omit the step of extracting 110 the data structure of the code of the software (instead of the data structure 10), for example even if the step of identifying 120 one or more software parts is not based on the data structure 10. Figure 1a -b).

[0021] The software may be designed for controlling, regulating and / or monitoring a technical system. The technical system may be, for example, a cyber-physical system. Alternatively or additionally, the technical system may include at least one computing unit (e.g., a control device) of the vehicle. For example, the technical system may be a braking system of the vehicle.

[0022] The method 100 can be performed in an electronic programming environment. This enables, for example, a user of the electronic programming environment (e.g., a software engineer) to take measures regarding software parts that have been evaluated 150 as vulnerable. Alternatively or additionally, further automatic analysis can also be performed in the electronic programming environment.

[0023] like Figure 1b As schematically shown in , method 100 may include outputting 160 at least one software part that is evaluated 150 as vulnerable. Outputting 160 may be performed, for example, via a user interface. The user interface may, for example, include a screen and at least one input interface (keyboard, mouse, touch screen). Alternatively or additionally, outputting 160 at least one software part that is evaluated 150 as vulnerable may be performed, for example, via an output file. Since at least one software part that is evaluated 150 as vulnerable is output 160, a user, such as a software engineer, may take measures to eliminate vulnerabilities in the software. This may improve the reliability and / or security of the software and generally improve the reliability and / or security of technical systems, especially information-physical systems, that are controlled, regulated and / or monitored by the software. For example, measures may include deleting software parts that are evaluated 150 as vulnerable. Here, for example, a software part may be replaced by a software part in a new (improved) version. Alternatively or additionally, the measures may, for example, include adapting software parts that are evaluated 150 as vulnerable.

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

[0025] The data structure may include or may be an abstract syntax tree. An abstract syntax tree may be a hierarchical representation of the decomposition of code into text. Alternatively or additionally, as in Figure 2 As schematically shown in , the data structure may include or may be a control flow graph. A control flow graph may be a directed graph for describing the program flow of a computer program (here: software). For example, starting from source code or compiled binary code, a p-code (the instruction set of a pseudo-machine, i.e., the instruction set of a virtual CPU) may be first generated and a control flow graph may be generated therefrom.

[0026] 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 a control flow graph from the abstract syntax tree. For example, such an action may be selected when extracting 110 the data structure 10 starting from source code.

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

[0028] For at least one identified software component, the evaluation 130 of whether the software component is to be associated with a known vulnerability can be based on a comparison of identifiers and / or metadata. In particular, for each identified 120 software component, the evaluation 130 of whether the corresponding software component is to be associated with a known vulnerability can be based on a comparison of identifiers and / or metadata. In particular, for example, each software component can each have a unique name and can each exist in a version (with sub-versions if necessary). In the evaluation 130, for example, the names and versions can then be compared.

[0029] The machine learning model may comprise a base model (e.g. in German: Basismodell) or may be a base model. The base model may be a large machine learning model that has been trained on a large range of large amounts of data (usually by self-supervised learning or semi-supervised learning) so that the large machine learning model can be adapted to a wide range of downstream tasks. In particular, the machine learning model may comprise a large language model (LLM) or be a large language model. A large language model may be a language model that is characterized by its size. In particular, a large language model may be a chatbot or have chatbot functionality.

[0030] For example, Google BERT can be used as a large language model. Alternatively or additionally, for example, OpenAI ChatGPT (for example in a version as of May 24, 2023) can be used as a large language model. Alternatively or additionally, for example, Hugging Face Bloom can be used as a large language model.

[0031] Alternatively or additionally, the machine learning model may include or be a multi-domain model. Here, for example, OpenAI GPT-4 (e.g., in a version as of March 14, 2023) may be used.

[0032] At least one main cause may for example be a (relevant, ie related to the associated known vulnerability) function, in particular wherein the function may be contained in a description (which is assigned to the known vulnerability). Determining at least one main cause may include filtering out (at least one) function from the description.

[0033] The prompt may include (or be) an instruction to a machine learning model (e.g., a base model) that is intended to extract one or more main causes from the description (or output: the main causes cannot be extracted). For example, the prompt may include (or be) a language instruction to a large language model (LLM) that is intended to extract one or more main causes from the description (or output: the main causes cannot be extracted). In other words, the machine learning model (here the LLM) does not have to be specially trained to extract the main causes. It may be sufficient that the machine learning model has generally been trained to have a certain understanding, in particular a certain language understanding, so that the prompt, in particular the language instruction, is understood by the machine learning model, and thereby enables the machine learning model to extract one or more main causes from the description.

[0034] Evaluating 150 at least one potentially vulnerable software portion as vulnerable or not vulnerable or optionally not evaluable based on at least one main cause and the extracted 110 data structure 10 may include checking whether functions belonging to the at least one main cause are contained in the extracted 110 data structure 10 (and are actually used).

[0035] Specific embodiments are described in more detail below. For example, p-code (see example below) can be generated from the source code (see example below) or compiled binary code (see example below) of the software, and a control flow graph can be generated based on the p-code, similar to Figure 2 . For example, based on the source code or other performed development, the included packages can be identified, and these findings can be used to generate a (complete) list of all possible included vulnerabilities. For each vulnerability found, a call can then be made as in, for example, Open AI ChatGPT (see example hint below) to identify at least one main cause. This main cause is then used to check, for example in a control flow graph, whether the function is included and used.

[0036] The exemplary source code is reproduced below:

[0037]

[0038]

[0039] An example (compiled) binary is reproduced below:

[0040] ,,01 00 02 00 25 64 20 0a 00 53 74 61 72 74 20 49

[0041] 44 41 20 54 72 61 63 69 6e 67 00 53 74 6f 70 20

[0042] 49 44 41 20 54 72 61 63 69 6e 67 00 01 1b 03 3b"

[0043] An exemplary p-code is reproduced below:

[0044]

[0045]

[0046]

[0047] An exemplary excerpt from the list of known vulnerabilities is reproduced below in English:

[0048] ,,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.11allows attackers to cause a denial of service(memory consumption)bytriggering mlx5_vector2eqn()failures,aka CID-c8c2a057fdc7

[0049] A flaw was discovered in OpenLDAP before 2.4.57 leading to a doublefree and slapd crash in the saslAuthzTo processing,resultingin denial ofservice

[0050] …“

[0051] An example including, for each description, an exemplary English prompt and a response generated by the machine learning model is reproduced below:

[0052] ,,You are expected to deliver answers as a security engineer.As suchI want you to extract the root cause of a CVE from its description.Answer asconcisely as possible.CVE:{cve}=>Answer:{answer}

[0053] CVE:A memory leak in the mlx5_fpga_conn_create_cq()functionindrivers / net / ethernet / mellanox / mlx5 / core / fpga / conn.c in the Linux kernelbefore 5.3.11allows attackers to cause a denial of service(memoryconsumption)by triggeringmlx5_vector2eqn()failures,aka CID-c8c2a057fdc7.

[0054] =>Answer:

[0055] -mlx5_fpga_conn_create_cq()

[0056] -mlx5_vector2eqn()

[0057] CVE:A heap out-of-bounds read / write vulnerability in the Linux Kerneltraffic control(QoS)subsystem can be exploited to achieve local privilegeescalation.Theqfq_change_class function does not properly limit the lmaxvariable which can lead toout-of-bounds read / write.If the TCA_QFQ_LMAX valueis not offered through nlattr,lmax is determined by the MTU value of thenetwork device.The MTU of the loopbackdevice can be set up to 2^31-1 and as aresult,it is possible to have an lmax value thatexceeds QFQ_MIN_LMAX.Werecommend upgrading past commit3037933448f60f9acb705997eae62013ecb81e0d.

[0058] =>Answer:

[0059] -qfq_change_class()

[0060] CVE:"managed-keys"is a feature which allows a BIND resolver toautomatically maintainthe keys used by trust anchors which operatorsconfigure for use in DNSSEC validation.Due to an error in the managed-keysfeature it is possible for a BIND server which usesmanaged-keys to exit dueto an assertion failure if,during key rollover,a trust anchor'skeys arereplaced with keys which use an unsupported algorithm.Versions affected:BIND9.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 the9.13development branch are also affected.Versions prior to BIND 9.9.0 havenot beenevaluated for vulnerability to CVE-2018-5745.

[0061] =>Answer:

[0062] root cause not identifiable

[0063] CVE:A use-after-free in Busybox's awk applet leads to denial ofservice and possibly codeexecution when processing a crafted awk pattern inthe hash_init function

[0064] =>Answer:

[0065] -hash_init()

[0066] CVE:A memory leak in the mlx5_fpga_conn_create_cq()functionindrivers / net / ethernet / mellanox / mlx5 / core / fpga / conn.c in the Linux kernelbefore 5.3.11allows attackers to cause a denial of service(memoryconsumption)by triggering

[0067] mlx5_vector2eqn()failures,aka CID-c8c2a057fdc7

[0068] =>Answer:

[0069] -mlx5_fpga_conn_create_cq()

[0070] CVE:A flaw was discovered in OpenLDAP before 2.4.57 leading to adouble free and slapd crash in the saslAuthzTo processing,resulting in denialof service

[0071] =>Answer:

[0072] -saslAuthzTo()“

[0073] For example, here 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 CVEfrom 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 indenial of service” outputs the main cause, saslAuthzTo()”.

[0074] Furthermore, a computer system is disclosed, which is designed to execute a computer-implemented method 100 for automatically identifying known vulnerabilities in static testing of software. The computer system may include a processor and / or a working memory.

[0075] Furthermore, a computer program is disclosed, which is designed to perform a computer-implemented method 100 for automatically identifying known vulnerabilities in static testing of software. For example, the computer program can be in an interpretable form or in a compiled form. The computer program can (also in parts) be loaded into the RAM of a computer, for example as a bit sequence or a byte sequence, for execution.

[0076] Furthermore, a computer-readable medium or signal storing and / or containing a computer program is disclosed. The medium may, for example, comprise one of a RAM, ROM, EPROM, HDD, SSD, ... on which / in which a signal is stored.

Claims

1. A computer-implemented method (100) for automatically identifying known vulnerabilities in static testing of software, comprising: - extracting (110) a data structure (10) of the code of said software; - identifying (120) one or more software parts based on the code, the extracted (110) data structure (10) and / or a software bill of materials (SBOM) of the software, the software being related to the one or more software parts; - for at least one identified ( 120 ) software component, evaluating ( 130 ) whether said software component is associated with a known vulnerability, wherein one or more potentially vulnerable software components are derived; - for at least one potentially vulnerable software component, applying a machine learning model to the description assigned to the known vulnerability, wherein the machine learning model is trained and configured to determine at least one primary cause from at least the description and the hint; - evaluating (150) at least one potentially vulnerable software part as vulnerable or not vulnerable or optionally not evaluable based on the at least one main cause and the extracted (110) data structure (10).

2. The method (100) according to claim 1, wherein the software is designed for controlling, regulating and / or monitoring a technical system, in particular a cyber-physical system, in particular at least one computing unit of a vehicle.

3. The method (100) according to claim 1 or 2, wherein the method (100) is performed in an electronic programming environment.

4. The method (100) according to any one of the preceding claims, comprising: - outputting (160) at least one software component evaluated (150) as vulnerable, optionally via a user interface.

5. The method (100) according to any one of the preceding claims, wherein the code comprises source code.

6. The method (100) of any one of the preceding claims, wherein the code comprises compiled binary code.

7. The method (100) of any one of the preceding claims, wherein the data structure comprises an abstract syntax tree.

8. The method (100) of any one of the preceding claims, wherein the data structure comprises a control flow graph.

9. The method (100) according to any 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. The method (100) according to any of the preceding claims, wherein the software part comprises a software package, a function and / or a library.

11. The method (100) according to any of the preceding claims, wherein evaluating (130) for at least one identified software component whether the software component is associated with a known vulnerability is based on a comparison of identifiers and / or metadata.

12. The method (100) of claim 11, wherein the identifier comprises a unique name of a software package, function and / or library.

13. The method (100) according to claim 11 or 12, wherein the metadata comprises version number, usage type, configuration and / or build options.

14. The method (100) of any preceding claim, wherein the machine learning model comprises a base model.

15. A method (100) according to any of the preceding claims, wherein the prompt comprises instructions to the machine learning model, the instructions being intended to extract one or more main causes from the description.

16. The method (100) of claim 14 or 15, wherein the machine learning model comprises a large language model (LLM).

17. The method (100) according to any of the preceding claims, wherein the at least one main cause is a function, in particular wherein the function is contained in the description.

18. The method (100) of claim 16 or 17, wherein the prompt comprises linguistic instructions to the large language model (LLM), the linguistic instructions being intended to extract one or more main reasons from the description.

19. A method (100) according to claim 17 or 18, wherein evaluating (150) the at least one potentially vulnerable software part as vulnerable or not vulnerable or optionally not evaluable based on the at least one main cause and the extracted (110) data structure (10) includes checking whether a function belonging to the at least one main cause is contained in the extracted (110) data structure (10).

20. A computer system designed to perform the computer-implemented method (100) for automatically identifying known vulnerabilities in static testing of software according to any one of the preceding claims.

21. A computer program designed to execute the computer-implemented method (100) for automatically identifying known vulnerabilities in static testing of software according to any one of claims 1 to 19.

22. A computer readable medium or signal storing and / or containing a computer program according to claim 21.

Images