CN113778509A - Method for determining version of open source component, storage medium and electronic device - Google Patents
Method for determining version of open source component, storage medium and electronic device Download PDFInfo
- Publication number
- CN113778509A CN113778509A CN202110931931.3A CN202110931931A CN113778509A CN 113778509 A CN113778509 A CN 113778509A CN 202110931931 A CN202110931931 A CN 202110931931A CN 113778509 A CN113778509 A CN 113778509A
- Authority
- CN
- China
- Prior art keywords
- target
- risk information
- version
- vulnerability risk
- component
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 35
- 238000001514 detection method Methods 0.000 claims abstract description 29
- 238000011161 development Methods 0.000 claims abstract description 12
- 238000004590 computer program Methods 0.000 claims description 13
- 238000012795 verification Methods 0.000 claims description 11
- 238000012545 processing Methods 0.000 claims description 3
- 238000011156 evaluation Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000007723 transport mechanism Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/577—Assessing vulnerabilities and evaluating computer system security
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Stored Programmes (AREA)
Abstract
The embodiment of the application discloses a method for determining the version of an open source component, a storage medium and an electronic device. The method comprises the following steps: a01, selecting vulnerability risk information as target vulnerability risk information from the prestored vulnerability risk information in the open source component; a02, detecting whether target vulnerability risk information exists in a target component to obtain a detection result, wherein the target component is obtained based on the secondary development of a source code of an open source component; a03, determining an alternative version range corresponding to a detection result according to version information influenced by target vulnerability risk information in an open source component; a04, judging whether the total number of versions in the alternative version range is greater than 1 to obtain a judgment result; if the judgment result is larger than 1, continuing to execute the step A01; otherwise, go to step A05; and step A05, recording the version information in the alternative version range as the target version of the source code of the source component in the target component.
Description
Technical Field
Embodiments of the present invention relate to the field of information processing, and in particular, to a method, a storage medium, and an electronic device for determining a version of an open source component.
Background
Open source components are primarily developed by teams of programmers scattered around the world. By using the source code of the open source component, software developers can widely carry out secondary development to obtain the required target component. Due to the open source characteristic of the open source component, a safety risk exists in the operation process of the open source component, and the whole target component developed based on the open source component is directly influenced.
In order to ensure the operation security of the target component, a corresponding security patch needs to be acquired based on the open source component used by the target component, so as to complete the security maintenance of the target component. Because the secure completions of the open source components are divided based on the version information of the open source components, if the open source components used by the target components are determined, a problem to be solved is needed.
Disclosure of Invention
In order to solve any technical problem, embodiments of the present application provide a method, a storage medium, and an electronic device for determining a version of an open source component.
To achieve the purpose of the embodiments of the present application, an embodiment of the present application provides a method for determining a version of an open source component, including:
a01, selecting vulnerability risk information as target vulnerability risk information from the prestored vulnerability risk information in the open source component;
a02, detecting whether the target component has the target vulnerability risk information to obtain a detection result, wherein the target component is obtained based on the secondary development of the source code of the open source component;
step A03, determining an alternative version range corresponding to the detection result according to version information influenced by the target vulnerability risk information in the open source component;
step A04, judging whether the total number of versions in the alternative version range is greater than 1 to obtain a judgment result;
if the judgment result is greater than 1, continuing to execute the step A01; otherwise, go to step A05;
and A05, recording the version information in the alternative version range as the target version of the source code of the source component in the target component.
A storage medium having a computer program stored therein, wherein the computer program is arranged to perform the method as described above when executed.
An electronic device comprising a memory having a computer program stored therein and a processor arranged to execute the computer program to perform the method as described above.
One of the above technical solutions has the following advantages or beneficial effects:
selecting vulnerability risk information as target vulnerability risk information from prestored vulnerability risk information in an open source component, detecting whether the target component has the target vulnerability risk information to obtain a detection result, determining an alternative version range corresponding to the detection result according to version information influenced by the target vulnerability risk information in the open source component, and then judging whether the total number of versions in the alternative version range is greater than 1 to obtain a judgment result; if the judgment result is greater than 1, continuing to execute circularly; otherwise, recording the version information in the alternative version range as the target version of the source code of the source component in the target component, and achieving the purpose of determining the target version of the source code of the source component in the target component by means of vulnerability detection and with the help of the version range influenced by the vulnerability in the source component.
Additional features and advantages of the embodiments of the application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the embodiments of the application. The objectives and other advantages of the embodiments of the application may be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.
Drawings
The accompanying drawings are included to provide a further understanding of the embodiments of the present application and are incorporated in and constitute a part of this specification, illustrate embodiments of the present application and together with the examples of the embodiments of the present application do not constitute a limitation of the embodiments of the present application.
Fig. 1 is a flowchart of a method for determining a version of a switch component according to an embodiment of the present application;
fig. 2 is a schematic diagram of a version evaluation system for a database provided in an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application more apparent, the embodiments of the present application will be described in detail below with reference to the accompanying drawings. It should be noted that, in the embodiments of the present application, features in the embodiments and the examples may be arbitrarily combined with each other without conflict.
Fig. 1 is a flowchart of a method for determining a version of a switch component according to an embodiment of the present application. As shown in fig. 1, the method includes:
a01, selecting vulnerability risk information as target vulnerability risk information from the prestored vulnerability risk information in the open source component;
in an exemplary embodiment, the number of selected vulnerability risk information may be one or more. When the target vulnerability risk information is selected, the target vulnerability risk information can be selected according to the range influenced by the vulnerability risk information.
When at least two target vulnerability risk information are selected simultaneously, the repeatability between the version ranges influenced by the two selected vulnerability risk information can be determined, and vulnerability risk information with low repeatability is preferentially selected as the target vulnerability risk information.
A02, detecting whether the target component has the target vulnerability risk information to obtain a detection result, wherein the target component is obtained based on the secondary development of the source code of the open source component;
in an exemplary embodiment, the target vulnerability risk information may be obtained by obtaining POC (Proof of Concept) data of the target vulnerability risk information; and detecting the vulnerability of the target component by using the POC data.
When vulnerability detection is carried out on a target component, for each target vulnerability risk information, a source code and POC data of the starting source component are utilized to carry out verification operation on the target component; if the verification operation can determine the vulnerability identification information of the target vulnerability risk information, determining that the target vulnerability risk information exists in the target component; otherwise, determining that the target component does not have the target vulnerability risk information.
The vulnerability identification information may be CVE (Common Vulnerabilities and exposition).
By the adoption of the method, vulnerability detection can be conducted on the target component in the development stage.
Step A03, determining an alternative version range corresponding to the detection result according to version information influenced by the target vulnerability risk information in the open source component;
if the target component has certain target vulnerability risk information, the version range influenced by the target vulnerability risk information can be used as an alternative version range; otherwise, the version range except the version range affected by the vulnerability risk information in all the version information of the open source component can be used as the alternative version range.
Step A03, judging whether the total number of versions in the alternative version range is greater than 1 to obtain a judgment result;
if the judgment result is greater than 1, the target version of the source code of the open source component used by the target component is determined, and the step A01 is executed continuously; otherwise, go to step A04;
and A04, recording the version information in the alternative version range as the target version of the source code of the source component in the target component.
According to the method provided by the embodiment of the application, vulnerability risk information is selected from vulnerability risk information in pre-stored open source components to serve as target vulnerability risk information, whether the target components exist in the target vulnerability risk information is detected, a detection result is obtained, an alternative version range corresponding to the detection result is determined according to version information influenced by the target vulnerability risk information in the open source components, whether the total number of versions in the alternative version range is larger than 1 is judged, and a judgment result is obtained; if the judgment result is more than 1, continuing to execute circularly; otherwise, recording the version information in the alternative version range as the target version of the source code of the open source component in the target component, and achieving the purpose of determining the target version of the source code of the open source component in the target component by means of vulnerability detection and with the help of the version range influenced by the vulnerability in the open source component.
The method provided by the embodiments of the present application is explained as follows:
according to whether the target vulnerability risk information exists in the target component, the following three conditions can be classified:
the first condition is as follows: the detection result is that the target vulnerability risk information exists in the target component;
case two: the detection result indicates that the target vulnerability risk information does not exist in the target component;
case two: the total number of the target vulnerability risk information is at least two, and the detection result indicates that one part of the target vulnerability risk information exists in the target component and the other part of the target vulnerability risk information does not exist in the target component.
The following is separately described for each case:
the first condition is as follows:
when the detection result indicates that the target component has the target vulnerability risk information, the target component may be divided into the following two types according to the total number of the used target vulnerability risk information, including:
a1, if the total number of the target vulnerability risk information is 1, taking the version range influenced by the target vulnerability risk information as an alternative version range;
for example, if the used target vulnerability risk information is vulnerability 1, the scope of vulnerability 1 affected by the open source component is directly used as the scope of the alternative version.
A2, if the total number of the target vulnerability risk information is at least two, determining a common version in the version range influenced by each target vulnerability risk information in the at least two target vulnerability risk information to obtain an alternative version range;
for example, the target vulnerability risk information used is vulnerability 1 and vulnerability 2, if the scope of influence of vulnerability 1 on the open source component includes version 1.0.0, 1.0.2, 2.0.0 and 2.0.1; the version range affected by vulnerability 2 includes version 1.0.0, 2.0.0 and 3.0.0; since the version ranges affected by the vulnerability 1 and the vulnerability 2 both include the versions 1.0.0 and 2.0.0, the versions 1.0.0 and 2.0.0 are used as the alternative version ranges.
Case two:
when the detection result indicates that the target component does not have the target vulnerability risk information, the target component can be divided into the following two types according to the total number of the used target vulnerability risk information, including:
b1, if the total number of the target vulnerability risk information is 1, determining the version except the version range influenced by the target vulnerability risk information in the whole version range of the open source component as an alternative version range;
for example, if the used target vulnerability risk information is vulnerability 1, the scope of vulnerability 1 affected by the open source component includes version 1.0.0, 1.0.2, 2.0.0 and 2.01; if all versions of the open source assembly include: versions 1.0.0, 1.0.1, 2.0.0, 2.0.1, 3.0.0, 3.0.1, 4.0.0, and 4.0.1, and when the version range corresponding to the vulnerability 1 is removed from all versions, the version range is taken as an alternative version range if the version range obtained includes 3.0.0, 3.0.1, 4.0.0, and 4.0.1.
B2, if the total number of the target vulnerability risk information is at least two, determining a maximum version range corresponding to the at least two target vulnerability risk information, where the maximum version range includes all versions in the version range affected by each of the at least two target vulnerability risk information, and obtaining an alternative version range by using the full version range of the switch component and the maximum version range.
For example, the target vulnerability risk information used is vulnerability 1 and vulnerability 2, if the scope of influence of vulnerability 1 on the open source component includes version 1.0.0, 1.0.2, 2.0.0 and 2.0.1; the version range affected by vulnerability 2 includes version 1.0.0, 2.0.0 and 3.0.0; all versions of the open source component include: versions 1.0.0, 1.0.1, 2.0.0, 2.0.1, 3.0.0, 3.0.1, 4.0.0, 4.0.1, and the maximum version range affected by the vulnerability 1 and the vulnerability 2 includes versions 1.0.0, 1.0.2, 2.0.0, 2.0.1, and 3.0.0, and after the version range corresponding to the vulnerability 1 is removed from the entire versions, the obtained version ranges include 3.0.1, 4.0.0, and 4.0.1, and then the version ranges are used as alternative version ranges.
Case three:
and when the detection result indicates that M target vulnerability risk information exists in the target component and N target vulnerability risk information does not exist in the target component, two different version ranges are required to be determined respectively.
Determining a common version range in the version ranges influenced by each target hole leakage risk information in the M target hole leakage risk information by adopting the mode of the condition I to obtain a first version range;
determining a maximum version range corresponding to the N target vulnerability risk information by using the above second method, and obtaining a second version range by using all version ranges of the open source component and the maximum version range, wherein the maximum version range includes all versions in the version range affected by each of the N target vulnerability risk information;
the first version range represents a possible version range determined according to M target vulnerability risk information existing in the target component, the second version range represents a possible version range determined according to M target vulnerability risk information not existing in the target component, and an alternative version range is obtained according to a version range shared by the first version range and the second version range;
and M and N are positive integers, and the sum of M and N is equal to the total number of the target vulnerability risk information.
Based on the content, the alternative version range corresponding to the target vulnerability risk information can be determined.
In an exemplary embodiment, selecting target vulnerability risk information as target vulnerability risk information from pre-stored target vulnerability risk information in an open source component includes:
after the alternative version range is obtained, obtaining an alternative version in the alternative version range;
and selecting target vulnerability risk information according to the alternative versions in the alternative version range.
If the total number of the versions in the range of the alternative versions is a, vulnerability risk information with the influence range having at most a-1 versions in the alternative versions can be selected as target risk information. If the range of the alternative versions is 3.0.1, 4.0.0 and 4.0.1, as the total number of the versions in the alternative versions is 3, vulnerability risk information affecting the range of one or two of the versions can be selected as target risk information so as to further narrow the value range of the alternative versions, wherein a is an integer greater than or equal to 2.
And selecting the target vulnerability risk information according to the version information in the alternative version, so that the determination efficiency of the target version can be improved.
In an exemplary embodiment, the selecting target vulnerability risk information according to the alternative version in the alternative version range includes:
selecting vulnerability risk information with an influence range including at least one alternative version as pre-selected vulnerability risk information;
and selecting at least two pieces of preselected vulnerability risk information as target vulnerability risk information according to the alternative versions corresponding to the preselected vulnerability risk information.
The vulnerability risk information with the influence range having at most a-1 versions in the alternative versions can be selected as preselected vulnerability risk information according to the total number of the versions in the version selection range being a, the alternative versions in the alternative version range are divided into b classes according to the alternative versions corresponding to the preselected vulnerability risk information, and the alternative versions in each class are not overlapped or partially overlapped; and selecting pre-selected vulnerability risk information of which the influence range only contains the classification but does not contain other b-1 classifications for each classification, and taking the combination of the pre-selected vulnerability risk information corresponding to each classification as the target vulnerability risk information selected at this time.
If the alternative versions are versions 3.0.1, 4.0.0 and 4.0.1, as the total number of versions in the alternative versions is 3, vulnerability risk information of one or two version ranges with influence ranges can be selected as preselected vulnerability risk information, for example, the influence range of vulnerability 3 is 3.0.1 and 5.0.0; the influence ranges of the loopholes 4 are 4.0.0, 4.0.1 and 6.0.0, and because one alternative version exists in the influence range of the loopholes 3 and two alternative versions exist in the influence range of the loopholes 3, the loopholes 3 and the loopholes 4 can be used as preselected loophole risk information.
And according to the alternative versions in the influence ranges of the vulnerabilities 3 and 4, dividing the alternative version range into two types, wherein one type is version 3.0.1, and the other types are version 4.0.0 and version 4.0.1, and selecting a combination of the vulnerabilities 3 and 4 as the target vulnerability risk information selected at this time.
And combining the preselected vulnerability risk information according to the alternative versions to serve as target risk information so as to further narrow the value range of the alternative versions.
In one exemplary embodiment, the method further comprises:
after a target version of a source code of a source component in the target component is determined, acquiring vulnerability patch data corresponding to the target version from vulnerability patch data corresponding to different versions of the source component;
and carrying out vulnerability processing operation on the target component by using the target vulnerability patch data.
And acquiring corresponding patch data based on the target version of the source code of the open source component to complete processing of the vulnerability, so that the safety of the target component can be improved.
The method provided by the embodiment of the present application is described below by taking an open source component as an open source database as an example:
in the secondary development process based on the open source database, if the open source database is not well controlled in version, the secondary developed open source database cannot be effectively updated after the security vulnerability of the open source database is updated, and the security problem is caused. Therefore, it is necessary to efficiently determine the source code version of the secondary developed open source database.
Fig. 2 is a schematic diagram of a version evaluation system for a database provided in an embodiment of the present application. As shown in fig. 2, the system includes:
the system comprises a vulnerability database, a database server and a database server, wherein the vulnerability database mainly collects all vulnerability information of a source database, and mainly comprises vulnerability codes and vulnerability influence ranges;
POC library: mainly recording all POC information existing in a source database, wherein the POC information mainly comprises a vulnerability verification program and a vulnerability number;
docker library: mainly building an open source database docker target drone environment library of a version to be verified;
a source code library: the source code of each branch of the source database is mainly collected. Calling a preset vulnerability security detection tool for detection;
and the automatic scheduling platform is used for determining the version of the open source database through the POC data and the source code and outputting an evaluation result.
In the system shown in fig. 2, POC data of a vulnerability is used for verification in a secondary development redis database to be verified; if the valid verification result can be output, the POC data only corresponds to one CVE number (or CNNVD number); each vulnerability number has a corresponding response range, and the specific recording mode is as follows:
redis Labs Redis input verification error vulnerability
CNNVD-202105 and 105 hazard classes: high risk
CVE number: CVE-2021-: input validation errors
Release time: 2021-05-04 threat types: remote control
Updating time: manufacturers 2021-07-02: redis Labs, Inc., USA
Vulnerability sources: red Hat
Vulnerability introduction:
redis Labs Redis is an open source, network-enabled, journaled, Key-Value (Key-Value) storage data system written using ANSIC, which may be content-based or persistent, and provides APIs in multiple languages, available from Redis Labs, Inc. of America.
Redis has an input validation error hole that results from STRALGLCS command integer overflow, which a remote attacker can use to execute arbitrary code on a target system, with the following products and versions affected: redis: 6.0.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.0.9, 6.0.10, 6.0.11, 6.0.12, 6.2.0, 6.2.1, 6.2.2.
After the verification operation is performed, there are two cases:
in the first case:
if the secondary development database is effectively verified to have the vulnerability with the number CVE-2021-29477, the verified database version is in the range of 6.0.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.0.9, 6.0.10, 6.0.11, 6.0.12, 6.2.0, 6.2.1 and 6.2.2.
Similarly, if a plurality of vulnerabilities can be effectively verified, the version range of the verified database can be further reduced.
The end is defined when the valid verification result of the POC can finally determine the version of redis for secondary development. And when the POC is effectively verified, the version of the redis finally determined to be in one interval, and then the source database source code base is used for carrying out file comparison to finally determine the version of the redis.
In the second case:
if the valid verification result is not output through the POC; because each vulnerability number is associated with an influence range, the version range of the secondary development database can be determined through an exclusion method; then, combining asset management and questionnaire survey information, narrowing the final version range; and finally, performing file comparison by starting a source database source code base to finally determine the version of the secondary development redis.
Based on the above manner, the determination of the target version of the source database can be realized.
An embodiment of the present application provides a storage medium, in which a computer program is stored, wherein the computer program is configured to perform the method described in any one of the above when the computer program runs.
An embodiment of the application provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the computer program to perform the method described in any one of the above.
It will be understood by those of ordinary skill in the art that all or some of the steps of the methods, systems, functional modules/units in the devices disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed by several physical components in cooperation. Some or all of the components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on computer readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). The term computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data, as is well known to those of ordinary skill in the art. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by a computer. In addition, communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media as known to those skilled in the art.
Claims (10)
1. A method of determining a version of an open source component, comprising:
a01, selecting vulnerability risk information as target vulnerability risk information from the prestored vulnerability risk information in the open source component;
a02, detecting whether the target component has the target vulnerability risk information to obtain a detection result, wherein the target component is obtained based on the secondary development of the source code of the open source component;
step A03, determining an alternative version range corresponding to the detection result according to version information influenced by the target vulnerability risk information in the open source component;
step A04, judging whether the total number of versions in the alternative version range is greater than 1 to obtain a judgment result;
if the judgment result is greater than 1, continuing to execute the step A01; otherwise, go to step A05;
and A05, recording the version information in the alternative version range as the target version of the source code of the source component in the target component.
2. The method of claim 1, further comprising:
after a target version of a source code of a source component in the target component is determined, acquiring vulnerability patch data corresponding to the target version from vulnerability patch data corresponding to different versions of the source component;
and carrying out vulnerability processing operation on the target component by using the target vulnerability patch data.
3. The method according to claim 1, wherein the detecting whether the target component has the target vulnerability risk information to obtain a detection result comprises:
technical verification POC data of target vulnerability risk information is obtained;
for each target vulnerability risk information, carrying out verification operation on the target component by using the source code and the POC data of the open source component, and if the verification operation can determine vulnerability identification information of the target vulnerability risk information, determining that the target vulnerability risk information exists in the target component; otherwise, determining that the target component does not have the target vulnerability risk information.
4. The method according to claim 1, wherein when the detection result is that the target component has the target vulnerability risk information, determining the alternative version range corresponding to the detection result according to the version information affected by the target vulnerability risk information in the open source component comprises:
if the total number of the target vulnerability risk information is 1, taking the version range influenced by the target vulnerability risk information as an alternative version range;
and if the total number of the target vulnerability risk information is at least two, determining a common version in the version range influenced by each target vulnerability risk information in the at least two target vulnerability risk information to obtain an alternative version range.
5. The method according to claim 1, wherein when the detection result indicates that the target vulnerability risk information does not exist in the target component, determining the alternative version range corresponding to the determination result according to the version information affected by the target vulnerability risk information in the open source component comprises:
if the total number of the target vulnerability risk information is 1, determining the version except the version range influenced by the target vulnerability risk information in all the version ranges of the open source component as an alternative version range;
if the total number of the target vulnerability risk information is at least two, determining the maximum version range corresponding to the at least two target vulnerability risk information, wherein the maximum version range comprises all versions in the version range influenced by each of the at least two target vulnerability risk information, and obtaining an alternative version range by using the whole version range of the open source component and the maximum version range.
6. The method according to claim 1, wherein when the detection result indicates that M target vulnerability risk information exists in the target component and N target vulnerability risk information does not exist, determining the alternative version range corresponding to the determination result according to the version information affected by the target vulnerability risk information in the open source component includes:
determining a common version range in the version ranges influenced by each target vulnerability risk information in the M target vulnerability risk information to obtain a first version range;
determining a maximum version range corresponding to the N target vulnerability risk information, wherein the maximum version range comprises all versions in the version range influenced by each of the N target vulnerability risk information, and obtaining a second version range by using all version ranges of the open source component and the maximum version range;
obtaining an alternative version range according to the first version range and the second version range;
and M and N are positive integers, and the sum of M and N is equal to the total number of the target vulnerability risk information.
7. The method according to any one of claims 1 to 6, wherein selecting vulnerability risk information as target vulnerability risk information from the pre-stored vulnerability risk information in the open source component comprises:
after the alternative version range is obtained, obtaining an alternative version in the alternative version range;
and selecting target vulnerability risk information according to the alternative versions in the alternative version range.
8. The method according to claim 7, wherein selecting target vulnerability risk information according to the alternative versions in the alternative version range comprises:
selecting vulnerability risk information with an influence range including at least one alternative version as preselected vulnerability risk information;
and selecting at least two pieces of preselected vulnerability risk information as target vulnerability risk information according to the alternative versions corresponding to the preselected vulnerability risk information.
9. A storage medium, in which a computer program is stored, wherein the computer program is arranged to perform the method of any of claims 1 to 8 when executed.
10. An electronic device comprising a memory and a processor, wherein the memory has stored therein a computer program, and wherein the processor is arranged to execute the computer program to perform the method of any of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110931931.3A CN113778509A (en) | 2021-08-13 | 2021-08-13 | Method for determining version of open source component, storage medium and electronic device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110931931.3A CN113778509A (en) | 2021-08-13 | 2021-08-13 | Method for determining version of open source component, storage medium and electronic device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113778509A true CN113778509A (en) | 2021-12-10 |
Family
ID=78837677
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110931931.3A Pending CN113778509A (en) | 2021-08-13 | 2021-08-13 | Method for determining version of open source component, storage medium and electronic device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113778509A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023241529A1 (en) * | 2022-06-17 | 2023-12-21 | 阿里云计算有限公司 | Vulnerability information processing method, service apparatus and vulnerability detection module |
Citations (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106446691A (en) * | 2016-11-24 | 2017-02-22 | 工业和信息化部电信研究院 | Method and device for detecting integrated or customized open source project bugs in software |
| CN108200029A (en) * | 2017-12-27 | 2018-06-22 | 北京知道创宇信息技术有限公司 | Loophole situation detection method, device, server and readable storage medium storing program for executing |
| CN110543767A (en) * | 2019-08-10 | 2019-12-06 | 苏州浪潮智能科技有限公司 | automatic monitoring method and system for open source component vulnerability |
| US20200042712A1 (en) * | 2018-07-31 | 2020-02-06 | Veracode, Inc. | Open-source software vulnerability analysis |
| CN110837646A (en) * | 2019-10-31 | 2020-02-25 | 国网河北省电力有限公司电力科学研究院 | Risk investigation device of unstructured database |
| US20200074084A1 (en) * | 2018-08-29 | 2020-03-05 | Microsoft Technology Licensing, Llc | Privacy-preserving component vulnerability detection and handling |
| CN110909363A (en) * | 2019-11-25 | 2020-03-24 | 中国人寿保险股份有限公司 | Software third-party component vulnerability emergency response system and method based on big data |
| CN111400719A (en) * | 2020-03-12 | 2020-07-10 | 中国科学院信息工程研究所 | Firmware vulnerability distinguishing method and system based on open source component version identification |
| CN111625839A (en) * | 2020-05-29 | 2020-09-04 | 深圳前海微众银行股份有限公司 | Third-party component vulnerability detection method, device, equipment and computer storage medium |
| CN111752586A (en) * | 2020-06-23 | 2020-10-09 | 上海交通大学 | Method and system for detecting unrepaired bugs of cross-architecture embedded equipment firmware |
| CN111797402A (en) * | 2020-06-17 | 2020-10-20 | 北京世纪互联宽带数据中心有限公司 | Method, device and storage medium for detecting software vulnerability |
| CN111931183A (en) * | 2020-07-31 | 2020-11-13 | 中国工商银行股份有限公司 | Open source software security vulnerability processing method and device |
| US20210056209A1 (en) * | 2019-08-22 | 2021-02-25 | Sonatype, Inc. | Method, system, and storage medium for security of software components |
| CN113094711A (en) * | 2021-04-30 | 2021-07-09 | 云南电网有限责任公司 | Open source code detection method and system based on staged project development |
| CN113127351A (en) * | 2021-04-20 | 2021-07-16 | 长沙市到家悠享家政服务有限公司 | Third-party component detection method, system and computer equipment |
-
2021
- 2021-08-13 CN CN202110931931.3A patent/CN113778509A/en active Pending
Patent Citations (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106446691A (en) * | 2016-11-24 | 2017-02-22 | 工业和信息化部电信研究院 | Method and device for detecting integrated or customized open source project bugs in software |
| CN108200029A (en) * | 2017-12-27 | 2018-06-22 | 北京知道创宇信息技术有限公司 | Loophole situation detection method, device, server and readable storage medium storing program for executing |
| US20200042712A1 (en) * | 2018-07-31 | 2020-02-06 | Veracode, Inc. | Open-source software vulnerability analysis |
| US20200074084A1 (en) * | 2018-08-29 | 2020-03-05 | Microsoft Technology Licensing, Llc | Privacy-preserving component vulnerability detection and handling |
| CN110543767A (en) * | 2019-08-10 | 2019-12-06 | 苏州浪潮智能科技有限公司 | automatic monitoring method and system for open source component vulnerability |
| US20210056209A1 (en) * | 2019-08-22 | 2021-02-25 | Sonatype, Inc. | Method, system, and storage medium for security of software components |
| CN110837646A (en) * | 2019-10-31 | 2020-02-25 | 国网河北省电力有限公司电力科学研究院 | Risk investigation device of unstructured database |
| CN110909363A (en) * | 2019-11-25 | 2020-03-24 | 中国人寿保险股份有限公司 | Software third-party component vulnerability emergency response system and method based on big data |
| CN111400719A (en) * | 2020-03-12 | 2020-07-10 | 中国科学院信息工程研究所 | Firmware vulnerability distinguishing method and system based on open source component version identification |
| CN111625839A (en) * | 2020-05-29 | 2020-09-04 | 深圳前海微众银行股份有限公司 | Third-party component vulnerability detection method, device, equipment and computer storage medium |
| CN111797402A (en) * | 2020-06-17 | 2020-10-20 | 北京世纪互联宽带数据中心有限公司 | Method, device and storage medium for detecting software vulnerability |
| CN111752586A (en) * | 2020-06-23 | 2020-10-09 | 上海交通大学 | Method and system for detecting unrepaired bugs of cross-architecture embedded equipment firmware |
| CN111931183A (en) * | 2020-07-31 | 2020-11-13 | 中国工商银行股份有限公司 | Open source software security vulnerability processing method and device |
| CN113127351A (en) * | 2021-04-20 | 2021-07-16 | 长沙市到家悠享家政服务有限公司 | Third-party component detection method, system and computer equipment |
| CN113094711A (en) * | 2021-04-30 | 2021-07-09 | 云南电网有限责任公司 | Open source code detection method and system based on staged project development |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023241529A1 (en) * | 2022-06-17 | 2023-12-21 | 阿里云计算有限公司 | Vulnerability information processing method, service apparatus and vulnerability detection module |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10885201B2 (en) | Apparatus for quantifying security of open-source software package, and apparatus and method for optimizing open-source software package | |
| US8966634B2 (en) | System and method for correcting antivirus records and using corrected antivirus records for malware detection | |
| CN112395616B (en) | Vulnerability processing method and device and computer equipment | |
| US11893117B2 (en) | Software package analysis for detection of malicious properties | |
| KR20130134790A (en) | Method and system for storing the integrity information of application, method and system for checking the integrity of application | |
| US8930970B2 (en) | Method and computer for obtaining using-frequency of application program | |
| CN109815697A (en) | Wrong report behavior processing method and processing device | |
| CN113778509A (en) | Method for determining version of open source component, storage medium and electronic device | |
| CN114139161A (en) | Method, device, electronic equipment and medium for batch vulnerability detection | |
| US20230017839A1 (en) | Risk analysis result display apparatus, method, and computer readable media | |
| US20220284109A1 (en) | Backdoor inspection apparatus, backdoor inspection method, and non-transitory computer readable medium | |
| KR102415494B1 (en) | Emulation based security analysis method for embedded devices | |
| CN115658492A (en) | Method and device for detecting abnormal value of kernel configuration item | |
| CN115391224A (en) | Flow playback method and device, computer equipment and readable storage medium | |
| CN107291618B (en) | Application storage method and device and terminal equipment | |
| AU2021427822B2 (en) | Information processing device, information processing method, and information processing program | |
| CN114969759B (en) | Asset security assessment method, device, terminal and medium of industrial robot system | |
| CN109918895B (en) | Method, electronic device, and computer-readable medium for outputting data | |
| KR101480244B1 (en) | Method for detecting malicious application using signature on class basis and device enabling the method | |
| TWI718636B (en) | Software security detecting system and software security detecting method | |
| US20230004642A1 (en) | Application integrity verification | |
| US11907710B2 (en) | Source code analysis apparatus | |
| CN112230935B (en) | Privacy risk detection method, device and equipment in application | |
| CN114896117A (en) | White list-based memory behavior monitoring method and device in software installation and update process | |
| Yashavant | SecSEC: Securing Smart Ethereum Contracts |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |