Data verification method and device for open source components

Abstract

The application discloses a data checking method and device for open source components, and the method comprises the following steps: dividing each component data collected into compulsory data and non-compulsory data; determining whether the compulsory data in each component data is collected in the current collection; if the result is yes, recording the component data to a normal data storage device, and determining whether component permission information exists in a preset permission library, whether component version information exists in a preset version library, and whether a component release time conforms to a set format; if the component permission information does not exist in the preset permission library, marking in the normal data storage device and recording to an abnormal data storage device; if the component version information does not exist in the preset version library, marking in the normal data storage device and recording to the abnormal data storage device; and if the component release time does not conform to the set format, marking in the normal data storage device and recording to the abnormal data storage device.

Description

Data verification methods and devices for open source components Technical Field

[0001] This application relates to the field of data verification technology for open-source components, specifically to a data verification method and apparatus for open-source components. Background Technology

[0002] In modern software development, verifying the security data of open-source components involves analyzing the correctness of this data. Currently, several methods exist for data verification during the data collection phase. These methods generally employ the same warning procedure when any data metric is detected as problematic (e.g., not collected or collected metrics not meeting requirements). However, in some cases, for certain component metrics, a missing metric might simply mean the component lacks the corresponding metric. This data might then be mistakenly identified as problematic and prevented from proceeding to the next stage (data synchronization), thus affecting the accuracy of data verification and the rationality of data updates. Furthermore, even if some component metrics are not perfectly accurate, they generally have little impact on subsequent data processing. However, current verification methods prevent this component data from proceeding to the next stage, further compromising the rationality of data updates.

[0003] In addition, current data verification methods do not perform full-process data verification, that is, data verification is not performed in the data acquisition, data synchronization, data cleaning and data upgrade stages. However, in reality, data problems may occur at each stage. Therefore, existing data verification methods cannot guarantee that the final data obtained is all problem-free. Summary of the Invention

[0004] The purpose of this application is to provide a data verification method, device, electronic device, and computer-readable storage medium for open-source components, which can solve at least one of the above-mentioned technical problems.

[0005] To achieve the above objectives, this application provides a data verification method for an open-source component, comprising:

[0006] The component data collected in the current data collection phase is divided into required data and optional data. The required data includes the component name and component release time in the component data, and the optional data includes the component license information and component version information in the component data.

[0007] Determine whether the required data in each component data entry was collected in the current data collection.

[0008] If the result is negative, the data of the aforementioned component will be recorded in the abnormal data storage device and a first-level warning operation will be performed.

[0009] If the result is yes, then the component data is recorded in the normal data storage device, and it is determined whether the component license information collected in the current time exists in the preset license library, whether the component version information collected in the current time exists in the preset version library, and whether the component release time collected in the current time conforms to the set format.

[0010] If the component license information collected in the current instance does not exist in the preset license library, it is marked in the component table of the normal data storage device, and recorded in the abnormal data storage device and a second-level warning operation is performed, where the first level is higher than the second level.

[0011] If the component version information collected in the current iteration does not exist in the preset version library, then it is marked in the component table of the normal data storage device, and recorded in the abnormal data storage device and a second-level warning operation is performed.

[0012] If the release time of the component collected in the current instance does not conform to the set format, it is marked in the component table of the normal data storage device, and recorded in the abnormal data storage device, and the second level of early warning operation is performed.

[0013] Optionally, the method further includes:

[0014] Each vulnerability data point collected during the data acquisition phase has a correlation attribute, which is information about the components affected by the vulnerability and the range of component versions.

[0015] Determine whether the associated attribute of each vulnerability data entry is empty. If the result is no, record the vulnerability data entry to a normal data storage device. If the result is yes, record the vulnerability data entry to an abnormal data storage device and perform a first-level warning operation.

[0016] Optionally, during the data synchronization phase, after synchronizing the data stored on the normal data storage device, a change comparison step is also included:

