CN117235739A

CN117235739A - Software security detection method, device, equipment and storage medium

Info

Publication number: CN117235739A
Application number: CN202311426430.5A
Authority: CN
Inventors: 尚亚龙
Original assignee: China Construction Bank Corp; CCB Finetech Co Ltd
Current assignee: China Construction Bank Corp; CCB Finetech Co Ltd
Priority date: 2023-10-30
Filing date: 2023-10-30
Publication date: 2023-12-15

Abstract

The application provides a software security detection method, device, equipment and storage medium. Relates to the technical field of big data intelligent analysis. The method comprises the following steps: determining at least one open source component present in the target software; acquiring a plurality of component characteristic information of each open source component; determining at least one first open source component in the at least one open source component according to the component characteristic information of each open source component, wherein the risk level of the first open source component is greater than or equal to a preset level; and performing pre-filtering treatment on the first open source assembly, determining a target open source assembly from the first open source assembly, performing vulnerability scanning treatment on the target open source assembly to obtain a vulnerability scanning result, and performing security treatment on the target open source assembly according to the vulnerability scanning result. According to the scheme, the pre-filtering is carried out before the vulnerability scanning treatment is carried out on the open source components through the risk level of the open source components, so that the number of the open source components for vulnerability scanning is reduced, and the vulnerability scanning efficiency is improved.

Description

Software security detection method, device, equipment and storage medium

Technical Field

The present application relates to the field of intelligent analysis technologies for big data, and in particular, to a method, an apparatus, a device, and a storage medium for detecting software security.

Background

In the technical field of big data intelligent analysis, the development efficiency can be improved by performing software development on the basis of the existing open source component, wherein the open source component comprises a framework, an operating environment or a development tool and the like for software development.

The use of the open source component can raise the software development efficiency and simultaneously face the security problem, and specifically, a vulnerability may exist in the open source component, and the vulnerability may cause the risk of developing software based on the open source component.

Based on this, the developer needs to perform necessary vulnerability scanning on the open source component before using the open source component, identify vulnerabilities therefrom and process them. If the scale of software development is large, the number of used open source components is obviously increased, which causes the problem of long time consumption of vulnerability scanning, and further causes low efficiency of software development.

Disclosure of Invention

The application provides a method, a device, equipment and a storage medium for detecting software security, which are used for improving the efficiency of vulnerability scanning.

In a first aspect, the present application provides a method for detecting security of software, including: determining at least one open source component present in the target software; acquiring a plurality of component characteristic information of each open source component, wherein the component characteristic information is corresponding to the component characteristic types; determining at least one first open source component in the at least one open source component according to the component characteristic information of each open source component, wherein the risk level of the first open source component is greater than or equal to a preset level; and performing pre-filtering treatment on the first open source assembly, determining a target open source assembly from the first open source assembly, performing vulnerability scanning treatment on the target open source assembly to obtain a vulnerability scanning result, and performing security treatment on the target open source assembly according to the vulnerability scanning result.

In one possible design, determining at least one first open source component among the at least one open source component according to the plurality of component characteristic information of each open source component includes: determining a ranking order between the plurality of component feature information; according to the sorting order, coding the feature information of the components of each open source component to obtain component code vectors of each open source component; the at least one first open source component is determined from the at least one open source component based on the component code vector of each open source component.

In one possible design, for any one of the open source components; according to the sorting order, performing coding processing on the feature information of the components of the open source component to obtain component code vectors of the open source component, including: acquiring a preset corresponding relation corresponding to each component feature type, wherein the preset corresponding relation comprises a plurality of preset component feature information corresponding to the component feature type and feature codes corresponding to each preset component feature information; for any component characteristic information of the open source component, determining a corresponding preset corresponding relation according to the component characteristic type of the component characteristic information, and determining a target characteristic code corresponding to the component characteristic information according to the component characteristic information and the corresponding preset corresponding relation; and combining the target feature codes corresponding to the component feature information according to the arrangement sequence to obtain the component code vector of the open source component.

In one possible design, determining the at least one first open source component in the at least one open source component based on the component code vector of each open source component includes: acquiring a first white list, wherein the first white list comprises a plurality of code vectors, the risk level of an open source component corresponding to the code vectors is smaller than the preset level, and the first white list is obtained according to historical software detection; and for any one open source component, if the first white list does not comprise the component code vector of the open source component, determining the open source component as the first open source component.

In one possible design, the pre-filtering the first open source component to determine a target open source component therefrom includes: judging whether the first open source assembly is a slow release assembly or not according to any one of the first open source assemblies; if not, determining that the first open source component is the target open source component.

In one possible design, determining whether the first open source component is a sustained release component includes: acquiring component configuration information of the first open source component; acquiring a plurality of component parameters of a preset type from the component configuration information; performing splicing processing on the plurality of component parameters to obtain first component identification information of the first open source component; judging whether the first open source component is the slow release component according to the first component identification information, wherein the slow release component is a component capable of executing slow release processing.

In one possible design, determining whether the first open source component is the slow release component according to the first component identification information includes: acquiring a second white list, wherein the second white list comprises a plurality of component identification information; if the second white list comprises the first component identification information, determining that the first open source component is the slow release component; and if the second white list does not comprise the first component identification information, determining that the first open source component is not the slow release component.

In one possible design, the method further comprises: if the first open source component is the slow release component, acquiring first component identification information of the first open source component; according to the first component identification information, slow release measures are obtained from a preset database, and the slow release measures comprise at least one of the following: configuring an updating measure or an access right setting measure; and carrying out slow release treatment on the first open source assembly according to the slow release measure.

In one possible design, the slow-release measure includes the configuration update measure, which includes a configuration update file; according to the slow release measure, the first open source assembly is subjected to slow release treatment, which comprises the following steps: determining configuration parameters to be updated in the first open source component according to the configuration update file; determining a configuration parameter value corresponding to each configuration parameter according to the configuration update file; acquiring an initial configuration file of the first open source component; and updating the parameter values of the configuration parameters in the initial configuration file to corresponding configuration parameter values so as to realize configuration updating processing of the first open source component.

