CN118332553A - Method for inspecting products - Google Patents

Abstract

The invention relates to a method (100) for inspecting a product (30), wherein the product (30) has a plurality of software components (200), comprising the steps of: determining (101) at least one vulnerability profile (240) based on the vulnerability specification (220) and the product specification (210), wherein the product specification (210) specifies a software component (200) of the product (30) and the vulnerability specification (220) specifies at least one vulnerability of the software component (200), wherein the respective vulnerability profile (240) specifies at least one attack possibility in accordance with the at least one vulnerability; determining (102) a product profile (230) of the product (30) detailing at least one attack possibility from the product (30); determining (103) at least one relevant vulnerability based on a comparison of the respective vulnerability profile (240) with the determined product profile (230), wherein the at least one relevant vulnerability is related to the information security of the product (30); outputting (104) the at least one relevant vulnerability.

Description

Method for inspecting products

Technical Field

The present invention relates to a method for inspecting a product. The invention also relates to a computer program and an apparatus for this purpose.

Background

Known security related products are checked against known vulnerabilities during their development phase. This is typically done by comparing a so-called "vulnerability database", i.e. a vulnerability database such as NVD (National Vulnerability Database ) or similar database, with a software bill of materials (Software Bill ofMaterials, SBOM) in which the software components used in the respective products are listed.

Such a check for known vulnerabilities is highly desirable from a security standpoint, and typically results in a long string of known vulnerabilities contained in a vulnerability database. However, it is generally unclear here which of these reported vulnerabilities are actually relevant to a particular product. For example, about 6000 known security holes for Linux kernel 4.14 are listed in NVD. However, each of these errors is only relevant to the particular product if the corresponding kernel function is actually used and the error, in terms of specification of the particular product and its software configuration, can actually be exploited in practice.

Disclosure of Invention

The subject of the invention is a method having the features of claim 1, a computer program having the features of claim 9 and a device having the features of claim 10. Further features and details of the invention emerge from the respective dependent claims, the description and the figures. The features and details described in connection with the method according to the invention are of course also applicable here in connection with the computer program according to the invention and the device according to the invention and vice versa, so that the disclosures of the various aspects of the invention are always mutually referenced or can always be mutually referenced.

The subject matter of the invention is in particular a method for inspecting a product, preferably for determining at least one relevant vulnerability of said product and/or for outputting a relevant vulnerability (english vulnerability). Here, the product may have a plurality of software components. Correspondingly, the product can also be designed as a software product. Optionally, the product may also have hardware components. Furthermore, the vulnerabilities may be designed as security-related vulnerabilities and/or information technology vulnerabilities that may cause damage if exploited by an attacker.

The method may comprise the steps of at least partially repeatedly and/or successively and/or automatically:

Determining at least one vulnerability profile based on a vulnerability specification, such as a database, such as an NVD (national vulnerability database), and a product specification, such as an SBOM, wherein the product specification may specify software components of the product and the vulnerability specification may specify at least one vulnerability of the software components, wherein the respective vulnerability profile may specify at least one attack possibility in accordance with the at least one vulnerability,

Determining a product profile of the product, the product profile specifying at least one attack potential based on the product,

Determining at least one relevant vulnerability based on a comparison of the respective vulnerability profile with the determined product profile, wherein the at least one relevant vulnerability may be relevant to the information security of the product,

-Outputting the at least one relevant vulnerability.

Thus, the present invention has the advantage of being able to automatically and reliably determine relevant vulnerabilities for a particular product. Most software vulnerabilities can only be exploited under certain conditions. Even if a vulnerable (English vulnerable) version of the software component is used in a particular product, it is unclear whether the vulnerability can actually be exploited. This is typically associated with standard SBOMs that do not contain information about the presence of these determined conditions for a product (the presence of these conditions is also referred to as attack possibilities in particular). Thus, checking products based on databases with known vulnerabilities can lead to a large number of false positives that must be manually eliminated. This results in a high outlay for error checking of such products. Thus, an advantage of the present invention may be that false positive results may be automatically eliminated or at least the number of false positive results may be reduced based on the determined correlation, especially in SBOM-based product inspection against known vulnerability databases.

Providing a product profile and/or a corresponding vulnerability profile may be performed, for example, based on a vulnerability report and SBOM for a particular product and, if necessary, the source code for the particular product. It may then be automatically determined which known vulnerabilities from a database such as NVD are actually relevant to the product. In particular, there is a correlation with the product when a particular vulnerable function of the library or a particular vulnerable feature of the Linux kernel is actually used in the source code of the product.

The invention may also have the advantage of enabling a coordinated collaboration between the software developer and the software user. To this end, it is preferable that extensibility descriptions of vulnerabilities and extensibility descriptions of the characteristics of software-based products that may be relevant to those vulnerabilities may be output.

Outputting the at least one relevant vulnerability may be done, for example, on a display screen and/or touch screen and/or in a non-volatile data store as digital information such as a file. Data transmission for output may also be performed, for example via the internet and/or via radio.

The detailed description of the software components in the product specification may be made, for example, by describing technical specifications regarding the type and/or version of the software components and/or existing functions and/or functions used. The product profile may specify the attack possibilities, for example by specifying the version of the software component and/or existing functions and/or functions used.

Furthermore, it may be provided within the scope of the present invention that the determining of the at least one vulnerability profile comprises the steps of:

Comparing, based on a vulnerability specification (preferably in the form of a database of vulnerabilities with respect to various software components) and a product specification (preferably in the form of a list of software components for a specific product and/or in the form of SBOM), to determine vulnerable software components for the product, wherein preferably the vulnerability specification is product-independent and the product specification is dependent on the product, wherein the software components are vulnerable, in particular when vulnerabilities are specified in the vulnerability specification for the software components.

Further, the determination of at least one relevant vulnerability may be performed to determine vulnerable software components of the vulnerable software components that may be utilized for at least one attack likelihood based on the at least one vulnerability in the particular product. The comparison may be performed, for example, by comparing an entry in the vulnerability specification with an entry in the product specification. In particular, such vulnerabilities may be determined from vulnerability specifications of software components assigned to the product in this manner. The allocation may also relate to, for example, the version of the software component and/or the functionality of the software component. The allocation may be defined in a vulnerability specification. In this way, vulnerability profiles can be determined for those vulnerabilities that exist in principle in the product and thus potentially could be exploited if certain conditions exist.

It is furthermore conceivable that the determination of the at least one vulnerability profile comprises the following steps:

-checking whether software components specified by the product specification agree with software components specified in the vulnerability specification to determine those vulnerabilities assigned to the agreed software components according to the vulnerability specification, wherein preferably a vulnerability profile assigned to these determined vulnerabilities is determined to query for the presence and/or number of vulnerabilities of the product.

This makes it possible to determine vulnerability profiles for those vulnerabilities that exist in principle in the product and thus may potentially be exploited if certain conditions exist.

Additional advantages may be realized within the scope of the invention if the product profile specifies at least one attack possibility and preferably a plurality of attack possibilities in terms of the product, preferably based on the software structure and/or hardware structure of the product. Further, as the determined at least one vulnerability profile, a plurality of vulnerability profiles may be determined for a plurality of vulnerabilities specifying a plurality of attack possibilities according to vulnerabilities of the software component preferably depending on the product, wherein the number of attack possibilities specified may be greater than the number of attack possibilities according to the product. Here, as at least one vulnerability profile, a plurality of vulnerability profiles may also be determined for each vulnerability of the software components of the product, particularly preferably at least five or at least 10 or at least 20 vulnerability profiles. Here, both the vulnerability profile and the product profile of the respective vulnerability illustrate the attack possibilities, i.e. in particular the conditions that have to be present in order to be able to exploit the respective vulnerability present in the product. In other words, the corresponding vulnerability profile defines which conditions must exist for the product to exploit the vulnerability (e.g., a determined software version and/or software functionality). The existence of vulnerabilities depends on the software component, but it is not necessary to know whether more specific conditions exist for the product in fact. The product profile can in turn define which conditions actually exist for the product by accounting for attack possibilities. By comparing the likelihood of attack from the product profile to the likelihood of attack from the vulnerability profile, vulnerabilities associated with the product can be determined.

It is furthermore conceivable that, when comparing the respective vulnerability profile with the determined product profile, it is checked whether at least one attack probability according to at least one vulnerability corresponds to at least one attack probability according to the product, preferably whether the respective attack probability specified by the vulnerability profile is also present in the product profile. This allows for reliable determination of the relevance of the vulnerability to the product.