[0017] The change in the component data is compared with a first upper limit threshold and a first lower limit threshold, respectively. If the change in the component data is greater than the first upper limit threshold or less than the second lower limit threshold, a warning message is issued.

[0018] The change in the vulnerability data is compared with the second upper limit threshold and the second lower limit threshold respectively. If the change in the vulnerability data is greater than the second upper limit threshold or less than the second lower limit threshold, a warning message is issued.

[0019] Optionally, during the data cleaning phase, when cleaning the synchronized data, a component-vulnerability relationship table and a component-license relationship table are established, and the number of vulnerabilities corresponding to each component version is recorded in the component table used to record the component data.

[0020] After data cleaning, the method further includes:

[0021] Determine whether the number of vulnerabilities corresponding to each component version in the component table is equal to the number of data rows for the corresponding component version in the component-vulnerability relationship table. If the result is not equal, issue a warning message; and

[0022] Determine whether the license information for each component in the component table exists in the component and license relationship table. If the result is no, issue a warning message.

[0023] Optionally, after data cleaning, the method further includes:

[0024] Determine whether the key fields of each component data entry are empty; if the result is yes, issue a warning message.

[0025] Optionally, after data cleaning, the method further includes:

[0026] The cleaned data is verified using data from the pre-established and regularly maintained benchmark database. If the cleaned data contains data that is inconsistent with the data in the benchmark database, a warning message is issued.

[0027] Optionally, the method further includes:

[0028] After the data cleaning phase is completed, the change in the first data compared to the current cleaning phase is statistically analyzed, and the content of the cleaned data is sampled and checked.

[0029] After the cleaned data is upgraded, the change in the second data compared to the previous upgrade is statistically analyzed, and the content of the upgraded data is sampled and checked. The upgraded data sampled and checked are consistent with the cleaned data sampled and checked.

[0030] Determine whether the second data change amount and the first data change amount are consistent, and whether the content of the upgraded data of the sampling inspection is the same as the content of the cleaned data of the sampling inspection.

[0031] If the result is negative, a warning message will be issued.

[0032] To achieve the above objectives, this application also provides a data verification device for an open-source component, comprising:

[0033] The segmentation module is used to divide the component data collected in the current data collection phase into required data and non-required data. The required data includes the component name and component release time in the component data, and the non-required data includes the component license information and component version information in the component data.

[0034] The determination module is used to determine whether the required data in each piece of component data has been collected in the current collection.

[0035] The recording and early warning module is used to record the component data to the abnormal data storage device and perform a first-level early warning operation if the result is negative.

[0036] The recording and determination module is used to record the component data to a normal data storage device if the result is yes, and to determine whether the component license information collected in the current time exists in a preset license library, whether the component version information collected in the current time exists in a preset version library, and whether the release time of the component collected in the current time conforms to a set format.

[0037] The first marking and recording module is used to mark the component in the component table of the normal data storage device and record it in the abnormal data storage device if the component license information collected in the current time does not exist in the preset license library, and to perform a second-level warning operation. The first level is higher than the second level. The preset license library is maintained according to the commonly used license sites.

[0038] The second marking and recording module is used to mark the component in the component table of the normal data storage device if the component version information collected in the current time does not exist in the preset version library, and to record it to the abnormal data storage device and perform a second-level warning operation. The preset version library is maintained according to a commonly used open source site.

[0039] The third marking and recording module marks the component's release time in the normal data storage device's component table and the abnormal data storage device in the abnormal data storage device if the component's release time does not conform to the set format. It also performs a second-level warning operation.

[0040] To achieve the above objectives, this application also provides an electronic device, comprising:

[0041] processor;

[0042] A memory in which executable instructions of the processor are stored;

[0043] The processor is configured to execute the data verification method of the open-source component as described above by executing the executable instructions.

[0044] To achieve the above objectives, this application also provides a computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the data verification method of the open-source component as described above.

[0045] This application also provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the data verification method of the open-source component as described above.

