Software verification device

Abstract

According to various embodiments, a software verification apparatus is described having: a rule database having a plurality of rules, each rule containing a criterion on one or more software characteristics and software characteristics, where the rule declares that software satisfying the criterion has software characteristics; an input interface designed to receive a software specification (e.g., source code); and one or more processors designed to determine which of the software characteristics the software has; on the basis of which software feature has been determined that the software has the software feature, which of the rules includes a satisfactory criterion is determined, and which of the software features the software has is determined from the rules including the satisfactory criterion. And determining whether one or more predefined requirements are satisfied for which the software has been determined to have its software characteristics.

Description

Technical Field

[0001] The present disclosure relates to a software verification device. Background Art

[0002] For many software applications, third-party software packages are used instead of writing all the program components by oneself. An example of this is an open source software package that can be downloaded from various registries and integrated into one's own software application. However, this requires a more thorough review of the software because third-party software potentially does not meet its expected requirements. Therefore, an effective process is desired to avoid using software that does not meet the expected requirements. Summary of the invention

[0003] According to various embodiments, a software verification device is provided, comprising: a rule database having a plurality of rules, wherein each rule comprises a standard regarding one or more software features and a software characteristic, wherein the rule states that software that meets the standard has the software characteristic; an input interface, wherein the input interface is designed to receive a software specification (e.g., source code); and one or more processors, which are designed to:

[0004] Find out which of the software features the software has;

[0005] determining which of the rules contain criteria that are satisfied (by the software), based on which software feature it has been determined that the software has the software feature;

[0006] Finding which of the software characteristics the software has based on rules containing criteria satisfied by the software, and

[0007] · determining whether a software characteristic satisfies one or more preset requirements, for which it has been determined that the software has the software characteristic; and

[0008] An output interface, wherein the output interface is designed to enable the use of the software through a data processing device (another data processing device different from the software safety checking device or the same data processing device as the software safety checking device) if (i.e., for example, in response to) it has been determined (by one or more processors) that a software characteristic satisfies one or more preset requirements, for which it has been determined by one or more processors that the software has the software characteristic.

[0009] The software verification device described above automatically extracts characteristics, such as the behavior of software (e.g., of an unknown software package) and ensures, for example, that the software is enabled for use only when the required requirements are met by the extracted characteristics. This can prevent the use of malicious (or also harmful due to inappropriate characteristics) software.

[0010] Various embodiments are described below.

[0011] Embodiment 1 is the software verification device as described above.

[0012] Embodiment 2 is a software verification apparatus according to embodiment 1, wherein for at least some of the rules (possibly all of the rules), the criterion is a Boolean function of one or more software features.

[0013] This enables efficient modeling and checking of various software characteristics.

[0014] Embodiment 3 is a software verification device according to Embodiment 1 or 2, wherein one or more preset requirements include: (through one or more processors) the software characteristics that have been determined for the software are within a preset allowed set of software characteristics; and / or (through one or more processors) the software characteristics that have been determined for the software cover a preset set of required software characteristics.

[0015] Thus, software with certain properties may be excluded (eg, "malicious" properties are not allowed) and / or certain properties may be required (eg, properties that certain redundancies exist or that the software is of a certain type (eg, "math library")).

[0016] Embodiment 4 is a software verification device according to one of embodiments 1 to 3, wherein the software feature is that the software is malicious, and the one or more requirements include a requirement that the software is not malicious.

[0017] Ultimately, in this case, the equipment used for software verification acts as a security probe.

[0018] Embodiment 5 is a software verification device according to any one of embodiments 1 to 4, wherein the rule database includes at least one rule for each software characteristic among a plurality of software characteristics, and the rule includes the software characteristic.

[0019] For example, multiple software characteristics may be tested, that is, to find out whether the software has software characteristics that together result in a specific behavior, so that the behavior of the software can be found and enabled according to the found behavior.

[0020] Embodiment 6 is a software verification device according to one of embodiments 1 to 5, wherein at least one software characteristic is a software type.

[0021] In particular, it can be determined whether the software is of the expected software type (eg, a library having functions for a specific application field, etc.).

[0022] Embodiment 7 is a software verification device according to one of embodiments 1 to 3, wherein at least some of the rules are fuzzy logic rules.

[0023] This allows for more flexible definition of rules to detect specific software features.

[0024] Embodiment 8 is a software verification device according to one of embodiments 1 to 7, having a user interface for defining at least a part of the rules of the rule database.

[0025] This allows software to be automatically checked for specific characteristics based on rules defined by a human user.