In one possible design, the slow release measure includes the access right setting measure, and the access right setting measure includes an access right update file; according to the slow release measure, the first open source assembly is subjected to slow release treatment, which comprises the following steps: determining authority parameters to be updated in the first open source component according to the access authority update file; determining a right parameter value corresponding to each right parameter according to the access right update file; acquiring an initial authority file of the first open source component; and updating the parameter values of the authority parameters in the initial authority file to corresponding authority parameter values so as to realize configuration updating processing of the first open source component.

In one possible design, the security processing for the target open source component according to the vulnerability scanning result includes: determining a safety processing mode corresponding to the target open source assembly, wherein the safety processing mode comprises an upgrading mode, a deleting mode and a slow-release processing mode; and carrying out security processing on the target open source component according to the security processing mode.

In one possible design, the safe treatment mode is the slow release treatment mode, and the method further includes: adding the component identification information of the target open source component to a second white list; and determining a slow release measure corresponding to the slow release processing mode, and correspondingly storing the component identification information of the target open source component and the slow release measure into a preset database.

In a second aspect, the present application provides a security detection device for software, comprising: a determining module for determining at least one open source component present in the target software; the device comprises an acquisition module, a control module and a control module, wherein the acquisition module is used for acquiring a plurality of component characteristic information of each open source component, wherein the component characteristic information is corresponding to a plurality of component characteristic types; the screening module is used for determining at least one first open source component in the at least one open source component according to the component characteristic information of each open source component, and the risk level of the first open source component is greater than or equal to a preset level; the judging module is used for carrying out pre-filtering treatment on the first open source assembly, determining a target open source assembly from the first open source assembly, carrying out vulnerability scanning treatment on the target open source assembly to obtain a vulnerability scanning result, and carrying out security treatment on the target open source assembly according to the vulnerability scanning result.

In one possible design, the filtering module is specifically configured to determine a ranking order among the plurality of component feature information; the screening module is specifically configured to perform coding processing on the feature information of multiple components of each open source component according to the ordering order, so as to obtain component code vectors of each open source component; the screening module is specifically further configured to determine the at least one first open source component in the at least one open source component according to a component code vector of each open source component.

In one possible design, for any one of the open source components; the screening module is specifically configured to obtain a preset corresponding relationship corresponding to each component feature type, where the preset corresponding relationship includes a plurality of preset component feature information corresponding to the component feature type and feature codes corresponding to each preset component feature information; the screening module is specifically configured to determine, for any component feature information of the open source component, a corresponding preset corresponding relationship according to a component feature type of the component feature information, and determine, according to the component feature information and the corresponding preset corresponding relationship, a target feature code corresponding to the component feature information; and the screening module is specifically configured to perform combination processing on the target feature codes corresponding to the feature information of the multiple components according to the arrangement sequence, so as to obtain a component code vector of the open source component.

In one possible design, the screening module is specifically configured to obtain a first white list, where the first white list includes a plurality of code vectors, a risk level of an open source component corresponding to the code vectors is smaller than the preset level, and the first white list is determined according to historical software detection; the screening module is specifically further configured to determine, for any one open source component, the open source component as a first open source component if the first whitelist does not include a component code vector of the open source component.

In one possible design, the apparatus further comprises: the matching module is used for judging whether the first open source assembly is a slow release assembly or not according to any one of the first open source assemblies; and the matching module is further configured to determine that the first open source component is the target open source component if not.

In one possible design, the apparatus further comprises: the matching module is used for acquiring the component configuration information of the first open source component; the matching module is further used for acquiring a plurality of component parameters of a preset type from the component configuration information; the matching module is further used for performing splicing processing on the plurality of component parameters to obtain first component identification information of the first open source component; the matching module is further configured to determine, according to the first component identification information, whether the first open source component is the slow release component, where the slow release component is a component capable of performing the slow release processing.

In one possible design, the matching module is specifically configured to obtain a second white list, where the second white list includes a plurality of component identification information; the matching module is specifically further configured to determine that the first open source component is the slow release component if the second whitelist includes the first component identification information; the matching module is specifically further configured to determine that the first open source component is not the slow release component if the second whitelist does not include the first component identification information.

In one possible design, the apparatus further comprises: the first execution module is used for acquiring first component identification information of the first open source component if the first open source component is the slow release component; the first execution module is further configured to obtain a slow release measure from a preset database according to the first component identification information, where the slow release measure includes at least one of the following: configuring an updating measure or an access right setting measure; the first execution module is further used for carrying out slow release treatment on the first open source component according to the slow release measure.

In one possible design, the slow-release measure includes the configuration update measure, which includes a configuration update file; the first execution module is specifically configured to determine a configuration parameter to be updated in the first open source component according to the configuration update file; the first execution module is specifically configured to determine a configuration parameter value corresponding to each configuration parameter according to the configuration update file; the first execution module is specifically configured to obtain an initial configuration file of the first open source component; the first execution module is specifically further configured to update a parameter value of the configuration parameter in the initial configuration file to a corresponding configuration parameter value, so as to implement configuration update processing on the first open source component.

In one possible design, the slow release measure includes the access right setting measure, and the access right setting measure includes an access right update file; the first execution module is specifically configured to determine an authority parameter to be updated in the first open source component according to the access authority update file; the first execution module is specifically configured to determine a permission parameter value corresponding to each permission parameter according to the access permission update file; the first execution module is specifically configured to obtain an initial rights file of the first open source component; the first execution module is specifically further configured to update a parameter value of the permission parameter in the initial permission file to a corresponding permission parameter value, so as to implement configuration update processing on the first open source component.

In one possible design, the apparatus further comprises: the second execution module is used for determining a safety processing mode corresponding to the target open-source component, wherein the safety processing mode comprises an upgrading mode, a deleting mode and a slow-release processing mode; the second execution module is further configured to perform security processing on the target open source component according to the security processing manner.

In one possible design, the apparatus further comprises: the updating module is used for adding the component identification information of the target open source component to a second white list; and the updating module is also used for determining slow release measures corresponding to the slow release processing mode and correspondingly storing the component identification information of the target open source component and the slow release measures into a preset database.