Further, it is optionally provided that by comparing the respective vulnerability profile with the determined product profile, it is checked whether the respective vulnerability of the software component for the product is suitable to be exploited for attacking the product. Not every vulnerability can be exploited in specific situations, for example when the conditions necessary for the exploitation, such as the use of certain functions, are not present for the product. The product profile may define which conditions actually exist for the product by accounting for the attack possibilities and thus providing the possibility to exploit vulnerabilities for the attack.

Furthermore, it can be provided within the scope of the invention that the product profile and the corresponding vulnerability profile have a common taxonomy and are each preferably designed as a list and/or file. This enables the comparison and/or determination of relevant vulnerabilities to be performed automatically.

It is furthermore conceivable that the product is intended for controlling a machine and/or a robot, preferably a vehicle, such as a motor vehicle and/or an autonomous vehicle. The steps of the method may be repeated automatically, preferably by a cloud service, in particular for monitoring the information security of the product during operation of the machine. The vehicle may be automatically controlled, for example, by an autonomous driving function and/or a driver assistance system provided at least in part by the product.

The subject of the invention is also a computer program, in particular a computer program product, comprising instructions which, when the computer program is executed by a computer, cause the computer to carry out the method according to the invention. The computer program according to the invention therefore brings about the same advantages as described in detail with reference to the method according to the invention.

The subject of the invention is also a device for data processing, which device is arranged to perform the method according to the invention. As the apparatus, for example, a computer executing the computer program according to the present invention may be specified. The computer may have at least one processor for executing a computer program. A non-volatile data memory may also be provided in which the computer program is stored and from which the processor may read for execution.

Also, the subject matter of the present invention can be a computer-readable storage medium comprising a computer program according to the present invention. The storage medium is designed, for example, as a data memory such as a hard disk and/or as a non-volatile memory and/or as a memory card. The storage medium may for example be integrated into the computer.

In addition, the method according to the invention can also be designed as a computer-implemented method.

Drawings

Further advantages, features and details of the invention emerge from the following description, wherein embodiments of the invention are described in detail with reference to the accompanying drawings. The features mentioned in the claims and in the description may be essential to the invention individually or in any combination.

Fig. 1 shows a schematic diagram of a method, apparatus and computer program according to an embodiment of the invention.

In the following figures, the same reference numerals are used even for the same technical features of the different embodiments.

Detailed Description

A method 100 for inspecting a product 30 is shown in fig. 1, wherein the product 30 may have a plurality of software components 200. Correspondingly, the product 30 may be designed as a software product, which is used, for example, in the machine 40.

According to a first method step 101, the method 100 comprises determining at least one vulnerability profile 240 based on a vulnerability specification 220 (e.g. a database such as NVD) and a product specification 210 such as SBOM. The determination may be performed, for example, by a data call, for example, via the internet. Further, the product specification 210 may specify the software component 200 of the product 30, and the vulnerability specification 220 may specify at least one vulnerability for the software component 200. The vulnerability specification 220 may generally describe herein the vulnerability based solely on knowledge of the existence of software components 200, such as a determined operating system, without specific product references. Rather, the product specification 210 may already have specific product references and specify which software components 200 are present for the product 30. The detailed description of the software component 200 by the product specification 210 may be text-based, for example, in a manner that describes technical specifications regarding the type and/or version of the software component and/or existing functions and/or functions used. The resulting corresponding vulnerability profile 240 may specify at least one attack possibility in terms of at least one vulnerability, i.e., specifically, which conditions may be exploited by the software component 200 of the product 30 (but without regard to whether such conditions are actually present for a particular product 30).

According to the second method step 102, a determination of the product profile 230 of the product 30 may be specified, wherein the product profile 230 specifies at least one attack possibility from the product 30. Thus, it can be stated here whether these conditions are actually present for a particular product 30.

Subsequently, according to a third method step 103, at least one relevant vulnerability may be determined based on a comparison of the respective vulnerability profile 240 with the determined product profile 230. When the conditions exist for the product 30 so that the vulnerability can be exploited, the vulnerability can be relevant. In other words, to do so, the product 30 must provide the attack possibilities from the product profile 230 that are required to exploit the vulnerability from the vulnerability profile 240. At least one relevant vulnerability is related to the information security of the product 30, since exploitation of the vulnerability may result in a compromise in the information security sense. After the relevant vulnerabilities are determined, they may be output in a fourth method step 104.