[0026] Embodiment 9 is a software verification apparatus according to one of embodiments 1 to 8, wherein the data processing device is a control device, and the software is at least a part of a control program for a robot device. .

[0027] Thus, for example, the safety of robot control can be guaranteed.

[0028] Embodiment 10 is a method for verifying software, comprising: storing multiple rules, each rule including standards regarding one or more software features and software characteristics, wherein the rule states that: software that meets the standards has the software characteristics; receiving software specifications; finding out which of the software characteristics the software has; based on which software characteristic the software has been found to have, finding out which of the rules contain standards that are met (by the software); finding out which of the software characteristics the software has based on the rules that contain the met standards; finding out whether the software characteristics meet one or more preset requirements, for which the software characteristics have been found to have the software characteristics; and if it has been found that the software characteristics meet one or more preset requirements, for which the software has been found to have the software characteristics, enabling use of the software through a data processing device.

[0029] Embodiment 11 is a computer program having instructions, which, when executed by a processor, cause the processor to perform the method according to embodiment 10.

[0030] Embodiment 12 is a computer-readable medium storing instructions, which, when executed by a processor, cause the processor to perform the method according to embodiment 10.

[0031] It should be noted that the embodiments described in conjunction with the software verification apparatus can similarly be applied to the method for verifying software. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In the accompanying drawings, similar reference numerals generally refer to the same parts in completely different views. The accompanying drawings are not necessarily to scale, where emphasis is generally placed on describing the principles of the invention instead. In the following description, various aspects are described with reference to the following drawings.

[0033] Figure 1A computer for developing and / or reviewing software applications is shown.

[0034] Figure 2 A description of the architecture of an automatic behavior extractor according to one embodiment is illustrated. DETAILED DESCRIPTION

[0035] The following detailed description is with reference to the accompanying drawings, which illustrate the specific details and aspects of the present invention that can be implemented for the purpose of explanation. Other aspects may be used and structural, logical and electrical changes may be performed without departing from the scope of protection of the present invention. Various aspects of the present invention are not necessarily mutually exclusive, because some aspects of the present invention may be combined with one or more other aspects of the present invention to form new aspects.

[0036] Various examples are described in more detail below.

[0037] Figure 1 A computer 100 is shown for use in developing and / or reviewing software applications.

[0038] The computer 100 has a CPU (Central Processing Unit) 101 and a work memory (RAM) 102. The work memory 102 is used to load a program code from a hard disk 103, for example, and the CPU 101 executes the program code.

[0039] In the present example it is assumed that a user (developer) intends to develop and / or test a software application using computer 100 .

[0040] To this end, the user executes the software development environment 104 on the CPU 101 .

[0041] The software development environment 104 enables the user to develop and test applications (i.e., software) 105 for various devices 106 or also for mobile (communication) devices, which are target hardware, such as embedded systems for controlling robotic devices, including robot arms and autonomous vehicles. To this end, the CPU 101 can execute a simulator as part of the software development environment 104 to simulate the behavior of the corresponding device 106 for which the application is developed or has been developed. If the software development environment 104 is only used to test (or check) software from another source, the software development environment 104 can also be regarded or designed as a software testing environment (and thus the computer is particularly regarded or designed as a software verification device).

[0042] The user can distribute the finished application to the corresponding device 106 via the communication network 107. Instead of via the communication network 107, this can also be done in other ways, for example by means of a USB stick.

[0043] However, before this happens, the user should perform a verification of the application 105, i.e. gain knowledge of whether the application 105 has certain properties, such as that it is not malicious, in order to avoid distributing incorrectly working applications to the device 106. This would also be the case if the user did not write the application 105 at least partially himself, but for example adopted program components from a third-party provider, such as libraries, in particular from an open source software package.

[0044] Open source software packages have become an essential cornerstone of modern software development. It is estimated that free and open source software accounts for 70% to 90% of all modern software solutions. As a result, the availability of software packages determines almost every aspect of modern software-based solutions, products, and services. Many packages can be downloaded from one of a large number of package registries (also known as repositories), including npm (JavaScript), PyPI (Python), RubyGems (Ruby), and others. Developers publish tens of thousands of updates to these registries and upload hundreds of new packages every day—resulting in a collection of millions of publicly available packages. Unfortunately, this large amount of free software comes at a price: potentially malicious or harmful software. The increased risk is due to several factors: (1) anyone can upload a package, (2) only a limited number of packages are digitally signed or checked, and (3) registries often have no active identification mechanisms. This environment is ripe for the integration of tampered packages in order to carry out attacks, such as those targeting the supply chain.