In a third aspect, an embodiment of the present application provides an electronic device, including: at least one processor and memory; the memory stores computer-executable instructions; the at least one processor executes computer-executable instructions stored in the memory, causing the at least one processor to perform the software security detection method as described above in the first aspect and the various possible designs of the first aspect.

In a fourth aspect, embodiments of the present application provide a computer readable storage medium having stored therein computer executable instructions which, when executed by a processor, implement a method for detecting security of software as described in the first aspect and various possible designs of the first aspect.

In a fifth aspect, embodiments of the present application provide a computer program product comprising a computer program which, when executed by a processor, implements the security detection method of software as described in the first aspect and the various possible designs of the first aspect.

The application provides a method, a device, equipment and a storage medium for detecting the safety of software, which are used for determining at least one open source component existing in target software; acquiring a plurality of component characteristic information of each open source component, wherein the component characteristic information is corresponding to the component characteristic types; determining at least one first open source component in the at least one open source component according to the component characteristic information of each open source component, wherein the risk level of the first open source component is greater than or equal to a preset level; and performing pre-filtering treatment on the first open source assembly, determining a target open source assembly from the first open source assembly, performing vulnerability scanning treatment on the target open source assembly to obtain a vulnerability scanning result, and performing security treatment on the target open source assembly according to the vulnerability scanning result. According to the scheme, the pre-filtering is carried out before the vulnerability scanning treatment is carried out on the open source components through the risk level of the open source components, so that the number of the open source components for vulnerability scanning is reduced, and the vulnerability scanning efficiency is improved.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application.

Fig. 1 is a schematic diagram of an application scenario of a software security detection method according to an embodiment of the present application;

fig. 2 is a flow chart of a method for detecting security of software according to an embodiment of the present application;

FIG. 3 is a flow chart of a method for detecting security of software according to an embodiment of the present application;

FIG. 4 is a schematic diagram of determining first component identification information according to an embodiment of the present application;

FIG. 5 is a schematic diagram of pre-filtration provided in an embodiment of the present application;

FIG. 6 is a flowchart of a method for detecting security of software according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a security detection device for software according to an embodiment of the present application;

FIG. 8 is a schematic structural diagram of a software security detection device according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Specific embodiments of the present application have been shown by way of the above drawings and will be described in more detail below. The drawings and the written description are not intended to limit the scope of the inventive concepts in any way, but rather to illustrate the inventive concepts to those skilled in the art by reference to the specific embodiments.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the application. Rather, they are merely examples of apparatus and methods consistent with aspects of the application as detailed in the accompanying claims.

In the technical scheme of the application, the related processes of collecting, storing, using, processing, transmitting, providing, disclosing and the like of the information such as financial data or user data are in accordance with the regulations of related laws and regulations, and the public welfare is not violated. The user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application are information and data authorized by the user or sufficiently authorized by each party, and the collection, use and processing of related data is required to comply with related laws and regulations and standards, and is provided with corresponding operation entries for the user to select authorization or rejection.

Fig. 1 is an application scenario diagram of security detection of prior art software. As shown in fig. 1, performing vulnerability scanning on a plurality of open source components with unknown security, determining the open source components with vulnerabilities and the secure open source components without vulnerabilities, performing security processing on the open source components with vulnerabilities, and performing software development through the secure open source components.

In the prior art, if the scale of software development is large, a large number of open source components with unknown security exist in the same period, and the plurality of open source components need to be queued to sequentially perform vulnerability scanning, so that vulnerability scanning efficiency is affected.

Aiming at the technical problems, the application provides the following technical conception: and pre-filtering is performed before vulnerability scanning is performed, and safe open source components are eliminated, so that the number of open source components for vulnerability scanning is reduced, and the vulnerability scanning efficiency is improved.

The following describes the technical scheme of the present application and how the technical scheme of the present application solves the above technical problems in detail with specific embodiments. The following embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.

Fig. 2 is a flow chart of a software security detection method according to an embodiment of the present application, where the method includes the following steps:

s201, determining at least one open source component existing in target software.

As an example, the execution subject of this embodiment may be a security detection device of software, which is variously implemented. For example, the program may be software, or a medium storing a related computer program, such as a usb disk; alternatively, the apparatus may be a physical device, such as a chip, a smart terminal, a computer, a server, etc., in which the relevant computer program is integrated or installed.

Wherein the target software is developed based on an open source component.

Optionally, an open source component required for development is determined before software development, and vulnerability scanning is performed on the open source component.

And optionally, performing vulnerability scanning on the developed open source components, determining components with vulnerabilities and performing security processing.

S202, acquiring a plurality of component characteristic information of each open source component, wherein the component characteristic information is corresponding to the component characteristic types;

optionally, component feature types include, but are not limited to: at least one of an organization identification, item representation, component version information, or item source, etc.

Still alternatively, component feature information is obtained from package management tools that store open source components, as well as from standard programming libraries.

S203, determining at least one first open source component in the at least one open source component according to the component characteristic information of each open source component, wherein the risk level of the first open source component is greater than or equal to a preset level.

For example, a risk level is determined for each of the open source components, the risk level evaluating the risk level of that open source component. If the risk level is smaller than the preset level, the corresponding open source component is considered to be free of risk or the use of the software is not affected by the risk, and the subsequent processing is not executed.

It will be appreciated that by risk level filtering, the number of open source components performing subsequent processing is reduced.

S204, pre-filtering the first open source assembly, determining a target open source assembly from the first open source assembly, performing vulnerability scanning on the target open source assembly to obtain a vulnerability scanning result, and performing security processing on the target open source assembly according to the vulnerability scanning result.

A possible implementation manner, performing a pre-filtering process on the first open source component, and determining a target open source component from the pre-filtered first open source component, including: judging whether the first open source assembly is a slow release assembly or not according to any one of the first open source assemblies; if not, determining that the first open source component is the target open source component.

The target open source component is a non-slow release component, and the slow release component is an open source component with holes and without affecting the use of software after slow release treatment of developers.

For example, an open source component with a vulnerability can be used for software development after slow release processing.

It will be appreciated that by slow release processing, the number of open source components performing vulnerability scanning may be further reduced.