Furthermore, a computer program 20 for executing the method 100 and a device 10 for executing the method 100 are shown in fig. 1. Furthermore, it is shown that the product 30 may be intended for controlling a machine 40 (preferably a vehicle 40) and/or a robot 40. Further, it is shown that the product 30 may have one or more software components 200, each of which may provide attack possibilities with a corresponding vulnerability. Here, the application objective of the method 100 may be to evaluate the correlation of known vulnerabilities with the likelihood of attack provided by the software component 200.

In embodiments of the invention, classification methods may be provided that provide attacker capabilities, in particular attack possibilities. The taxonomies may be used to create at least one vulnerability profile 240 listing such attacker capabilities, and preferably all of the attacker capabilities, required to actually exploit the determined vulnerability.

According to an implementation variant of the present invention, such vulnerability profiles 240 may be digitized specifications with a list of key-value pairs, such as files, for example text files. These keys may be descriptive of the individual capabilities of the attacker. These values (e.g., 0 or 1) may indicate which capabilities are needed to exploit the determined vulnerability. Alternatively or additionally, at least one vulnerability profile 240 may also be stored in a database.

According to another exemplary aspect of the invention, at least one product profile 230 may be set up that is created in the same manner as the vulnerability profile 240 (digitizing a specification or file, such as a text-based list with key-value pairs) and using the same taxonomies as the vulnerability profile 240, if necessary. Here, the product profile 230 may define the capabilities of a potential attacker, particularly the likelihood of an attack, when the potential attacker attacks the product 30. In other words, the product profile 230 may define what an attacker can do if the attacker is able to "break into" the product 30 (represented by the above-described taxonomies).

An example of the name of such a product profile 230 may be

"Linux-based embedded device" or

"Linux-based lawnmowers" and the like.

The capabilities of the attacker in the product profile 230 may be:

"local login: 1",

"Login infrastructure X:0",

"Access wireless network interface: 0 "and the like,

This means that local login is possible, but that infrastructure X cannot be logged in, and that the wireless network interface cannot be accessed (e.g. because the device does not have a WiFi adapter).

By providing vulnerability profiles 240 and 230 and determining and exporting relevant vulnerabilities, the mechanisms proposed according to implementation variants of the present invention illustratively work as follows:

1. an automated system (e.g., CI/CD pipeline or cron job) queries a database (e.g., NVD) for a particular product 30, and in particular a determined SBOM.

2. The query provides information regarding the existence of determined vulnerabilities for a particular product 30 (particularly a given SBOM), as well as a corresponding vulnerability profile 240 for each vulnerability.

3. A product profile 230 of the particular product 30 to be inspected is read in.

4. Next, for each entry in the list of known vulnerabilities returned for that particular product 30 or that SBOM, it is checked whether the vulnerability profile 240 is consistent with the product profile 230. In other words, it is checked whether the attacker profile of the particular product 30 makes the vulnerability available in practice. For this check, a comparison may be made as to whether the required attacker capabilities, and in particular the attack possibilities, set in the vulnerability profile 240 are also set in the product profile 230.

5. In case of agreement, the vulnerability involved may be added to the list of actual relevant vulnerabilities for that particular product 30. Otherwise the vulnerability may be ignored. Alternatively or additionally, this information may also be stored in an additional long-term database that may be used for all future checks to more quickly exclude all vulnerabilities that have been proven to be irrelevant to the particular product 30 in previous runs.

6. Finally, an output (e.g., in the form of a document, a website, a ticket listing in a problem tracking system (e.g., jira), a Github topic listing, etc.) may be created that contains a list of vulnerabilities associated with the particular product 30.

The overall mechanism described in steps 1 to 6 may here be performed continuously, for example as a cloud service running continuously in the background. Here, the check may be automatically triggered in the background (i.e., without having to manually initiate the check) each time a new vulnerability is reported to a database such as an NVD. In addition, steps 1 to 6 may be performed for each product 30 to be inspected.

To create a taxonomy, there may be a limited number of elements that such taxonomies should include. So that common operating system resources (e.g., files, folders, network ports, processes, etc.) can be used as elements of the taxonomies.

Embodiments of the present invention may have the following advantages: so that it is possible to check whether a given vulnerability is actually related to the product 30 involved and that verification can be performed in an automatic manner if necessary instead of by manual checking.