[0046] This application divides each piece of component data collected during the data acquisition phase into mandatory data and non-mandatory data. As long as the mandatory data can be collected in the current acquisition, regardless of the acquisition status of the non-mandatory data, the component data is recorded in the normal data storage device, so that it can proceed to the next stage of processing. This avoids the situation where the component data cannot proceed to the next stage of processing because the non-mandatory data is not collected or the collected data does not meet the requirements, thus effectively improving the rationality of local component data updates. Furthermore, assuming that the required data is collected in the current iteration, if the component license information collected in the current iteration does not exist in the preset license library, it will be marked in the component table of the normal data storage device and recorded in the abnormal data storage device for a second-level warning operation. If the component version information collected in the current iteration does not exist in the preset version library, it will be marked in the component table of the normal data storage device and recorded in the abnormal data storage device for a second-level warning operation. If the release time of the component collected in the current iteration does not conform to the set format, it will be marked in the component table of the normal data storage device and recorded in the abnormal data storage device for a second-level warning operation. In other words, if the collected non-required data does not meet the above requirements but does not affect the subsequent processing of the component data, this application can mark it in the component table of the normal data storage device and record it in the abnormal data storage device for a warning operation, which is convenient for reminding developers. Attached Figure Description

[0047] Figure 1 is a flowchart of the data verification method of the open source component in an embodiment of this application.

[0048] Figure 2 is a schematic block diagram of the data verification device of the open source component in an embodiment of this application.

[0049] Figure 3 is a schematic block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0050] To explain in detail the technical content, structural features, objectives and effects of this application, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0051] Example 1

[0052] Referring to Figure 1, this application discloses a data verification method for open-source components, including:

[0053] 101. Divide the component data collected in the current data collection phase into required data and optional data. Required data includes the component name and component release time in the component data. Optional data includes the component license information and component version information in the component data.

[0054] Data collection during the data acquisition phase is performed by collecting data from open-source websites using the unique identifier of the component (component name) on the local machine. For a small number of components, component license information and component version information may not exist, so this application classifies them as optional data.

[0055] 102. Determine whether the required data in each component data has been collected in the current collection. If the result is no, proceed to step 103. If the result is yes, proceed to steps 104, 105, 106, and 107.

[0056] 103. Record this component data to the abnormal data storage device and perform a first-level warning operation. The first level is the highest abnormal level, indicating that an error (ERROR) has occurred.

[0057] 104. Record this component data to a normal data storage device.

[0058] 105. Determine whether the component license information collected in the current iteration exists in the preset license library. If the result is no, proceed to step 108.

[0059] 106. Determine whether the component version information collected in the current iteration exists in the preset version library. If the result is no, proceed to step 108.

[0060] 107. Determine if the release time of the component collected in the current batch conforms to the set format. If the result is no, proceed to step 108.

[0061] 108. Mark it in the component table of normal data storage device, and record it to abnormal data storage device and perform a second-level (WARN) warning operation. The first level is higher than the second level (i.e. the severity of the second level is lower than the first level).

[0062] The default license library is maintained based on commonly used license sites and is updated regularly. Common component licenses are collected in the default license library. If the component license information collected in the last collection does not exist in the default license library, it is highly likely that the component license information is not a regular license. Therefore, it can be marked in the component table of the normal data storage device, and recorded to the abnormal data storage device with a second-level warning operation to remind the developers.

[0063] The default version repository is maintained based on commonly used open-source sites and is updated regularly. Common component versions are collected in the default license repository. If the component version information collected this time does not exist in the default version repository, it is likely that the component version information is special. Therefore, it can be marked in the component table of the normal data storage device, and recorded to the abnormal data storage device with a second-level warning operation to remind the developers.

[0064] Since whether the format of the component release time conforms to the set format is only a formality issue and will not affect subsequent data processing, when the format of the component release time does not conform to the set format, it can be marked in the component table of the normal data storage device, and recorded in the abnormal data storage device for a second-level warning operation, thereby reminding the developers to fix it.