For example, the slow release process is a known process, and is determined based on a history of processes. The security processing is a processing mode corresponding to the loopholes, which is determined by performing targeted analysis according to the loophole scanning result.

In such a viable implementation, the processing efficiency of the security process is lower than that of the slow release process, by which the overall efficiency of software development can be improved.

The method for detecting the safety of the software provided by the embodiment of the application determines at least one open source component existing in the target software; acquiring a plurality of component characteristic information of each open source component, wherein the component characteristic information is corresponding to the component characteristic types; determining at least one first open source component in the at least one open source component according to the component characteristic information of each open source component, wherein the risk level of the first open source component is greater than or equal to a preset level; and performing pre-filtering treatment on the first open source assembly, determining a target open source assembly from the first open source assembly, performing vulnerability scanning treatment on the target open source assembly to obtain a vulnerability scanning result, and performing security treatment on the target open source assembly according to the vulnerability scanning result. According to the scheme, the pre-filtering is carried out before the vulnerability scanning treatment is carried out on the open source components through the risk level of the open source components, so that the number of the open source components for vulnerability scanning is reduced, and the vulnerability scanning efficiency is improved.

On the basis of any of the above embodiments, a detailed process of security detection of software will be described below with reference to fig. 3.

Fig. 3 is a flow chart of a software security detection method according to an embodiment of the present application. As shown in fig. 3, the method includes:

s301, determining at least one open source component existing in target software.

It should be noted that, the execution process of S301 is referred to S201, and will not be described herein.

S302, acquiring a plurality of component characteristic information of each open source component, wherein the component characteristic information is corresponding to the component characteristic types.

It should be noted that, the execution process of S302 is referred to S202, and will not be described herein.

S303, acquiring a first white list, wherein the first white list comprises a plurality of code vectors, the risk level of an open source component corresponding to the code vectors is smaller than the preset level, and the first white list is obtained through detection and determination according to historical software.

In combination with the scenario example, the open source component corresponding to the code vector in the first whitelist is a verified security component.

A possible implementation manner, determining a first open source component, includes: determining a ranking order between the plurality of component feature information; according to the sorting order, coding the feature information of the components of each open source component to obtain component code vectors of each open source component; the at least one first open source component is determined from the at least one open source component based on the component code vector of each open source component.

For example, the feature information of the plurality of open source components includes: organization name 1, organization name 2, version information 1, or version information 2, feature information is converted into a code, organization name 1 is converted into 0001, organization name 2 is converted into 0002, version information 1 is converted into 000A, and version information 2 is converted into 000B.

Specifically, in one possible implementation manner, according to the sorting order, the coding processing is performed on the feature information of the components of the open source component to obtain a component code vector of the open source component, where the coding processing includes: acquiring a preset corresponding relation corresponding to each component feature type, wherein the preset corresponding relation comprises a plurality of preset component feature information corresponding to the component feature type and feature codes corresponding to each preset component feature information; for any component characteristic information of the open source component, determining a corresponding preset corresponding relation according to the component characteristic type of the component characteristic information, and determining a target characteristic code corresponding to the component characteristic information according to the component characteristic information and the corresponding preset corresponding relation; and combining the target feature codes corresponding to the component feature information according to the arrangement sequence to obtain the component code vector of the open source component.

For example, a corresponding preset corresponding relation is determined according to the component feature type, the organization name type corresponds to the preset corresponding relation 1, the version information type corresponds to the preset corresponding relation 2, and the feature code is determined according to the corresponding preset corresponding relation.

Optionally, the arrangement order is preset.

For example, if the arrangement order is that the organization name is before, the version information is after, the organization name 1 of any open source component is converted to 0001, the version information 1 is converted to 000A, and the feature codes are combined to obtain the component code vector of 0001000A.

In such a possible implementation, the efficiency of whitelist matching may be improved by translating the code vector.

S304, for any open source component, if the first white list does not include the component code vector of the open source component, determining the open source component as a first open source component.

Optionally, the first whitelist is gradually expanding.

In combination with the scenario example, the first open source component does not exist in the first whitelist, and the first open source component is a component that is not verified. As the first whitelist expands, the number of first open source components gradually decreases.

It can be appreciated that the number of the first open source components is less than or equal to that of the at least one open source component, and the open source components can be effectively filtered through the first white list, so that the efficiency of vulnerability scanning is improved.

A possible implementation manner, determining whether the first open source component is a slow release component, includes: acquiring component configuration information of the first open source component; acquiring a plurality of component parameters of a preset type from the component configuration information; performing splicing processing on the plurality of component parameters to obtain first component identification information of the first open source component; judging whether the first open source component is the slow release component according to the first component identification information, wherein the slow release component is a component capable of executing slow release processing.

Next, determination of the first component identification information will be described with reference to fig. 4.

Fig. 4 is a schematic diagram of determining first component identification information according to an embodiment of the present application. As shown in fig. 4, for any one first open source component, component configuration information of the first open source component is determined, different types of component parameters are obtained from the component configuration information, and the component parameters are combined to obtain first component identification information.

In the feasible implementation mode, the first component identification information can be determined by combining the multiple component parameters through the splicing process, so that the random error is reduced, and the accuracy of judging the slow-release component is improved.

S305, acquiring a second white list, wherein the second white list comprises a plurality of component identification information.

Optionally, the component identification information includes, but is not limited to: the binding configures at least one of a user name, a physical subsystem, or an engineering, etc.

Still alternatively, the component identification information is unique information.

S306, if the second white list includes the first component identification information, determining that the first open source component is the slow release component.

Optionally, the second whitelist is progressively expanded.

By combining the scene example, the identification information verified as the slow-release component is stored in the second white list, and whether the first open source component is the slow-release component can be rapidly determined by comparing the identification information of the first component with the identification information stored in the second white list.

Next, prefiltering will be described with reference to fig. 5.

Fig. 5 is a schematic diagram of pre-filtering according to an embodiment of the present application. As shown in fig. 5, a plurality of open source components are determined, a code vector of each open source component is determined, for a code vector of any one open source component, if the code vector exists in the first white list, the open source component is determined to be a security component, and if the code vector does not exist in the first white list, whether the code vector exists in the second white list is determined. And if the code vector exists in the second white list, determining that the open source component is a safety component, and if the code vector does not exist in the second white list, performing vulnerability scanning on the open source component.