The above explanation of embodiments describes the invention only in the context of examples. Of course, the individual features of the embodiments can be combined with one another freely as long as they are technically reasonable without departing from the scope of the invention.

Claims (10)

1. A method (100) for inspecting a product (30), wherein the product (30) has a plurality of software components (200), comprising the steps of:

Determining (101) at least one vulnerability profile (240) based on a vulnerability specification (220) and a product specification (210), wherein the product specification (210) specifies a software component (200) of the product (30) and the vulnerability specification (220) specifies at least one vulnerability of the software component (200), wherein the respective vulnerability profile (240) specifies at least one attack possibility in accordance with the at least one vulnerability,

Determining (102) a product profile (230) of the product (30), the product profile specifying at least one attack possibility in accordance with the product (30),

Determining (103) at least one relevant vulnerability based on a comparison of the respective vulnerability profile (240) with the determined product profile (230), wherein the at least one relevant vulnerability is related to the information security of the product (30),

-Outputting (104) the at least one relevant vulnerability.

2. The method (100) of claim 1,

It is characterized in that the method comprises the steps of,

Determining (101) at least one vulnerability profile (240) comprises the steps of:

Comparing, based on the vulnerability specification (220) and the product specification (210), to determine vulnerable software components (200) of the product (30), the vulnerability specification preferably being in the form of a database of vulnerabilities with respect to various software components (200), the product specification preferably being in the form of a list of software components (200) of a specific product (30) and/or in the form of SBOM, wherein preferably the vulnerability specification (220) is product independent and the product specification (210) is product dependent,

Wherein the determination (103) of at least one relevant vulnerability is performed to determine those of the vulnerable software components (200) that can be exploited for the at least one attack possibility according to the at least one vulnerability in the specific product (30).

3. The method (100) according to any one of the preceding claims,

It is characterized in that the method comprises the steps of,

Determining (101) at least one vulnerability profile (240) comprises the steps of:

-checking whether the software components (200) specified by the product specification (210) agree with the software components (200) specified in the vulnerability specification (220) to determine those vulnerabilities assigned to the agreed software components (200) according to the vulnerability specification (220), wherein preferably a vulnerability profile (240) assigned to the determined vulnerabilities is determined to query the product (30) for the presence and/or number of vulnerabilities.

4. The method (100) according to any one of the preceding claims,

It is characterized in that the method comprises the steps of,

The product profile (230) specifies the at least one attack possibility and preferably a plurality of attack possibilities from the product (30) based on a software structure and/or a hardware structure of the product (30), wherein preferably as the determined at least one vulnerability profile (220) a plurality of vulnerability profiles (240) are determined for a plurality of vulnerabilities specifying a plurality of attack possibilities from vulnerabilities depending on the software component (200) of the product (30), wherein the number of specified attack possibilities is greater than the number of attack possibilities from the product (30).

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

It is characterized in that the method comprises the steps of,

In comparing the respective vulnerability profile (240) with the determined product profile (230), it is checked whether at least one attack possibility according to the at least one vulnerability corresponds to at least one attack possibility according to the product (30), preferably whether the respective attack possibility specified by the vulnerability profile (240) is also present in the product profile (230).

6. The method (100) according to any one of the preceding claims,

It is characterized in that the method comprises the steps of,

By comparing the respective vulnerability profile (240) with the determined product profile (230), it is checked whether the respective vulnerability of the software component (200) for the product (30) is suitable to be exploited for attacking the product (30).

7. The method (100) according to any one of the preceding claims,

It is characterized in that the method comprises the steps of,

The product profile (230) and the corresponding vulnerability profile (240) have a common taxonomy and are preferably designed as lists and/or files, respectively.

8. The method (100) according to any one of the preceding claims,

It is characterized in that the method comprises the steps of,

The product (30) is intended for controlling a machine (40), preferably a vehicle (40), and/or a robot (40), wherein the steps of the method (100) are automatically repeated, preferably by a cloud service, in particular for monitoring the information security of the product (30) during operation of the machine (40).

9. A computer program (20) comprising instructions which, when the computer program (20) is executed by a computer (10), cause the computer (10) to perform the method (100) according to any one of the preceding claims.

10. A device (10) for data processing, the device being arranged to perform the method (100) according to any one of claims 1 to 8.