[0065] This application divides each piece of component data collected during the data acquisition phase into mandatory data and non-mandatory data. As long as the mandatory data can be collected in the current acquisition, regardless of the acquisition status of the non-mandatory data, the component data is recorded in the normal data storage device, so that it can proceed to the next stage of processing. This avoids the situation where the component data cannot proceed to the next stage of processing because the non-mandatory data is not collected or the collected data does not meet the requirements, thus effectively improving the rationality of local component data updates. Furthermore, assuming that the required data is collected in the current iteration, if the component license information collected in the current iteration does not exist in the preset license library, it will be marked in the component table of the normal data storage device and recorded in the abnormal data storage device for a second-level warning operation. If the component version information collected in the current iteration does not exist in the preset version library, it will be marked in the component table of the normal data storage device and recorded in the abnormal data storage device for a second-level warning operation. If the release time of the component collected in the current iteration does not conform to the set format, it will be marked in the component table of the normal data storage device and recorded in the abnormal data storage device for a second-level warning operation. In other words, if the collected non-required data does not meet the above requirements but does not affect the subsequent processing of the component data, this application can mark it in the component table of the normal data storage device and record it in the abnormal data storage device for a warning operation, which is convenient for reminding developers.

[0066] Specifically, the method also includes:

[0067] The vulnerability data collected during the data acquisition phase has a correlation attribute, which includes information about the components affected by the vulnerability and the range of component versions. In other words, this application collects vulnerability data from specific sites, resulting in a correlation between the collected vulnerability data.

[0068] Determine whether the associated attribute of each vulnerability data is empty. If the result is no, record the vulnerability data in the normal data storage device (vulnerability table). If the result is yes, record the vulnerability data in the abnormal data storage device and perform the first-level warning operation.

[0069] Each vulnerability record includes the vulnerability number, vulnerability release date, and vulnerability description.

[0070] This application ensures that each piece of vulnerability data collected has an association attribute, and only records it into the vulnerability table of the normal data storage device when it is confirmed that the association attribute of each piece of vulnerability data is not empty, thereby ensuring that the vulnerability data collected by the normal data storage device contains information about the components affected by the vulnerability and the range of component versions.

[0071] Specifically, in the data synchronization phase (i.e., synchronizing data to another storage device, which is a standard procedure in the field and will not be described in detail here), after synchronizing the data stored on the normal data storage device, a change comparison step is also included:

[0072] The amount of change in component data (i.e. the number of component data entries that have changed) is compared with the first upper limit threshold and the first lower limit threshold respectively. If the amount of change in component data is greater than the first upper limit threshold or less than the second lower limit threshold, a warning message is issued.

[0073] The amount of change in the vulnerability data (i.e. the number of component data entries that have changed) is compared with the second upper limit threshold and the second lower limit threshold respectively. If the amount of change in the vulnerability data is greater than the second upper limit threshold or less than the second lower limit threshold, a warning message is issued.

[0074] Since the amount of data updated each time usually fluctuates within a certain range, if it is outside this range, it means that there may be a problem with the data update. Therefore, this application compares the amount of data change with a set threshold to determine whether there may be an anomaly and issues a warning message accordingly, so that human intervention can be carried out.

[0075] Specifically, during the data cleaning phase, a component-vulnerability relationship table and a component-license relationship table are established when cleaning the synchronized data. Additionally, a component table is used to record the number of vulnerabilities corresponding to each version of each component. The component-vulnerability relationship table establishes the influence relationship between components in the component table and vulnerabilities in the vulnerability table, while the component-license relationship table establishes the association relationship between components in the component table and licenses in the preset license table. These are standard operations during the data cleaning phase and are known to those skilled in the art, and will not be detailed here.

[0076] After data cleaning, the methods also include:

[0077] Determine whether the number of vulnerabilities corresponding to each version of each component in the component table is equal to the number of data rows for the corresponding component version in the component-vulnerability relationship table. If the result is not equal, issue a warning message; and

[0078] Determine if the license information for each component in the component table exists in the component and license relationship table. If the result is no, issue a warning message.

[0079] This application records the number of vulnerabilities corresponding to each component version in the component table, and compares the number of vulnerabilities with the number of data rows of the corresponding component version in the component and vulnerability relationship table for verification. If the two are not equal, it indicates that there is a problem, and a warning message will be issued, which helps to reduce the probability of problems in the collected data.

[0080] Specifically, after data cleaning, the methods also include:

[0081] Determine if the key fields of each component's data are empty. If the result is yes, issue a warning message. There are two scenarios: one is that the data definitely has a problem when it is empty (e.g., version release date, latest version), and the other is that the data may have a problem when it is empty (e.g., license abbreviation, recommended version).

[0082] Specifically, after data cleaning, the methods also include:

[0083] The cleaned data is verified using data from a pre-established and regularly maintained benchmark database. If the cleaned data contains data that is inconsistent with the data in the benchmark database, a warning message is issued to prompt manual intervention.

[0084] Specifically, the methods also include:

[0085] After the data cleaning phase is completed, the changes in the first set of data compared to the current cleaning phase are statistically analyzed, and the content of the cleaned data is sampled and checked.

[0086] After the cleaned data is upgraded, the change in the second data compared to the previous upgrade is statistically analyzed, and the content of the upgraded data is sampled and checked. The upgraded data sampled and checked are consistent with the cleaned data sampled and checked.

[0087] Determine whether the change in the second data is consistent with the change in the first data, and whether the content of the upgraded data after the sampling inspection is the same as the content of the cleaned data after the sampling inspection.

[0088] If the result is negative, a warning message will be issued.

[0089] Data upgrades involve writing cleaned data into the Elasticsearch cluster using different syntaxes, a process known to those skilled in the art, and will not be discussed in detail here.

[0090] By determining whether the change in the second data is consistent with the change in the first data, and whether the content of the upgraded data after sampling inspection is the same as the content of the cleaned data after sampling inspection, the upgrade result can be verified, and it can be basically determined whether the upgrade was completed correctly.

[0091] Specifically, this application periodically or when customers have doubts about the data, manually verify the data in the knowledge base. This mainly involves two aspects: first, verifying data relationships, such as component license relationships and component vulnerability relationships; and second, using benchmark database data to verify the integrity and correctness of the data. The benchmark database here can be a commonly used component benchmark database or a full database based on production line analysis.

[0092] As can be seen from the above, in the specific implementation of this application, the data of the open source component can be verified throughout the entire process, that is, data verification will be carried out in the data collection stage, data synchronization stage, data cleaning stage and data upgrade stage, which will help to obtain more accurate data.

[0093] Example 2

[0094] Please refer to Figure 2. This application discloses a data verification device for an open-source component, including:

[0095] The segmentation module 201 is used to divide the component data collected in the current data collection phase into required data and non-required data. The required data includes the component name and component release time in the component data, and the non-required data includes the component license information and component version information in the component data.

[0096] The determination module 202 is used to determine whether the required data in each component data has been collected in the current collection.

[0097] The recording and early warning module 203 is used to record the component data to the abnormal data storage device and perform the first-level early warning operation if the result is negative.

[0098] The recording and determination module 204 is used to record the component data to the normal data storage device if the result is yes, and to determine whether the component license information collected in the current time exists in the preset license library, whether the component version information collected in the current time exists in the preset version library, and whether the release time of the component collected in the current time conforms to the set format.