S307, according to the first component identification information, a slow release measure is obtained from a preset database, wherein the slow release measure comprises at least one of the following steps: an update measure or an access right setting measure is configured.

Optionally, the preset database corresponds to the second white list, and slow release measures corresponding to the component identification information in the second white list are stored in the preset database.

For a scene example, if the verification is that the open source component is the slow release component, determining a corresponding slow release measure, storing component identification information of the open source component in a second white list, and storing the component identification information of the open source component and the corresponding slow release measure in a preset database.

And S308, performing slow release treatment on the first open source assembly according to the slow release measure.

A possible implementation manner, the slow release measure comprises the configuration updating measure, and the configuration updating measure comprises a configuration updating file; according to the slow release measure, the first open source assembly is subjected to slow release treatment, which comprises the following steps: determining configuration parameters to be updated in the first open source component according to the configuration update file; determining a configuration parameter value corresponding to each configuration parameter according to the configuration update file; acquiring an initial configuration file of the first open source component; and updating the parameter values of the configuration parameters in the initial configuration file to corresponding configuration parameter values so as to realize configuration updating processing of the first open source component.

In the related technology, the vulnerability is processed by adopting a mode of updating a version or deleting an open source component, the influence of the vulnerability can be effectively eliminated aiming at the serious vulnerability, and the development cost is increased aiming at the vulnerability with small influence degree.

In combination with a scenario example, for a configuration update measure, the vulnerability in the first open source component has a smaller influence on software, the vulnerability can be eliminated by updating the parameter value without affecting the function of the first open source component, the configuration update file stores the configuration parameter value, and the vulnerability can be eliminated by replacing the parameter value in the first open source component with the configuration parameter value.

In such a possible implementation, the time consumption of configuration update is low, and slow release processing can be quickly realized through configuration update.

In another possible implementation manner, the slow release measure includes the access right setting measure, and the access right setting measure includes an access right update file; according to the slow release measure, the first open source assembly is subjected to slow release treatment, which comprises the following steps: determining authority parameters to be updated in the first open source component according to the access authority update file; determining a right parameter value corresponding to each right parameter according to the access right update file; acquiring an initial authority file of the first open source component; and updating the parameter values of the authority parameters in the initial authority file to corresponding authority parameter values so as to realize configuration updating processing of the first open source component.

Optionally, the authority parameter value includes white list information.

In combination with a scene example, aiming at an access right setting measure, a first open source component has a vulnerability, the vulnerability cannot be influenced when an internal person normally uses the software, the software is only used by the internal person, and the scene can limit the persons allowed to access in white list information, so that the influence of the vulnerability on the software caused by the malignant operation of other persons is avoided.

In the feasible implementation mode, the time consumption of the access right setting measures is low, and the slow release processing can be quickly realized through the access right setting measures.

S309, if the second white list does not include the first component identification information, determining that the first open source component is not the slow release component.

It should be noted that, the execution process of S309 is referred to S306, and will not be described herein.

S310, determining a safety processing mode corresponding to the first open source component, wherein the safety processing mode comprises an upgrading mode, a deleting mode and a slow release processing mode.

In combination with a scene example, aiming at serious loopholes, an upgrading mode or a deleting mode is adopted as a security processing mode, and aiming at loopholes with small influence degree, a slow-release processing mode is adopted as a security processing mode.

S311, performing security processing on the target open source component according to the security processing mode.

In combination with a scene example, aiming at an upgrading mode, a developer updates a version of a first open source component on the basis of the first open source component, and the upgraded open source component eliminates the vulnerability by modifying the code related to the vulnerability. Aiming at the deleting mode, the corresponding vulnerability influence range is larger, if the vulnerability influence range cannot be solved by modifying codes, the first open source component needs to be deleted, and the existing other open source components are used for replacing or redeveloping the replaced open source components.

A possible implementation manner, the safe processing manner is the slow release processing manner, and the method further includes: adding component identification information of the first open source component to a second white list; and determining a slow release measure corresponding to the slow release processing mode, and correspondingly storing the component identification information of the first open source component and the slow release measure into a preset database.

For example, if the first open source component does not exist in the second white list and is determined to be in the slow release processing mode, the first open source component is a newly added open source component, and no record is made in the second white list.

In this possible implementation manner, the component identification information of the first open source component is added to the second white list, so as to expand the second white list, and the filtering efficiency can be improved when the pre-filtering of other open source components is performed subsequently.

On the basis of any of the above embodiments, a detailed process of security detection of software will be described below with reference to fig. 6.

Fig. 6 is a flow chart of a software security detection method according to an embodiment of the present application. As shown in fig. 6, the method includes:

s601, performing vulnerability scanning processing on the target open source component to obtain a vulnerability scanning result, wherein the vulnerability scanning result comprises a vulnerability component.

Optionally, vulnerability scanning processing is performed through a vulnerability database.

In combination with the scenario example, the vulnerability component is a component existing in the vulnerability database in the target open source component.

S602, obtaining vulnerability information of the vulnerability component.

Optionally, vulnerability information of the vulnerability component is obtained from a vulnerability database.

In combination with the scenario example, the vulnerability database includes vulnerability information of each vulnerability, and the vulnerability information includes explanation of the vulnerability.

S603, determining a security processing mode of the vulnerability component according to the vulnerability information.

By combining with a scene example, determining the specific type, severity, processing difficulty and other information of the loophole corresponding to the loophole component according to the loophole information, and determining the security processing mode of the loophole component according to the information so that the processed loophole component does not generate potential safety hazards.

Fig. 7 is a schematic structural diagram of a software security detection device according to an embodiment of the present application. As shown in fig. 7, the security detection means 70 of the software may include: a determining module 71, an acquiring module 72, a screening module 73 and a judging module 74,

the determining module 71 is configured to determine at least one open source component existing in the target software;

the acquiring module 72 is configured to acquire a plurality of component feature information of each open source component, where the plurality of component feature information is component feature information corresponding to a plurality of component feature types;

the screening module 73 is configured to determine at least one first open source component from the at least one open source component according to the component feature information of each open source component, where a risk level of the first open source component is greater than or equal to a preset level;

the judging module 74 is configured to judge, for any one of the first open source components, whether the first open source component is a slow release component.

Alternatively, the determining module 71 may perform S201 in the embodiment of fig. 2.

Alternatively, the acquisition module 72 may perform S202 in the embodiment of fig. 2.

Optionally, the screening module 73 may perform S203 in the embodiment of fig. 2.

Alternatively, the determination module 74 may execute S204 in the embodiment of fig. 2.

It should be noted that, the security detection device for software shown in the embodiment of the present application may execute the technical solution shown in the embodiment of the method, and its implementation principle and beneficial effects are similar, and will not be described herein again.

In one possible implementation, the screening module 73 is specifically configured to:

determining a ranking order between the plurality of component feature information;

according to the sorting order, coding the feature information of the components of each open source component to obtain component code vectors of each open source component;

the at least one first open source component is determined from the at least one open source component based on the component code vector of each open source component.

In one possible implementation, for any one of the open source components; the screening module 73 is specifically configured to:

acquiring a preset corresponding relation corresponding to each component feature type, wherein the preset corresponding relation comprises a plurality of preset component feature information corresponding to the component feature type and feature codes corresponding to each preset component feature information;

For any component characteristic information of the open source component, determining a corresponding preset corresponding relation according to the component characteristic type of the component characteristic information, and determining a target characteristic code corresponding to the component characteristic information according to the component characteristic information and the corresponding preset corresponding relation;

and combining the target feature codes corresponding to the component feature information according to the arrangement sequence to obtain the component code vector of the open source component.

acquiring a first white list, wherein the first white list comprises a plurality of code vectors, the risk level of an open source component corresponding to the code vectors is smaller than the preset level, and the first white list is obtained according to historical software detection;

and for any one open source component, if the first white list does not comprise the component code vector of the open source component, determining the open source component as the first open source component.

Fig. 8 is a schematic structural diagram of a software security detection device according to an embodiment of the present application. On the basis of the embodiment shown in fig. 7, as shown in fig. 8, the security detection device 80 of the software further includes: a matching module 75, a first execution module 76, a second execution module 77, and an updating module 78, wherein:

The matching module 75 is configured to:

judging whether the first open source assembly is a slow release assembly or not according to any one of the first open source assemblies;

if not, determining that the first open source component is the target open source component.

In a possible implementation manner, the matching module 75 is specifically configured to:

acquiring component configuration information of the first open source component;

acquiring a plurality of component parameters of a preset type from the component configuration information;

performing splicing processing on the plurality of component parameters to obtain first component identification information of the first open source component;

judging whether the first open source component is the slow release component according to the first component identification information, wherein the slow release component is a component capable of executing slow release processing.

acquiring a second white list, wherein the second white list comprises a plurality of component identification information;

if the second white list comprises the first component identification information, determining that the first open source component is the slow release component;

and if the second white list does not comprise the first component identification information, determining that the first open source component is not the slow release component.

The first execution module 76 is configured to:

if the first open source component is the slow release component, acquiring first component identification information of the first open source component;

according to the first component identification information, slow release measures are obtained from a preset database, and the slow release measures comprise at least one of the following: configuring an updating measure or an access right setting measure;

and carrying out slow release treatment on the first open source assembly according to the slow release measure.

In a possible implementation manner, the slow-release measure comprises the configuration updating measure, and the configuration updating measure comprises a configuration updating file; the first execution module 76 is specifically configured to:

determining configuration parameters to be updated in the first open source component according to the configuration update file;

determining a configuration parameter value corresponding to each configuration parameter according to the configuration update file;

acquiring an initial configuration file of the first open source component;

and updating the parameter values of the configuration parameters in the initial configuration file to corresponding configuration parameter values so as to realize configuration updating processing of the first open source component.

In a possible implementation manner, the slow release measure includes the access right setting measure, and the access right setting measure includes an access right update file; the first execution module 76 is specifically configured to:

Determining authority parameters to be updated in the first open source component according to the access authority update file;

determining a right parameter value corresponding to each right parameter according to the access right update file;

acquiring an initial authority file of the first open source component;

and updating the parameter values of the authority parameters in the initial authority file to corresponding authority parameter values so as to realize configuration updating processing of the first open source component.

The second execution module 77 is configured to:

determining a safety processing mode corresponding to the target open source assembly, wherein the safety processing mode comprises an upgrading mode, a deleting mode and a slow-release processing mode;

and carrying out security processing on the target open source component according to the security processing mode.

The update module 78 is configured to:

adding the component identification information of the target open source component to a second white list; the method comprises the steps of,

and determining a slow release measure corresponding to the slow release processing mode, and correspondingly storing the component identification information of the target open source component and the slow release measure into a preset database.

It should be noted that, it should be understood that the division of the modules of the above apparatus is merely a division of a logic function, and may be fully or partially integrated into a physical entity or may be physically separated. And these modules may all be implemented in software in the form of calls by the processing element; or can be realized in hardware; the method can also be realized in a form of calling software by a processing element, and the method can be realized in a form of hardware by a part of modules. The modules may be processing elements that are individually set up, may be implemented as integrated in a chip of the above-described apparatus, or may be stored in a memory of the above-described apparatus in the form of program codes, and the functions of the above-described modules may be called and executed by a processing element of the above-described apparatus. In addition, all or part of the modules can be integrated together or can be independently implemented. The processing element here may be an integrated circuit with signal processing capabilities. In implementation, each step of the above method or each module above may be implemented by an integrated logic circuit of hardware in a processor element or an instruction in a software form.

Fig. 9 is a schematic structural diagram of an electronic device according to an embodiment of the present application. As shown in fig. 9, the electronic device may include: a transceiver 91, a processor 92, a memory 93.

Processor 92 executes the computer-executable instructions stored in the memory, causing processor 92 to perform the aspects of the embodiments described above. The processor 92 may be a general purpose processor including a central processing unit CPU, a network processor (network processor, NP), etc.; but may also be a digital signal processor DSP, an application specific integrated circuit ASIC, a field programmable gate array FPGA or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component.

The memory 93 is coupled to the processor 92 via a system bus and communicates with each other, and the memory 93 is adapted to store computer program instructions.

The transceiver 91 may be used to obtain a task to be run and configuration information of the task to be run.

The system bus may be a peripheral component interconnect standard (peripheral component interconnect, PCI) bus or an extended industry standard architecture (extended industry standard architecture, EISA) bus, among others. The system bus may be classified into an address bus, a data bus, a control bus, and the like. For ease of illustration, the figures are shown with only one bold line, but not with only one bus or one type of bus. The transceiver is used to enable communication between the database access device and other computers (e.g., clients, read-write libraries, and read-only libraries). The memory may include random access memory (random access memory, RAM) and may also include non-volatile memory (non-volatile memory).

The electronic device provided by the embodiment of the application can be the terminal device of the embodiment.

The embodiment of the application also provides a chip for running the instruction, which is used for executing the technical scheme of the software security detection method in the embodiment.

The embodiment of the application also provides a computer readable storage medium, wherein the computer readable storage medium stores computer instructions, and when the computer instructions run on a computer, the computer is caused to execute the technical scheme of the safety detection method of the embodiment software.

The embodiment of the application also provides a computer program product, which comprises a computer program stored in a computer readable storage medium, wherein at least one processor can read the computer program from the computer readable storage medium, and the technical scheme of the software security detection method in the embodiment can be realized when the at least one processor executes the computer program.

In the several embodiments provided by the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described device embodiments are merely illustrative, e.g., the division of modules is merely a logical function division, and there may be additional divisions of actual implementation, e.g., multiple modules may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or modules, which may be in electrical, mechanical, or other forms.

The modules illustrated as separate components may or may not be physically separate, and components shown as modules may or may not be physical units, may be located in one place, or may be distributed over multiple network units. Some or all of the modules may be selected according to actual needs to implement the solution of this embodiment.

In addition, each functional module in the embodiments of the present application may be integrated in one processing unit, or each module may exist alone physically, or two or more modules may be integrated in one unit. The units formed by the modules can be realized in a form of hardware or a form of hardware and software functional units.

The integrated modules, which are implemented in the form of software functional modules, may be stored in a computer readable storage medium. The software functional modules described above are stored in a storage medium and include instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or processor to perform some of the steps of the methods of the various embodiments of the application.

It should be understood that the above processor may be a central processing unit (Central Processing Unit, abbreviated as CPU), but may also be other general purpose processors, digital signal processors (Digital Signal Processor, abbreviated as DSP), application specific integrated circuits (Application Specific Integrated Circuit, abbreviated as ASIC), etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the present application may be embodied directly in a hardware processor for execution, or in a combination of hardware and software modules in a processor for execution.

The memory may comprise a high-speed RAM memory, and may further comprise a non-volatile memory NVM, such as at least one magnetic disk memory, and may also be a U-disk, a removable hard disk, a read-only memory, a magnetic disk or optical disk, etc.

The bus may be an industry standard architecture (Industry Standard Architecture, ISA) bus, an external device interconnect (Peripheral Component Interconnect, PCI) bus, or an extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus, among others. The buses may be divided into address buses, data buses, control buses, etc. For ease of illustration, the buses in the drawings of the present application are not limited to only one bus or to one type of bus.

The storage medium may be implemented by any type or combination of volatile or nonvolatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.

An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application specific integrated circuit (Application Specific Integrated Circuits, ASIC for short). Of course, the processor and the storage medium may reside as discrete components in an electronic control unit or master control device.

Those of ordinary skill in the art will appreciate that: all or part of the steps for implementing the method embodiments described above may be performed by hardware associated with program instructions. The foregoing program may be stored in a computer readable storage medium. The program, when executed, performs steps including the method embodiments described above; and the aforementioned storage medium includes: various media that can store program code, such as ROM, RAM, magnetic or optical disks.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some or all of the technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the application.

Claims

1. A method for detecting security of software, comprising:

determining at least one open source component present in the target software;

acquiring a plurality of component characteristic information of each open source component, wherein the component characteristic information is corresponding to the component characteristic types;

determining at least one first open source component in the at least one open source component according to the component characteristic information of each open source component, wherein the risk level of the first open source component is greater than or equal to a preset level;

and performing pre-filtering treatment on the first open source assembly, determining a target open source assembly from the first open source assembly, performing vulnerability scanning treatment on the target open source assembly to obtain a vulnerability scanning result, and performing security treatment on the target open source assembly according to the vulnerability scanning result.

2. The method of claim 1, wherein determining at least one first open source component among the at least one open source component based on the plurality of component characteristic information for each open source component, comprises:

3. The method of claim 2, wherein for any one open source component; according to the sorting order, performing coding processing on the feature information of the components of the open source component to obtain component code vectors of the open source component, including:

4. A method according to claim 2 or 3, wherein determining the at least one first open source component among the at least one open source component based on the component code vector of each open source component comprises:

5. The method of any of claims 1-4, wherein pre-filtering the first open source component to determine a target open source component therefrom comprises:

6. The method of claim 5, wherein determining whether the first open source component is a sustained release component comprises:

7. The method of claim 6, wherein determining whether the first open source component is the slow release component based on the first component identification information comprises:

8. The method of claim 7, wherein the method further comprises:

9. The method of claim 8, wherein the slow-release measure comprises the configuration update measure, the configuration update measure comprising a configuration update file; according to the slow release measure, the first open source assembly is subjected to slow release treatment, which comprises the following steps:

acquiring an initial configuration file of the first open source component;

10. The method of claim 9, wherein the slow release measure comprises the access rights setting measure comprising an access rights update file; according to the slow release measure, the first open source assembly is subjected to slow release treatment, which comprises the following steps:

acquiring an initial authority file of the first open source component;

11. The method according to any of claims 1-10, wherein performing security processing on the target open source component according to the vulnerability scanning result comprises:

12. The method of claim 11, wherein the safe treatment regimen is the slow release treatment regimen, the method further comprising:

13. A security detection device for software, comprising:

a determining module for determining at least one open source component present in the target software;

the device comprises an acquisition module, a control module and a control module, wherein the acquisition module is used for acquiring a plurality of component characteristic information of each open source component, wherein the component characteristic information is corresponding to a plurality of component characteristic types;

the screening module is used for determining at least one first open source component in the at least one open source component according to the component characteristic information of each open source component, and the risk level of the first open source component is greater than or equal to a preset level;

the judging module is used for carrying out pre-filtering treatment on the first open source assembly, determining a target open source assembly from the first open source assembly, carrying out vulnerability scanning treatment on the target open source assembly to obtain a vulnerability scanning result, and carrying out security treatment on the target open source assembly according to the vulnerability scanning result.

14. The apparatus of claim 13, wherein the device comprises a plurality of sensors,

the screening module is specifically configured to determine a sorting order among the feature information of the plurality of components;

the screening module is specifically configured to perform coding processing on the feature information of multiple components of each open source component according to the ordering order, so as to obtain component code vectors of each open source component;

The screening module is specifically further configured to determine the at least one first open source component in the at least one open source component according to a component code vector of each open source component.

15. The apparatus of claim 14, wherein for any one open source component;

the screening module is specifically configured to obtain a preset corresponding relationship corresponding to each component feature type, where the preset corresponding relationship includes a plurality of preset component feature information corresponding to the component feature type and feature codes corresponding to each preset component feature information;

the screening module is specifically configured to determine, for any component feature information of the open source component, a corresponding preset corresponding relationship according to a component feature type of the component feature information, and determine, according to the component feature information and the corresponding preset corresponding relationship, a target feature code corresponding to the component feature information;

and the screening module is specifically configured to perform combination processing on the target feature codes corresponding to the feature information of the multiple components according to the arrangement sequence, so as to obtain a component code vector of the open source component.

16. The device according to claim 14 or 15, wherein,

The screening module is specifically configured to obtain a first white list, where the first white list includes a plurality of code vectors, a risk level of an open source component corresponding to the code vectors is smaller than the preset level, and the first white list is obtained according to detection of historical software;

the screening module is specifically further configured to determine, for any one open source component, the open source component as a first open source component if the first whitelist does not include a component code vector of the open source component.

17. The apparatus according to any one of claims 13-16, wherein the apparatus further comprises:

the matching module is used for judging whether the first open source assembly is a slow release assembly or not according to any one of the first open source assemblies;

and the matching module is further configured to determine that the first open source component is the target open source component if not.

18. The apparatus of claim 17, wherein the device comprises a plurality of sensors,

the matching module is specifically configured to obtain component configuration information of the first open source component;

the matching module is specifically configured to obtain a plurality of component parameters of a preset type from the component configuration information;

The matching module is specifically configured to perform splicing processing on the plurality of component parameters to obtain first component identification information of the first open source component;

the matching module is specifically configured to determine, according to the first component identification information, whether the first open source component is the slow release component, where the slow release component is a component capable of executing the slow release process.

19. The apparatus of claim 18, wherein the device comprises a plurality of sensors,

the matching module is specifically configured to obtain a second white list, where the second white list includes a plurality of component identification information;

the matching module is specifically further configured to determine that the first open source component is the slow release component if the second whitelist includes the first component identification information;

the matching module is specifically further configured to determine that the first open source component is not the slow release component if the second whitelist does not include the first component identification information.

20. The apparatus of claim 19, wherein the apparatus further comprises:

the first execution module is used for acquiring first component identification information of the first open source component if the first open source component is the slow release component;

The first execution module is further configured to obtain a slow release measure from a preset database according to the first component identification information, where the slow release measure includes at least one of the following: configuring an updating measure or an access right setting measure;

the first execution module is further used for carrying out slow release treatment on the first open source component according to the slow release measure.

21. The apparatus of claim 20, wherein the slow-release measure comprises the configuration update measure, the configuration update measure comprising a configuration update file;

the first execution module is specifically configured to determine a configuration parameter to be updated in the first open source component according to the configuration update file;

the first execution module is specifically configured to determine a configuration parameter value corresponding to each configuration parameter according to the configuration update file;

the first execution module is specifically configured to obtain an initial configuration file of the first open source component;

the first execution module is specifically further configured to update a parameter value of the configuration parameter in the initial configuration file to a corresponding configuration parameter value, so as to implement configuration update processing on the first open source component.

22. The apparatus of claim 21, wherein the slow release measure comprises the access rights setting measure comprising an access rights update file;

the first execution module is specifically configured to determine an authority parameter to be updated in the first open source component according to the access authority update file;

the first execution module is specifically configured to determine a permission parameter value corresponding to each permission parameter according to the access permission update file;

the first execution module is specifically configured to obtain an initial rights file of the first open source component;

the first execution module is specifically further configured to update a parameter value of the permission parameter in the initial permission file to a corresponding permission parameter value, so as to implement configuration update processing on the first open source component.

23. The apparatus according to any one of claims 13-22, wherein the apparatus further comprises:

the second execution module is used for determining a safety processing mode corresponding to the target open-source component, wherein the safety processing mode comprises an upgrading mode, a deleting mode and a slow-release processing mode;

the second execution module is further configured to perform security processing on the target open source component according to the security processing manner.

24. The apparatus of claim 23, wherein the apparatus further comprises:

the updating module is used for adding the component identification information of the target open source component to a second white list; the method comprises the steps of,

the updating module is further used for determining slow-release measures corresponding to the slow-release processing mode and storing the component identification information of the target open source component and the slow-release measures to a preset database correspondingly.

25. An electronic device, comprising: a processor, and a memory communicatively coupled to the processor;

the memory stores computer-executable instructions;

the processor executes computer-executable instructions stored in the memory to implement the method of any one of claims 1-12.

26. A computer readable storage medium having stored therein computer executable instructions which when executed by a processor are adapted to carry out the method of any one of claims 1-12.

27. A computer program product comprising a computer program which, when executed by a processor, implements the method of any of claims 1-12.