[0045] According to various embodiments, a processing method is provided, which realizes: for an unknown software package (i.e., one or more programs that may be part of a larger program, such as one or more program components of an application 105), a behavior description (i.e., the characteristics of the software) is automatically extracted from the software package, or ensures: one or more programs included in the software package have the expected characteristics (e.g., benign). For example, the software development environment 104 implements a corresponding tool 108 (the tool can be regarded as a verification tool), and the tool implements the processing method described below.

[0046] According to various embodiments, a behavioral description of a software package is automatically extracted (or based on a verification that one or more programs contained in the software package have the desired properties based on an automatic behavior extractor E (e.g. as part of the verification tool 108) for automatically creating a behavioral description of the software package p (or any software)). It should be noted that the term software package is not limited to software components from an online registry. In principle, any code snippet and any software field can be used as input for the extraction.

[0047] Figure 2 A description of the architecture 200 of an automatic behavior extractor E according to one embodiment is illustrated.

[0048] In this example the features are: Check the package (ie software): whether the package is benign or malicious and what type of software it is.

[0049] The input of E is unknown package p u "Unknown" may refer to a piece of software that a user (e.g., a user of computer 100) wishes to examine for what behavioral features exist in the code. The behavior extractor E comprises a behavior extraction chain H. H comprises four interconnected databases:

[0050] - Signature database: The signature database stores signatures C. A signature defines a series of individual characteristics that indicate a specific characteristic (eg potentially malicious behavior, a specific software type, etc.).

[0051] - Verifier database: said verifier database contains information about the verifier V, ie about the set of tools, methods and systems implementing the check for each feature C whether a given software package has said feature.

[0052] - Rulebook (rule database) B: This contains a series of rules, where each rule contains criteria (e.g. in the form of a corresponding Boolean function with features as input variables). Each rule is also associated with a characteristic (in this example, "malicious" behavior) and states that if the criteria of the rule (i.e. the criteria contained in the rule) are met, then the software has this characteristic.

[0053] - Software Type Database (T): contains known types of software, where each software type is associated with one or more rules in the rulebook.

[0054] In the example described, the rulebook stores a series of rules that define specific behaviors that can be associated with a particular type of software package, in the example benign / malicious: A single rule defines what a human (or any form of reasoning generative model) would define as malicious behavior. The rulebook can be extended at any time by rule writers W. For example, if necessary, a user can write new rules and Figure 2201. The rule writer may be a (human) user, a machine learning based model or any other process that can create appropriate rules. The rules may be adapted based on the evidence generated to better detect malicious behavior checks. The rules contain two main elements: features and operators. Features, for example, describe specific functions of a software package, such as "establishing a connection to an external server", "processing passwords", "storing data", etc. Each feature may be checked (verified) by one or more of the verifiers. It should be noted that each feature itself is not necessarily an indicator of malicious behavior. However, with the help of the logical operator O, rules may be formed that implement: modeling malicious behavior together with each harmless feature. For example, some features (possibly in combination) are only a characterization of malware for a specific software type. Then corresponding rules may be formulated that combine the features (e.g., in combination) with the following features that characterize the software type in combination (i.e., the rule is, for example, an "and" association of two combinations, so that the software is detected as malicious only when the features that show the maliciousness of the software type are satisfied and the features that show the software type are satisfied, but other association operators may also be used, such as or, not, etc.). As described above, individual rules can also be associated with specific software types (i.e., if the software type exists, the criteria contained in the rule are met), so that the software type can be detected (i.e., such a rule contains a combination of features that indicate the software type only when the criteria contained in such a rule are met).

[0055] For example, a math library should with the highest probability not establish connections to external servers during calculations. However, for an authentication package that communicates with an external service, connections to external servers can be completely harmless behavior. Thus, the described approach achieves the transformation of a human-understandable description of malicious behavior into evaluable rules.

[0056] As in Figure 2 As described in , behavior extraction is performed, for example, as follows:

[0057] 1. For p u Execute the behavior extraction chain (H) for all available validators V.

[0058] 2. The dependency on the feature database C is tracked only for the verifiers that give a positive (“true”) evaluation. All features referenced in this way, i.e., for which the corresponding verifier has respectively determined p u The set of all features C' having this feature is stored separately for evaluation.

[0059] 3. In the next step, the dependency chain is run through to the rule book, i.e. rules are selected from the rule book that only contain referenced features, i.e. features from set C', executed (i.e. evaluated: whether their criteria are met), and the rules that meet their criteria are stored in set R' for evaluation.