[0099] The marking and recording module 205 is used to mark the component in the normal data storage device's component table and record it in the abnormal data storage device and perform a second-level warning operation if the component license information collected in the current batch does not exist in the preset license library. The first level is higher than the second level. The preset license library is maintained according to the commonly used license sites. If the component version information collected in the current batch does not exist in the preset version library, it is marked in the normal data storage device's component table and recorded in the abnormal data storage device and perform a second-level warning operation. The preset version library is maintained according to the commonly used open source sites. If the release time of the component collected in the current batch does not conform to the set format, it is marked in the normal data storage device's component table and recorded in the abnormal data storage device and performs a second-level warning operation.

[0100] This application divides each piece of component data collected during the data acquisition phase into mandatory data and non-mandatory data. As long as the mandatory data can be collected in the current acquisition, regardless of the acquisition status of the non-mandatory data, the component data is recorded in the normal data storage device, so that it can proceed to the next stage of processing. This avoids the situation where the component data cannot proceed to the next stage of processing because the non-mandatory data is not collected or the collected data does not meet the requirements, thus effectively improving the rationality of local component data updates. Furthermore, assuming that the required data is collected in the current iteration, if the component license information collected in the current iteration does not exist in the preset license library, it will be marked in the component table of the normal data storage device and recorded in the abnormal data storage device for a second-level warning operation. If the component version information collected in the current iteration does not exist in the preset version library, it will be marked in the component table of the normal data storage device and recorded in the abnormal data storage device for a second-level warning operation. If the release time of the component collected in the current iteration does not conform to the set format, it will be marked in the component table of the normal data storage device and recorded in the abnormal data storage device for a second-level warning operation. In other words, if the collected non-required data does not meet the above requirements but does not affect the subsequent processing of the component data, this application can mark it in the component table of the normal data storage device and record it in the abnormal data storage device for a warning operation, which is convenient for reminding developers.

[0101] Example 3

[0102] Referring to Figure 3, this application discloses an electronic device, including:

[0103] Processor 30;

[0104] Memory 40, which stores executable instructions of processor 30;

[0105] The processor 30 is configured to execute the data verification method of the open-source component as described in Embodiment 1 by executing executable instructions.

[0106] Example 4

[0107] This application discloses a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements the data verification method of the open-source component as described in Embodiment 1.

[0108] Example 5

[0109] This application discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the data verification method of the aforementioned open-source component.

[0110] It should be understood that, in the embodiments of this application, the processor may be a central processing unit (CPU), but it may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0111] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by hardware related to computer program instructions. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0112] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0113] The above-disclosed examples are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall fall within the scope of this application.

Claims

1. A data verification method for an open-source component, characterized in that, include: The component data collected in the current data collection phase is divided into required data and optional data. The required data includes the component name and component release time, and the optional data includes the component license information and component version information. It is then determined whether the required data in each piece of component data was collected in the current data collection phase. If the result is negative, the data of the aforementioned component will be recorded in the abnormal data storage device and a first-level warning operation will be performed. If the result is yes, then the component data is recorded in the normal data storage device, and it is determined whether the component license information collected in the current time exists in the preset license library, whether the component version information collected in the current time exists in the preset version library, and whether the release time of the component collected in the current time conforms to the set format; if the component license information collected in the current time does not exist in the preset license library, then it is marked in the component table of the normal data storage device, and recorded in the abnormal data storage device and a second-level warning operation is performed, where the first level is higher than the second level; if the component version information collected in the current time does not exist in the preset version library, then it is marked in the component table of the normal data storage device, and recorded in the abnormal data storage device and a second-level warning operation is performed. If the release time of the component collected in the current instance does not conform to the set format, it is marked in the component table of the normal data storage device, and recorded in the abnormal data storage device, and the second level of early warning operation is performed.

2. The data verification method for open-source components as described in claim 1, characterized in that, The method further includes: each vulnerability data collected during the data acquisition phase has an association attribute, the association attribute being information about the components affected by the vulnerability and the range of component versions; determining whether the association attribute of each vulnerability data is empty, if the result is no, then the vulnerability data is recorded to a normal data storage device, if the result is yes, then the vulnerability data is recorded to an abnormal data storage device and a first-level warning operation is performed.