[0060] 4. Finally, all software types associated with at least one rule that meets its criteria (and is thus included in R') are extracted from the software type database. The extracted software types are stored as a set T' for evaluation.

[0061] 5. Perform an evaluation based on C', R' and T'. This can be an enable signal indicating that the software package has the desired characteristics (i.e. a positive verification result), a signal indicating that the software package does not have at least one desired characteristic (and thus refusing to enable and, for example, refusing to use and / or distribute the software contained in the software package), or also creating a signal indicating that the input package p u behavioral characteristics of the report.

[0062] The software type database T can be populated with the available software types as follows:

[0063] - One or more possible types may be manually extracted from descriptions, keywords, documentation, and other content available online in a corresponding registry (e.g., on a specific package website on npm).

[0064] - One or more possible types can be extracted from the software package with the aid of a script that automatically searches the mentioned content of the software package.

[0065] - One or more possible types can be extracted with the help of machine learning based package content analysis.

[0066] - Types may be manually defined (by the user) based on assumptions about functionality (e.g. if the user intends to use a math library, then the type "math library" may be accommodated in T, since the existence of that type is plausible; nevertheless, the rules may check whether that type actually exists).

[0067] Examples of types are "Math Library", "Image Rendering Library", "Cryptography Library", "Machine Learning Library", "Database", etc.

[0068] According to one embodiment, if the set of logical operators O used by the behavior extractor E is too strict for some rules, the behavior extractor E can support fuzzy logic to express more "fuzzy" conditions. In terms of rules, this means including assessments of specific behaviors, such as "frequent", "slow", "medium", "high". Instead, for example, if r = "connected to an external server" is satisfied (in this example, the criterion of the rule has only one feature, but the rule can also be a combination of multiple features accordingly), then p can be said to be malicious and r = "very frequently connected to an external server" can be defined. Therefore, with the help of fuzzy logic, the processing method described here can be adapted so that specific malicious or benign behaviors (which may be specific to each software type, such as expressed above by the corresponding features in the rules) can be better detected and described.

[0069] In summary, according to various embodiments, there is provided a software verification apparatus (e.g., in the form of a data processing device such as the data processing device 100 or a component thereof), the software verification apparatus having:

[0070] A rule database having a plurality of rules, wherein each rule contains a standard regarding one or more software features and a software characteristic, wherein the rule states that software that meets the standard has the software characteristic; an input interface, wherein the input interface is designed to receive a specification (such as source code) of the software; and one or more processors, which are designed to

[0071] Find out which of the software features the software has;

[0072] Based on which software feature it has been determined that the software has the software feature, determining which of the rules contain a satisfied criterion;

[0073] Finding which of the software characteristics the software has based on rules containing satisfied criteria, and

[0074] · determining whether a software characteristic satisfies one or more pre-set requirements, for which it has been determined that the software has the software characteristic; and

[0075] An output interface (e.g., an interface to the network 107), wherein the output interface is designed to enable use of the software via a data processing device (a data processing device different from or the same as the data processing device that implements the software security check device) if (i.e., for example, in response to) it has been determined (via one or more processors) that a software characteristic satisfies one or more preset requirements, for which it has been determined via one or more processors that the software has the software characteristic.

[0076] The software verification device can be executed by one or more computers with one or more data processing units. The term "data processing unit" can be understood as any type of entity that implements processing data or signals. For example, data or signals can be processed according to at least one (i.e., one or more than one) specific function performed by a data processing unit. The data processing unit may include an analog circuit, a digital circuit, a logic circuit, a microprocessor, a microcontroller, a central unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a programmable gate array integrated circuit (FPGA) or any combination thereof or be composed of them. Any other means for implementing the corresponding functions described in more detail herein may also be understood as a data processing unit or a logic circuit device. One or more of the method steps described in detail herein can be performed (e.g., implemented) by a data processing unit through one or more specific functions performed by the data processing unit.

[0077] According to various embodiments, the provided processing method (or software verification device) has the following characteristics or implementations:

[0078] 1. Create a behavior description report based on a set of well-defined and human-understandable features and rules (e.g., by an automatic behavior extractor E). The created report thus provides extremely reliable and easy-to-understand descriptions that can be used for various purposes:

[0079] -Analyze potential malicious / benign behavior of unknown types of software. Here, the generated report can explain: which validators, features and rules are "real" for a given software.

[0080] - The generated report can be used to check whether specific requirements are actually implemented in the software. Therefore, the software verification device is not limited to applications for identifying malicious / benign software.

[0081] - The software verification device can also be used as a kind of software type classifier. Thus, for example, a general software type can be determined based on the triggered verifiers, features and rules.

[0082] 2. Various databases within the behavior chain provide a high degree of adaptability and flexibility when defining new rules. For example, comprehensive rules can be created by nesting existing rules in the database.

[0083] 3. The software verification device can be designed so that the number of registered verifiers, features, rules and types in H increases with each use (by recording them in the corresponding database through the software verification device), so that the software verification device becomes more and more effective over time.

[0084] 4. Once H is populated with data, the behavior extractor E can be integrated into an automated development environment (e.g., software development environment 104). For example, analysis can be automatically triggered during testing and a report on the behavior can be created. This report can then be used as input for various security checks.

[0085] 5. Software verification devices can be used for open source and closed source software.

[0086] 6. The software verification device can support the analysis of any software code written in any programming language as long as the verifier supports the target language.

[0087] 7. The software verification device may support fuzzy logic to achieve a more accurate description of the software characteristics of the software package (eg, malicious and benign behaviors or software types).

[0088] The software being validated (or an application containing the software as a component) can be, for example, a control program or a control program component for a robotic device. The term "robotic device" can be understood as any engineering system (having mechanical parts whose movements are controlled and thus have trajectories), such as: a computer-controlled machine, a vehicle, a household appliance, a power tool, a manufacturing machine, a personal assistant or an access control system. The software can also be part of an infotainment system in a vehicle or also a software app on a mobile phone, which communicates with other devices (e.g. robotic devices, such as vehicles or robots).

Claims

1. A software verification device (100), comprising: A rule database having a plurality of rules, wherein each rule contains criteria regarding one or more software features and software characteristics, wherein the rule states that software (105) that meets the criteria has the software characteristics; an input interface, the input interface being designed to receive specifications of the software (105); One or more processors (101) configured to - finding out which of the software features the software (105) has; - based on which software feature it has been determined that the software (105) has the software feature, determining which of the rules contain a criterion that is met, - determining which of the software characteristics the software (105) has according to a rule containing criteria that are satisfied, and - determining whether the software characteristic meets one or more preset requirements, for which it has been determined that the software (105) has the software characteristic; An output interface, wherein the output interface is designed to: if it has been determined that the software characteristic satisfies the one or more preset requirements, and it has been determined by the one or more processors (101) that the software (105) has the software characteristic, then use of the software (105) is enabled by a data processing device (106).

2. The software verification apparatus (100) according to claim 1, wherein for at least some of the rules, the criterion is a Boolean function of the one or more software features.

3. A software verification device (100) according to claim 1 or 2, wherein the one or more preset requirements include: the software characteristics for which it has been determined that the software (105) has are within a preset allowed set of software characteristics; and / or the software characteristics for which it has been determined that the software (105) has covers a preset set of required software characteristics.

4. The software verification device (100) according to any one of claims 1 to 3, wherein the software characteristic is that the software (105) is malicious, and the one or more requirements include a requirement that the software (105) is not malicious.

5. The software verification device (100) according to any one of claims 1 to 4, wherein the rule database contains at least one rule for each software characteristic of a plurality of software characteristics, the rule containing the software characteristic.

6. The software verification device (100) according to any one of claims 1 to 5, wherein at least one software characteristic is a software type.

7. The software verification device (100) according to any one of claims 1 to 3, wherein at least some of the rules are fuzzy logic rules.

8. The software verification device (100) according to any one of claims 1 to 7, comprising a user interface for defining at least a part of the rules of the rule database.

9. A software verification apparatus (100) according to any one of claims 1 to 8, wherein the data processing device (106) is a control device, and the software (105) is at least a part of a control program for a robotic device.

10. A method (105) for verifying software, comprising: Storing a plurality of rules, wherein each rule comprises a standard regarding one or more software features and a software characteristic, wherein the rule states that software (105) that meets the standard has the software characteristic; receiving a specification of software (105); Finding which of the software features the software (105) has; determining which of the rules contain a satisfied criterion based on which software feature it has been determined that the software (105) has the software feature; Determining which of the software characteristics the software (105) has based on the rules including the criteria that are satisfied; and Determining whether the software characteristic satisfies one or more preset requirements, and determining whether the software characteristic (105) has the software characteristic; and If it has been determined that the software characteristic satisfies the one or more preset requirements and it has been determined that the software (105) has the software characteristic, use of the software (105) is enabled via a data processing device (106).

11. A computer program having instructions which, when executed by a processor (101), cause the processor (101) to perform the method according to claim 10.

12. A computer readable medium storing instructions which, when executed by a processor (101), cause the processor (101) to perform the method according to claim 10.

Images