3. The data verification method for open-source components as described in claim 2, characterized in that, During the data synchronization phase, after synchronizing the data stored on the normal data storage device, a change comparison step is also included: comparing the change in the component data with a first upper limit threshold and a first lower limit threshold respectively; if the change in the component data is greater than the first upper limit threshold or less than the first lower limit threshold, a warning message is issued; comparing the change in the vulnerability data with a second upper limit threshold and a second lower limit threshold respectively; if the change in the vulnerability data is greater than the second upper limit threshold or less than the second lower limit threshold, a warning message is issued.

4. The data verification method for open-source components as described in claim 3, characterized in that, During the data cleaning phase, a component-vulnerability relationship table and a component-license relationship table are established while cleaning the synchronized data. The number of vulnerabilities corresponding to each component version is also recorded in the component table used to record the component data. After data cleaning, the method further includes: determining whether the number of vulnerabilities corresponding to each component version in the component table is equal to the number of data rows for the corresponding component version in the component-vulnerability relationship table; if the result is negative, a warning message is issued; and determining whether the license information for each component in the component table exists in the component-license relationship table; if the result is negative, a warning message is issued.

5. The data verification method for open-source components as described in claim 3 or 4, characterized in that, After data cleaning, the method further includes: determining whether the key fields of each piece of component data are empty, and issuing a warning message if the result is yes.

6. The data verification method for open-source components as described in claim 3, characterized in that, After data cleaning, the method further includes: verifying the cleaned data using data from a pre-established and regularly maintained benchmark database; and issuing a warning message if the cleaned data contains data inconsistent with the data in the benchmark database.

7. The data verification method for open-source components as described in claim 3, characterized in that, The method further includes: after data cleaning is completed in the data cleaning stage, calculating the first data change compared to before the current cleaning and sampling the content of the cleaned data; after the cleaned data is upgraded, calculating the second data change compared to before the current upgrade and sampling the content of the upgraded data, wherein the upgraded data sampled is consistent with the cleaned data sampled; determining whether the second data change and the first data change are consistent and whether the content of the upgraded data sampled is the same as the content of the cleaned data sampled; if the result is negative, issuing a warning message.

8. A data verification device for an open-source component, characterized in that, include: The segmentation module is used to divide the component data collected in the current data collection phase into required data and non-required data. The required data includes the component name and component release time in the component data, and the non-required data includes the component license information and component version information in the component data. The determination module is used to determine whether the required data in each piece of component data was collected in the current collection. The recording and early warning module is used to record the component data to the abnormal data storage device and perform a first-level early warning operation if the result is negative. The recording and determination module is used to record the component data to a normal data storage device if the result is yes, and to determine whether the component license information collected in the current time exists in a preset license library, whether the component version information collected in the current time exists in a preset version library, and whether the release time of the component collected in the current time conforms to a set format; the first marking and recording module is used to mark the component in the component table of the normal data storage device if the component license information collected in the current time does not exist in the preset license library, and to record it to an abnormal data storage device and perform a second-level warning operation, wherein the first level is higher than the second level, and the preset license library is maintained according to the commonly used license sites; The second marking and recording module is used to mark the component in the component table of the normal data storage device if the component version information collected in the current time does not exist in the preset version library, and to record it to the abnormal data storage device and perform a second-level warning operation. The preset version library is maintained according to a commonly used open source site. The third marking and recording module marks the component's release time in the normal data storage device's component table and the abnormal data storage device in the abnormal data storage device if the component's release time does not conform to the set format. It also performs a second-level warning operation.

9. An electronic device, characterized in that, include: A processor; a memory storing executable instructions of the processor; wherein the processor is configured to perform a data verification method of the open-source component according to any one of claims 1 to 7 by executing the executable instructions.

10. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed by the processor, it implements the data verification method of the open-source component as described in any one of claims 1 to 7.

Images