Method, device, storage medium and program product for security evaluation of financial applications

Abstract

This application provides a security assessment method, device, storage medium, and program product for financial applications, relating to the fintech field. The method includes: quantifying the raw security data of the financial application according to preset data quantification rules to obtain multiple security dimension indicators; obtaining a security profile score based on the business scenario type and the multiple security dimension indicators; performing code structure parsing processing on the code data in the raw security data to obtain a code structure representation, and obtaining vulnerability attribution relationships based on the code structure representation, vulnerability detection results, and business metadata; obtaining the business system type to which the financial application belongs, and determining the vulnerability remediation priority based on the vulnerability detection results and the business system type using preset priority determination rules; and generating and outputting a security assessment result based on the security profile score, vulnerability attribution relationships, and vulnerability remediation priority. This application improves the accuracy of financial application security assessment results.

Description

Technical Field

[0001] This application relates to the field of financial technology, and in particular to a security assessment method, device, storage medium, and program product for financial applications. Background Technology

[0002] With the online and platform-based transformation of financial services, applications in payment clearing, customer transactions, account management, and internal operations handle large amounts of sensitive data and high-frequency transaction requests. Their operational security is crucial not only for business continuity but also for user data protection and the efficiency of handling risk events. To ensure stable and secure application operation, regular security testing and risk assessments are typically conducted, and subsequent remediation plans and resource allocation strategies are developed based on the test results.

[0003] Existing security testing and assessment of financial applications typically rely on a specific type of testing data for analysis. For example, during the development or delivery phase, the analysis often uses a list of issues output by source code testing tools as input, identifying defects and generating test results based on preset rules. Alternatively, during the operation and maintenance phase, the analysis method uses operational data such as operation logs, alarm records, or security device interception records as the main input, filtering and correlating event records to output a summary of anomalies or risks.

[0004] However, when relying on a single-dimensional data source to form a judgment, the identification results of risk items are easily affected by the coverage and expression of that data source, leading to omissions or misjudgments of some risk items, making it difficult for the assessment conclusion to accurately reflect the actual risk status of financial applications. Summary of the Invention

[0005] This application provides a security assessment method, device, storage medium, and program product for financial applications to solve the technical problem of low accuracy in existing security assessments.

[0006] Firstly, this application provides a security assessment method for financial applications, including:

[0007] Obtain raw security data for financial applications, and quantify the raw security data according to preset data quantification rules to obtain multiple security dimension indicators;

[0008] Based on the business scenario type of the financial application and the multiple security dimension indicators, a security profile score for the financial application is obtained.

[0009] The code data in the original security data is parsed to obtain a code structure representation. Based on the code structure representation, the vulnerability detection results and business metadata in the original security data, the requirement items and corresponding code location information for each vulnerability are determined, and the vulnerability tracing relationship is obtained.

[0010] Obtain the business system type to which the financial application belongs, and determine the vulnerability remediation priority of each vulnerability based on the vulnerability detection results and the business system type using preset priority determination rules;

[0011] Based on the security profile score, the vulnerability attribution relationship, and the vulnerability remediation priority, a security assessment result is generated and output.

[0012] Secondly, this application provides a security assessment device for financial applications, comprising:

[0013] The data acquisition module is used to acquire the raw security data of financial applications and to quantify the raw security data according to preset data quantification rules to obtain multiple security dimension indicators.

[0014] The profile scoring module is used to obtain a security profile score for the financial application based on the business scenario type of the financial application and the multiple security dimension indicators.

[0015] The vulnerability analysis module is used to perform code structure parsing processing on the code data in the original security data, obtain the code structure representation, and determine the requirement items and corresponding code location information for each vulnerability based on the code structure representation, the vulnerability detection results and business metadata in the original security data, and obtain the vulnerability tracing relationship.

[0016] The vulnerability analysis module is also used to obtain the business system type to which the financial application belongs, and to determine the vulnerability remediation priority of each vulnerability based on the vulnerability detection results and the business system type, using preset priority determination rules.

[0017] The results output module is used to generate and output security assessment results based on the security profile score, the vulnerability attribution relationship, and the vulnerability remediation priority.

[0018] Thirdly, embodiments of this application provide an electronic device, a processor, and a memory communicatively connected to the processor;

[0019] The memory stores computer-executed instructions;

[0020] The processor executes computer execution instructions stored in the memory to implement the method described above.

[0021] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the above-described method.

[0022] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0023] This application provides a security assessment method, device, storage medium, and program product for financial applications. By acquiring the raw security data of financial applications and transforming detection and operational information from different sources into multiple comparable security dimension indicators according to preset quantitative rules, the input for security assessment is converted from discrete detection conclusions and descriptive information into a computable set of structured indicators. This provides a consistent quantitative basis for risk item identification and comprehensive judgment, reducing the probability of missed or incorrect assessments caused by inconsistent assessment criteria. Based on the quantitative indicators, a security profile score is further calculated by combining the business scenario type of the financial application. This allows the assessment conclusions to incorporate modulating factors of business scenario differences within the same quantitative framework, reducing bias caused by relying solely on general rules. The output score more stably reflects the overall risk status of the target application in its specific business scenario, improving the accuracy of the assessment conclusions in expressing the actual risk level. Simultaneously, code structure analysis is performed on the code data, and vulnerability attribution relationships are established by combining vulnerability detection results with business metadata. This forms a traceable link from risk items to business semantics, improving the interpretability and verifiability of the assessment conclusions. By obtaining the business system type and determining rules based on preset priorities to generate vulnerability remediation priorities, the output governance ranking no longer relies on the on-the-spot experience of the assessors, improving the consistency and stability of risk management recommendations. Integrating security profile scoring, vulnerability attribution relationships, and vulnerability remediation priorities to generate and output security assessment results enables the formation of actionable assessment conclusions and governance recommendations under a unified quantitative basis. This improves the overall accuracy of financial application security assessment results and reduces the impact of missed and false positives on subsequent governance decisions. Attached Figure Description

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

[0025] Figure 1 A flowchart illustrating the security assessment method for financial applications provided in this application embodiment;

[0026] Figure 2 This is a schematic flowchart of a method for updating scoring weight coefficients provided in an embodiment of this application;

[0027] Figure 3 A schematic flowchart illustrating the method for obtaining vulnerability detection results of financial applications provided in this application embodiment;

[0028] Figure 4 A schematic diagram of the structure of the security assessment device for financial applications provided in the embodiments of this application;

[0029] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0030] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0031] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0032] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0033] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0034] It should be noted that the security assessment method, device, storage medium and program product for financial applications provided in this application can be used in the field of financial technology, or in any field other than financial technology. The application field of the security assessment method, device, storage medium and program product for financial applications in this application is not limited.

[0035] The inventive concept of this application lies in transforming the security assessment of financial applications from relying on the output of single-dimensional detection data to a quantitative fusion and traceable correlation analysis based on multi-source raw security data. Specifically, by acquiring the raw security data of financial applications and performing unified quantitative processing according to preset data quantification rules, security information from different sources and with different structures is transformed into multiple calculable and comparable security dimension indicators. This ensures that the assessment input has a consistent quantitative caliber and a reproducible computational basis, providing a stable basis for subsequent comprehensive judgment. Based on the quantitative indicators, the business scenario type of the financial application is further introduced into the scoring generation, enabling the assessment conclusions to reflect differences in business context within a unified computational framework. A security profile score is formed through the comprehensive calculation of multiple security dimension indicators, quantitatively representing the overall risk status of the target application. This transforms the assessment results from a mere aggregation of single detection results into a holistic risk measure that can be stably compared across dimensions and time, improving the expressive power and consistency of the assessment conclusions in reflecting the actual risk status.

[0036] Meanwhile, to ensure that the assessment conclusions have interpretable business implications and verifiable code implications, this application performs code structure parsing processing on the code data in the original security data to obtain a code structure representation. Combined with vulnerability detection results and business metadata, it determines the corresponding requirement items and code location information for each vulnerability, forming a vulnerability attribution relationship. By establishing the correlation link between vulnerabilities and requirement items / code location information, the assessment process can provide the business semantics and implementation location basis while outputting risk items. Next, based on the vulnerability detection results, a preset priority determination rule is used to determine the vulnerability remediation priority of each vulnerability, enabling a deterministic quantitative ranking of the urgency of vulnerability handling under the constraints of technical severity and business attributes. Finally, the security profile score, vulnerability attribution relationship, and vulnerability remediation priority are integrated to generate and output the security assessment results. This output simultaneously covers the overall risk situation, the business and code location basis of key risk items, and an executable governance priority sequence, forming a closed-loop assessment mechanism from data quantification to risk expression to governance implementation. This improves the accuracy of the assessment results, reduces missed and false positives, and enhances the interpretability and enforceability of the assessment conclusions.

[0037] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0038] Figure 1 This is a flowchart illustrating the security assessment method for financial applications provided in this application embodiment. Figure 1 As shown, it includes:

[0039] S11: Obtain the raw security data of financial applications, and quantify the raw security data according to the preset data quantification rules to obtain multiple security dimension indicators.

[0040] In this embodiment, the raw security data refers to original records or outputs related to the security status of financial applications. Its sources cover application development, testing, deployment, and operation, and it reflects the objective status of the target financial application across different security dimensions. By uniformly collecting and formatting the raw security data, data from different sources and with different structures acquires an input format that can be stably read by subsequent processing modules, providing a consistent data foundation for subsequent quantification. Furthermore, the raw security data is quantified according to preset data quantification rules to convert descriptive and heterogeneous raw information into calculable and comparable numerical results. Data quantification rules constrain the processing scope and calculation methods of the raw security data, ensuring consistent quantification output for similar raw security data across different evaluation batches. For example, quantification processing includes operations such as field extraction, validity verification, noise filtering, scale unification, and numerical mapping of the raw security data to eliminate the impact of differences in data sources on the calculation results and ensure stable comparability of the quantification results within a preset value range. By uniformly quantifying the raw security data through preset data quantification rules, the security assessment is transformed from a descriptive analysis that relies on subjective judgment to an index-based calculation effect based on consistent criteria, thereby improving the stability and repeatability of subsequent security assessment conclusions.

[0041] After quantification, multiple security dimension indicators are obtained as multi-dimensional input variables to characterize the security status of the target financial application. Each security dimension indicator corresponds to a different aspect of the financial application's security risk. Each indicator is derived from its corresponding raw security data through quantification and independently reflects the risk level or health status of that aspect. By simultaneously acquiring multiple security dimension indicators, subsequent assessments can comprehensively consider the impact of different risk sources on the overall security status within the same quantitative framework, avoiding biases caused by relying solely on a single detection result or data source. By constructing a multi-dimensional set of security dimension indicators, a multi-faceted quantitative characterization of the target financial application's security status is achieved, providing data support for obtaining more accurate security assessment results.

[0042] S12: Based on the business scenario type of the financial application and multiple security dimension indicators, obtain the security profile score of the financial application.

[0043] In this embodiment, the business scenario type is used to identify the business attributes and risk context of the target financial application, reflecting the differences in data sensitivity, transaction risk, and the scope of business interruption impact among different financial businesses. By using the business scenario type and multiple security dimension indicators as scoring inputs, the security profile score not only reflects the objective risk level reflected by the security dimension indicators but also adapts the scoring results to the differences in business scenarios. Simultaneously, the business scenario type participates in the generation of the security profile score, ensuring that the scoring results are differentiated based on business differences. The business scenario type can trigger scenario-based modulation during the scoring process, enabling financial applications with different business scenario types to obtain differentiated security profile scores under the same security dimension indicators, making the scoring results closer to the risk-bearing capacity and risk exposure level of the target financial application in its business scenario. Through the joint analysis of business scenario type and multi-dimensional indicators, a dynamic characterization of the overall risk status of the financial application is achieved, which helps improve the accuracy of security assessment conclusions and reduce the impact of missed or incorrect judgments on the overall risk situation assessment.

[0044] S13, perform code structure parsing on the code data in the original security data to obtain the code structure representation, and determine the requirement items and corresponding code location information for each vulnerability based on the code structure representation, the vulnerability detection results in the original security data and business metadata, and obtain the vulnerability tracing relationship.

[0045] In this embodiment, the code data is a program representation that reflects the implementation logic of a financial application. Code structure parsing is used to extract structural information with stable semantic boundaries from the code data and organize this structural information into a searchable and locatable code structure representation. The code structure representation describes the organizational and relational relationships between code entities and establishes a correspondence between code entities and their code location information. This allows for the subsequent location of vulnerability-related code entities within the code structure representation based on their location information. By performing code structure parsing on the code data and constructing a code structure representation, the textual form of the code is transformed into a computable, structured representation, improving the accuracy of subsequent vulnerability location and correlation analysis.

[0046] Vulnerability detection results identify potential risks in the target financial application, while business metadata provides structured information about the application's business meaning and functional boundaries. By utilizing the vulnerability identifiers and associated code location information provided by the vulnerability detection results, the vulnerability-related code entities are located in the code structure representation. Combined with the business semantic mapping provided by the business metadata, the code entities containing the vulnerability are aligned with their respective business functional scope, further identifying the requirements corresponding to that business function. This process ensures that each vulnerability is not only located at its specific code location but also associated with its corresponding requirement, extending the process from vulnerability detection to locating the root cause of business requirements.

[0047] Furthermore, the vulnerability attribution relationship records the correspondence between vulnerabilities, requirements, and code location information in a structured manner, enabling subsequent assessment and remediation processes to be reviewed and traced based on the same attribution basis. The vulnerability attribution relationship includes at least the vulnerability's identifier, the requirement associated with that vulnerability, and the corresponding code location information. It can be used to support tracing the causes of vulnerabilities, defining the scope of remediation, and interpreting and verifying assessment results. By forming vulnerability attribution relationships, the location of risk items at the business semantic level and their precise positioning at the code level are determined, improving the verifiability and accuracy of security assessment conclusions and reducing omissions or misjudgments due to lack of context.

[0048] S14: Obtain the business system type to which the financial application belongs, and determine the vulnerability remediation priority of each vulnerability based on the vulnerability detection results and the business system type, using preset priority determination rules.

[0049] In this embodiment, by acquiring the business system type, vulnerability handling decisions no longer rely solely on the technical information reflected in vulnerability detection results, but can be constrained by the risk impact based on business system attributes, providing a business-dimensional basis for determining vulnerability remediation priorities. Furthermore, a preset priority determination rule is used to determine the vulnerability remediation priority for each vulnerability. The priority determination rule uses information reflecting the severity of the vulnerability in the vulnerability detection results as input, and combines this with the differences in business impact corresponding to different business system types to quantitatively differentiate the urgency of handling different vulnerabilities. By calculating vulnerability remediation priorities using the preset priority determination rule, vulnerabilities of the same type or severity can receive differentiated remediation priorities under different business system types, while also ensuring that vulnerability detection results from different sources form a comparable ranking basis under the same calculation caliber. Through the rule-based priority determination process, deviations caused by inconsistent handling judgments during the assessment process are reduced, improving the executability of security assessment conclusions.

[0050] S15 generates and outputs security assessment results based on security profile scores, vulnerability attribution relationships, and vulnerability remediation priorities.

[0051] In this embodiment, the security profile score is used to describe the overall security risk level of the target financial application, the vulnerability attribution relationship is used to provide a traceable association between vulnerabilities and requirement items and code location information, and the vulnerability remediation priority is used to quantitatively characterize the urgency of handling each vulnerability. By fusing the above three types of results as unified inputs, the output security assessment results not only include a quantitative characterization of the overall risk status of the application, but also the basis for locating and prioritizing key risk items. Through the fusion of multi-source assessment results, the integrity and consistency of the assessment output are achieved, improving the ability of the assessment conclusions to support actual governance decisions. Furthermore, the generation of security assessment results includes associating and organizing vulnerability attribution relationships and vulnerability remediation priorities to form structured output content that can be used for review and governance execution. By mapping the vulnerability remediation priority of each vulnerability to its corresponding requirement item and code location information, the assessment results can simultaneously express at the same item level what the priority object is and where the object is located at the business semantics and code implementation level, providing a clear basis for subsequent verification, reproduction, remediation, and regression checks, and improving the usability of the assessment results.

[0052] In one specific embodiment, the raw security data includes at least one of vulnerability detection results, application configuration data, dependency component data, and historical security event data.

[0053] Specifically, vulnerability detection results are the output information obtained after performing security tests on a target financial application. They typically include fields such as vulnerability entries, vulnerability identification information, affected objects and location information, and severity information. In practice, vulnerability detection results can come from the detection output of source code or build artifacts, or from the detection output of the runtime environment or interface interaction process, such as vulnerability reports output by static detection tools or penetration results output by dynamic detection tools.

[0054] Application configuration data represents the configuration status of a target financial application at the server, container, middleware, and application runtime parameter levels. This data can include network access control rules, permission configurations, encryption protocols and certificate activation status, and key security switches in the application configuration file, among other configuration snapshots or sets of configuration items. During data collection, application configuration data can be recorded at the configuration item level, including configuration keys, configuration values, configuration sources, collection time, and applicable environment. Configuration versions or change identifiers can also be retained to support subsequent comparisons.

[0055] Dependency component data is a list of third-party libraries, open-source components, and internal public components used by the target financial application, along with their version information. This data may include a Software Bill of Materials (SBOM), a build dependency list, component hashes or coordinates, and dependency import paths. In practice, dependency component data can be matched with a pre-defined vulnerability database to supplement component risk information, such as recording known vulnerability entries, affected version ranges, and vulnerability severity scores. Furthermore, dependency component data can retain the component's origin (repository, image, artifact repository) and release timestamp to identify new issues arising from version drift.

[0056] Historical security incident data consists of records of security events related to the target financial application within a preset time window. These records can originate from archived information such as production environment security event logs, security device interception records, past vulnerability patching records, or security test reports from version iterations. During collection, historical security incident data can record elements such as event occurrence time, event type, event severity, scope of impact, handling conclusions, and associated objects, and can retain association identifiers between events and application versions, interfaces, or functional modules to support traceability.

[0057] Furthermore, security metrics include code security metrics, dependent component security metrics, configuration security metrics, or historical event metrics.

[0058] Specifically, the code security metric represents the risk level of the target financial application at the code implementation level. It is a quantitative output based on vulnerability entries related to the code in vulnerability detection results, reflecting the comprehensive impact of code defects in terms of type and severity. The dependent component security metric represents the risk level of third-party components relied upon by the target financial application. It is a quantitative output based on the matching results of dependent component data and a pre-set vulnerability database, reflecting the quantity and severity characteristics of component vulnerabilities. The configuration security metric represents the security status of the target financial application at the deployment and operational configuration level. It is a quantitative output based on application configuration data, reflecting the degree to which configuration items meet pre-set compliance benchmarks. The historical event metric represents the intensity of security exposure and handling feedback of the target financial application within a pre-set time window. It is a quantitative output based on historical security event data, reflecting the comprehensive impact of event frequency and severity.

[0059] Next, based on the above embodiments, the original security data is quantified according to preset data quantization rules to obtain multiple security dimension indicators, including:

[0060] S111: Based on the vulnerability detection results, extract multiple vulnerability entries, and obtain code security indicators according to the vulnerability level corresponding to each vulnerability entry and the preset level weight coefficient corresponding to the vulnerability level.

[0061] Specifically, each vulnerability entry in the vulnerability detection results is considered the smallest record unit of risk to the target financial application's code implementation level. Each vulnerability entry carries at least information uniquely identifying it and information indicating its vulnerability level. The vulnerability level represents the relative severity of the vulnerability's impact on security. It can be directly given by the vulnerability detection results or determined by the vulnerability type, triggering conditions, and impact scope in the results according to preset mapping rules, and corresponds one-to-one with preset level weighting coefficients. These preset level weighting coefficients represent the contribution of different vulnerability levels to the code security index, allowing the code security index to reflect the greater impact of higher-level vulnerabilities on the index under the same calculation caliber. In the specific quantitative processing, each vulnerability entry is matched with a preset level weighting coefficient according to its vulnerability level, and the matching results are weighted, summarized, and scaled to obtain the index value of the code security index. For example, the vulnerability detection results can include code vulnerability entries output by static detection tools or reproducible vulnerability entries output by dynamic detection tools, thereby forming a calculable quantitative result for the code security index. By applying consistent weighting to vulnerability entries based on their vulnerability level and preset weighting coefficients, discrete vulnerability entries are transformed into stable and comparable code security indicators. This provides a unified quantitative basis for subsequent comprehensive assessments and reduces the probability of missed or incorrect assessments.

[0062] S112, Match the dependent component data with the preset vulnerability database to obtain the number of dependent component vulnerabilities and the vulnerability severity score corresponding to each dependent component vulnerability, and obtain the security indicators of the dependent components based on the number of dependent component vulnerabilities and the vulnerability severity score corresponding to each dependent component vulnerability.

[0063] Specifically, for each dependent component in the dependent component data, its component identifier and version information are extracted and compared with the affected component information in a pre-defined vulnerability database to determine whether the dependent component corresponds to a known vulnerability and the corresponding set of vulnerability entries. The pre-defined vulnerability database provides reference information on dependent component vulnerabilities and includes at least fields such as vulnerability identifier, affected version range, and vulnerability severity score. The vulnerability severity score is a numerical representation of the vulnerability's severity and can be directly taken from the score field in the vulnerability database. After matching, the number of dependent component vulnerabilities is counted, and the vulnerability severity score corresponding to each dependent component vulnerability is extracted. When calculating the dependent component security index, the number of dependent component vulnerabilities and the vulnerability severity score corresponding to each dependent component vulnerability are used to form a comprehensive quantitative result. For example, the vulnerability severity scores are aggregated and combined with the number of dependent component vulnerabilities, and then mapped to the dependent component security index according to a pre-defined scale. For example, the total number of dependent component vulnerabilities × the average CVSS score, and then normalized to a value between 0 and 100. In summary, by jointly quantifying the risks of dependent components in terms of both quantity and severity scores, the security indicators of dependent components can stably reflect the intensity of risks on the dependent side and support the accuracy of subsequent profiling and scoring.

[0064] S113: Extract multiple configuration items based on application configuration data, and determine the compliance of multiple configuration items according to preset compliance benchmarks to obtain the configuration item compliance rate, and generate configuration security indicators based on the configuration item compliance rate.

[0065] Specifically, configuration items refer to the security-related settings of the target financial application at the host, container, middleware, or application parameter level, and may include information such as configuration keys, configuration values, configuration sources, and collection times. Multiple configuration items are assessed for compliance based on preset compliance benchmarks. These benchmarks define the expected states and judgment conditions that configuration items should meet at the security level, and can be represented as an executable set of rules or thresholds. After each configuration item's compliance is assessed, the number of configuration items conforming to the preset compliance benchmarks and the total number of configuration items are counted to calculate the configuration item compliance rate, which is then used to generate a configuration security indicator. In practice, the configuration item compliance rate can be converted into a configuration security indicator value using a preset method to ensure that the configuration security indicator can be comprehensively calculated with other security dimension indicators under a unified scale. For example, the configuration item compliance rate (e.g., the proportion conforming to the CIS benchmark) × 100 yields the configuration security indicator. By performing consistency assessments on configuration items based on preset compliance benchmarks and outputting the configuration item compliance rate, the configuration verification results are quantified into configuration security indicators, reducing evaluation bias caused by inconsistencies in the expression of configuration inspection results.

[0066] S114. Based on the historical security event data within the preset time window, obtain the number of historical security events and the event level coefficient corresponding to each historical security event. Calculate and obtain historical event indicators based on the number of historical security events and the event level coefficient corresponding to each historical security event.

[0067] Specifically, historical security event data is filtered and aggregated within a preset time window to obtain the number of historical security events. The preset time window is used to limit the effective range of historical signals to avoid unreasonable influence of outdated events on the current assessment. Subsequently, a corresponding event level coefficient is obtained for each historical security event. The event level coefficient is used to reflect the contribution intensity of different levels of events to the risk situation. It can be directly mapped from the event level and can reflect the greater impact of higher-level events on historical event indicators. In the quantitative calculation, a weighted calculation result is formed based on the number of historical security events and the corresponding event level coefficient to obtain the indicator value of the historical event indicator. For example, each historical security event is weighted and summarized according to the event level coefficient and mapped to a historical event indicator according to a preset scale. The number of security events in the past year × the event severity level coefficient (e.g., high-risk event = 10 points / event) transforms historical security event data into a weighted historical event indicator, realizing the quantitative expression of risk exposure and handling feedback during the operation period. This allows the assessment results to be calibrated using historical signals, improving the ability to reflect the actual risk status and reducing the impact of missed or misjudged cases on the overall judgment.

[0068] In one embodiment, the security profile score of the financial application obtained in step S12 above will be further explained. Based on the above embodiment, it includes:

[0069] S121. Based on the business metadata of the financial application, determine the business scenario type of the financial application and query and obtain the business threat coefficient corresponding to the business scenario type.

[0070] Specifically, business identification information in business metadata is used to categorize the business attributes of the target financial application to determine its business scenario type. Business metadata is a structured collection of information related to the business meaning of the financial application, containing at least fields that indicate business boundaries or labels, such as business category markers reflected by application registration information, interface definition documents, or functional module division information. The business scenario type represents the risk level difference within the financial business context of the target financial application and serves as contextualized input for subsequent profiling and scoring. After determining the business scenario type, a preset business threat coefficient mapping relationship is queried to obtain the business threat coefficient. The business threat coefficient is a preset coefficient corresponding to the business scenario type, used to reflect the differences in risk tolerance of different business scenarios in dimensions such as regulatory requirements, scope of business interruption impact, and data sensitivity. For example, the business threat coefficient can be set to a higher coefficient for payment or clearing scenarios and a relatively lower coefficient for internal operation scenarios. For instance, the threat coefficient for a payment / clearing system is 1.5, the threat coefficient for a customer transaction system is 1.2, and the threat coefficient for an internal management system is 0.8. By determining the business scenario type based on business metadata and introducing a business threat coefficient, the subsequent scoring results can reflect the risk differences of business scenarios under the same security dimension indicator input, thereby improving the accuracy of the scoring in expressing the actual risk status.

[0071] S122: Obtain code security metrics, dependent component security metrics, configuration security metrics, and historical event metrics, and calculate a comprehensive score by weighting the code security metrics, dependent component security metrics, configuration security metrics, and historical event metrics according to preset scoring weight coefficients.

[0072] Specifically, preset scoring weight coefficients are used to limit the contribution ratio of each security dimension indicator in the comprehensive score, reducing the unreasonable impact of a certain dimension on the evaluation result due to differences in indicator dimensions or information coverage. These preset scoring weight coefficients can be pre-configured and maintained consistently during evaluation calculations, ensuring comparability of evaluation results across different batches. In implementation, code security indicators, dependent component security indicators, configuration security indicators, and historical event indicators are multiplied by their corresponding preset scoring weight coefficients and then summed or equivalently weighted to obtain the comprehensive score. Each security dimension indicator can be within the same preset value range before entering the weighted calculation to ensure the weighted result is interpretable and comparable. By weighting and fusing multi-dimensional security states within the same calculation framework, a structured and comprehensive expression of the overall risk posture of the target financial application is achieved, reducing the risk of missed or incorrect judgments caused by relying solely on a single detection output to form an evaluation conclusion.

[0073] S123, based on the comprehensive score and business threat coefficient, obtains a security profile score for financial applications.

[0074] Specifically, the security profile score is a rating result used to quantitatively characterize the overall security risk status of a target financial application. It is generated from a comprehensive score under the constraint of a business threat coefficient, enabling applications in different business scenarios to generate more differentiated profile scores under the same comprehensive score conditions. In specific implementation, the business threat coefficient can be used to normalize or scale the comprehensive score to obtain the security profile score. For example, the comprehensive score and the business threat coefficient can be combined in a preset manner to form the final score. This calculation method ensures that business scenarios with higher business threat coefficients reflect stricter risk expression in the score output, making the score closer to the governance requirements of high-risk business scenarios. For example, the security profile score = (0.4 × code security + 0.3 × dependency vulnerabilities + 0.2 × configuration security + 0.1 × historical events) / business threat coefficient. By using the business threat coefficient to modulate the comprehensive score in a scenario-based manner, the security profile score achieves an adaptive expression of business differences, improving the stability and accuracy of the assessment results and reducing missed or incorrect judgments caused by the failure to quantify differences in business context.

[0075] In one embodiment, the raw security data also includes code data and business metadata. Code data represents the implementation logic and program structure of the target financial application, and may include source code files, compiled binary files, and code artifact information related to the construction process. This enables subsequent code structure parsing and processing based on the code data to form a code structure representation. The collection of code data can cover the core business modules and supporting infrastructure implementation of the financial application to ensure sufficient coverage of the security assessment at the code level. The core business modules may include business logic implementations such as payment clearing, transaction processing, and risk control verification. Business metadata is the structured descriptive information of the target financial application at the business level. It includes at least identification information that indicates business boundaries, functional organization, and requirement associations to support the alignment of technical detection results with business semantics. Business metadata may include requirement document identification information, interface definition information, functional module division information, and descriptive information related to compliance or regulation. It may further include business tags or business category information to characterize the application's business attributes, supporting the subsequent determination of business scenario types and business system types. Business metadata can be extracted from the requirements management system, interface management platform, application registration information or version delivery documents during collection, and formed into a searchable mapping relationship in a structured manner.

[0076] In one embodiment, the acquisition of vulnerability attribution relationships in step S13 is provided, and an implementation method is offered here. Based on the above embodiment, it includes:

[0077] S131, perform abstract syntax tree parsing on the code data, establish the correspondence between syntax nodes and code location information, and obtain the code structure representation.

[0078] Specifically, Abstract Syntax Tree (AST) parsing transforms code data from text to a semantically hierarchical structure, enabling syntactic elements in the code to be structurally represented as nodes. The mapping between syntactic nodes and code location information maps each syntactic node to its specific location within the code data. Code location information includes at least a file identifier and its location within the file, allowing subsequent location of the corresponding syntactic node within the code structure representation. Based on this, the code structure representation forms a searchable data structure, which includes at least a set of syntactic nodes, hierarchical relationships between nodes, and index relationships from nodes to code location information. By constructing a structured representation at the syntactic node level through AST parsing, a precise positioning foundation is provided for vulnerability localization and business correlation analysis, improving the repeatability and accuracy of vulnerability identification.

[0079] S132, based on the code structure representation, identify the annotation information corresponding to the financial business, and determine the business processing function according to the annotation information.

[0080] Specifically, annotation information is used to identify business semantic boundaries or business processing entry points at the code level, enabling business-related program fragments to be filtered and aggregated from the general code structure. Annotation identification is based on the type characteristics and meta-information features of syntax nodes in the code structure representation, and a relationship is established between the identified annotation information and its corresponding syntax nodes. Based on this, the business processing function is determined, allowing subsequent call relationship analysis to converge its analysis scope from the business processing function, reducing noise introduction caused by indiscriminate expansion of the entire code. By identifying annotation information and determining business processing functions, the code structure representation is aligned with financial business semantics, providing business anchors for subsequent extraction of call chains and / or data flow paths related to fund flows, improving the relevance and interpretability of the tracing chain.

[0081] S133, based on the call relationship of business processing functions, obtain the call chain and / or data flow path associated with the cash flow.

[0082] Specifically, the call relationship represents the association between a business processing function and other functions it calls; the call chain describes the sequence of functions extending from the business processing function along the call relationship; and the data flow path describes the transmission trajectory of key data between variables, parameters, and return values ​​during business processing. The call chain and / or data flow path associated with fund flows characterize the implementation path of fund processing logic at the code level in financial business, enabling subsequent focus on key nodes related to fund processing. In specific implementations, data objects related to fund processing can be identified in the code structure representation based on reference relationships, parameter passing relationships, or assignment relationships between syntax nodes, and the transmission of these objects between functions forms a data flow path. Simultaneously, the call chain can be traced downwards along the call relationship of the business processing function, and nodes related to fund processing can be filtered within the call chain. By extracting the call chain and / or data flow path associated with fund flows from the business processing function, a structured characterization of the key risk-bearing path in financial business is achieved. This provides operable path-level objects for subsequent association annotation based on regulatory requirements, improving the ability to identify high-risk semantic locations.

[0083] S134. Based on the regulatory requirements information in the business metadata, associate and annotate the call chain and / or data flow path to update the code structure representation.

[0084] Specifically, regulatory requirement information is used to represent the constraints and concerns of financial businesses at the compliance and regulatory levels, and it can be correlated with business functions, interfaces, or processing flows. Association annotation is used to map regulatory requirement information to nodes in the call chain and / or data flow path, adding regulatory semantic attributes to the original syntax and call structure of the code structure representation, forming an enhanced code structure representation that can simultaneously express code structure, business processing path, and regulatory constraints. This update process can record information such as regulatory requirement identifiers, constraint categories, or compliance tags for corresponding syntax nodes or path nodes in the code structure representation, enabling subsequent vulnerability localization and requirement item association to prioritize critical paths and nodes subject to regulatory constraints. By introducing regulatory requirement information to associate and annotate the call chain and / or data flow path, compliance semantics are integrated into the code structure representation, improving the ability of source tracing analysis to focus on key risk points in financial scenarios and reducing the possibility of misjudging non-critical code as high-risk.

[0085] S135. Based on the vulnerability detection results, obtain the vulnerability identifier of each vulnerability and its corresponding code location information, and locate the syntax node corresponding to the code location information in the code structure representation.

[0086] Specifically, vulnerability identifiers uniquely characterize vulnerability entries, while code location information indicates the scope of the vulnerability's location within the code data. By matching the code location information in the vulnerability detection results with the code location information index of syntax nodes, the syntax node corresponding to the vulnerability's location can be located in the code structure representation. Furthermore, the structural context information of this syntax node in the code structure representation can be obtained, such as its associated function, the call chain position of its associated business processing function, or the position of its associated data flow path. This location process transforms the vulnerability from a detection output entry into a structural node that can be referenced in the code structure representation, providing a stable object for subsequent extraction of business function identifiers and association with requirement item identifiers. Locating syntax nodes in the code structure representation achieves structured and contextualized vulnerability location, enhancing the interpretability of vulnerability judgment and tracing, and reducing missed or false positives caused by location bias.

[0087] S136. Based on the interface definition information and / or functional module division information in the business metadata, obtain the business function identifier corresponding to the syntax node, and determine the requirement item identifier corresponding to the business function identifier based on the association information between the business function identifier and the requirement item identifier.

[0088] Specifically, interface definition information and functional module division information provide the basis for mapping between business function boundaries and technical implementation units. The business function identifier uniquely identifies the business function and can be determined through the correspondence between the interface implementation, module boundary, or business processing function to which the syntax node belongs and the interface definition information. When a syntax node corresponds to interface definition information, the business function identifier can be obtained directly; when a syntax node corresponds to a module boundary, the business function identifier can be obtained based on the functional module division information. Subsequently, the requirement item identifier corresponding to the business function identifier is determined based on the association information between the business function identifier and the requirement item identifier. This association information describes the correspondence between the business function identifier and the requirement item identifier and can be included in the business metadata to form a structured mapping record, allowing the mapping from business function identifier to requirement item identifier to be directly queried. By utilizing interface definition information and / or functional module division information to establish a mapping from syntax nodes to business function identifiers, and further mapping to requirement item identifiers, semantic continuity from code structure nodes to requirement item identifiers is achieved. This enables vulnerabilities to be traced back to their corresponding requirement item level, improving the ability of the tracing results to support the root cause location of problems.

[0089] S137 generates and records vulnerability attribution relationships based on the vulnerability identifier, requirement item identifier, and code location information of each vulnerability.

[0090] Specifically, the vulnerability attribution relationship is structured to solidify the correspondence between vulnerabilities, requirement identifiers, and code location information. This enables subsequent security assessments and remediation processes to verify and trace the business and code endpoints of vulnerabilities. The vulnerability attribution relationship record can include persistent storage of the set of requirement identifiers and code location information associated with each vulnerability identifier. It can also supplement this with syntax node reference information for the vulnerability in the code structure representation, supporting further analysis and visualization based on the code structure representation. By generating and recording vulnerability attribution relationships, the assessment results have clear business and code location bases when output, reducing misjudgments due to a lack of contextual information and lowering the cost of reviewing missed detections caused by unclear location.

[0091] In one embodiment, step S14 is further explained below. Based on the above embodiment, determining the vulnerability remediation priority for each vulnerability includes:

[0092] S141. Based on business metadata, determine the business system type of the financial application; among which, the business system type includes core systems, customer systems, and internal systems.

[0093] Specifically, the business system type indicates the criticality and risk impact of a financial application within the business system. It includes core systems, customer systems, and internal systems. Core systems are those involved in critical transaction links such as fund clearing and core accounting; customer systems are those for customer-facing transactions, inquiries, or service interactions; and internal systems are back-end management, operational support, or reporting systems. The determination of the business system type can be based on a comprehensive assessment of system business tags, functional module division information, interface definition information, and identification information related to business links within the business metadata. This ensures that the same financial application, across different versions or deployment configurations, can generate a stable business system type output based on consistent data standards. Utilizing business metadata to determine the business system type provides a business-side constraint for the order of vulnerability handling.

[0094] S142, Based on the business system type, query the preset business impact factor mapping table to obtain the business impact factor.

[0095] Specifically, a pre-defined business impact factor mapping table is used to solidify the correspondence between business system types and business impact factors, enabling different business system types to be mapped into quantifiable parameters that can be used in calculations with a unified standard. The business impact factor represents the intensity of the impact of a business system type on the urgency of vulnerability risk handling. Its value can be configured according to preset rules and maintained in a version-based management system to ensure consistency in calculation across different assessment batches. For example, the business impact factor can be configured with a higher value for core systems, a medium value for customer systems, and a lower value for internal systems, reflecting the differences in financial risk, scope of business interruption impact, and consequences of sensitive data exposure among different system types. By mapping business system types to business impact factors, the differences on the business side are transformed into quantifiable parameters, reducing fluctuations caused by differences in human interpretation during the priority determination process.

[0096] For example, the business impact factor of the core system is 1.0, which is determined by its involvement in fund clearing and core accounting; the business impact factor of the customer system is 0.7, which is determined by its involvement in customer-facing transaction / query functions; and the business impact factor of the internal system is 0.3, which is determined by its involvement in back-end management and reporting functions.

[0097] S143: Obtain the vulnerability identifier of each vulnerability based on the vulnerability detection results, and query the preset vulnerability database based on the vulnerability identifier to obtain the vulnerability severity score corresponding to each vulnerability.

[0098] Specifically, each vulnerability entry in the vulnerability detection results is extracted with a vulnerability identifier, which is used to uniquely identify the vulnerability and support cross-data source association. The vulnerability identifier can be a form of identifier that can be retrieved from a vulnerability database, enabling subsequent authoritative or quasi-authoritative scoring information related to the severity of the vulnerability to be obtained through this identifier. A pre-defined vulnerability database is used to provide the correspondence between vulnerability identifiers and vulnerability severity scores. It can contain structured records such as the scope of vulnerability impact, version information, and scoring fields, ensuring that the query process can reliably return the vulnerability severity score corresponding to the vulnerability identifier. The vulnerability severity score is used to numerically express the severity of the vulnerability, enabling subsequent priority calculations to compare different vulnerabilities on a uniform scale. By associating the vulnerability identifiers in the vulnerability detection results with the pre-defined vulnerability database to obtain the vulnerability severity score, a unified source of vulnerability severity quantification is achieved, providing comparable severity input for subsequent calculations of vulnerability remediation priorities.

[0099] S144: Calculate the vulnerability remediation priority for each vulnerability based on the vulnerability severity score and business impact factor.

[0100] Specifically, vulnerability severity scores and business impact factors are combined and calculated under preset priority determination rules to output vulnerability remediation priorities that characterize the urgency of handling. The priority determination rules define the contribution of vulnerability severity scores to the technical risk side and the moderating effect of business impact factors on the business impact side, enabling the same vulnerability to exhibit differentiated remediation priorities across different business system types, while simultaneously providing a stable and comparable ranking basis for different vulnerabilities within the same business system type. In practice, vulnerability remediation priorities are obtained from vulnerability severity scores and business impact factors according to preset calculation methods, integrating the severity of the vulnerability and the importance of the business system within the same quantitative framework. For example, the remediation priority is obtained by multiplying the CVSS score by the business impact factor (BIF). For instance, a SQL injection vulnerability (CVSS 9.8) in a card repayment function (customer system) would have a priority of 9.8 × 0.7 = 6.86. By combining vulnerability severity scores and business impact factors in a rule-based manner to generate vulnerability remediation priorities, the stability and consistency of the priority results are improved, and support is provided for reducing the bias in assessment conclusions and minimizing the impact of missed or incorrect assessments on governance decisions.

[0101] In one embodiment, step S15 is implemented as follows: Based on the above embodiment, a security assessment result is generated and output according to the security profile score, vulnerability attribution relationship, and vulnerability remediation priority, including:

[0102] S151, based on the vulnerability attribution relationship, obtain the corresponding requirements and code location information for each vulnerability.

[0103] Specifically, vulnerability attribution relationships are parsed and retrieved as structured traceability records to extract the business and code location information corresponding to each vulnerability. This acquisition process uses the vulnerability identifier recorded in the vulnerability attribution relationship as an index to read the requirement items and code location information associated with that vulnerability identifier, maintaining the correspondence between the two. In cases where one vulnerability corresponds to multiple requirement items or multiple code location information, the acquisition process retains the many-to-many association results and consistently extracts and records the requirement item identifiers within the requirement items, ensuring that subsequent governance entries can stably reference the same identifier system. By extracting requirement items and code location information from the vulnerability attribution relationship, the assessment output achieves the effect of traceable business root causes and locatable code location, improving the verifiability of security assessment results and reducing misjudgments caused by a lack of context.

[0104] S152 associates vulnerability remediation priorities, corresponding requirements for each vulnerability, and code location information to generate a set of governance entries containing vulnerability identifiers, requirement identifiers, code location information, and vulnerability remediation priorities.

[0105] Specifically, vulnerability identifiers are used as the association key to merge assessment results from different sources, forming itemized outputs for governance execution. Specifically, vulnerability remediation priorities are matched with vulnerability identifiers in the vulnerability attribution relationship, ensuring that the urgency of each vulnerability's handling is aggregated and presented in the same governance item along with its business and code implementation points. Simultaneously, requirement item identifiers and corresponding code location information from requirement items are written into the governance items, ensuring that each governance item includes at least a vulnerability identifier, requirement item identifier, code location information, and vulnerability remediation priority. This guarantees that the item expresses both "what to fix first" and "where to fix it, corresponding to which requirement item." When generating the governance item set, field completeness is validated to ensure that vulnerability identifiers uniquely identify the item subject, requirement item identifiers support business-side tracing, code location information supports R&D-side positioning, and vulnerability remediation priorities have comparable ranking significance. This fusion of attributes to form the governance item set reduces the handling bias caused by information fragmentation during the implementation phase of assessment conclusions.

[0106] S153, based on vulnerability remediation priority, sorts each governance item in the governance item set to obtain a governance list.

[0107] Specifically, the sorting process deterministically rearranges the set of governance items under a preset sorting criterion to form a priority sequence that can be directly used for governance advancement. Governance items are sorted primarily based on vulnerability remediation priority, ensuring that governance items with higher urgency are presented first. When multiple governance items have the same or similar vulnerability remediation priorities, the sorting process maintains a stable deterministic output, ensuring a reproducible presentation order for the same batch of governance items across different assessment batches. By generating a governance list based on vulnerability remediation priority, the output directly supports resource allocation and governance scheduling, reducing the risk of inconsistencies caused by secondary manual assessment.

[0108] S154 generates risk profile information for the target application based on the security profile score, and outputs the risk profile information and governance list through a visual decision dashboard to complete the output of the security assessment results.

[0109] Specifically, the security profile score, as a quantitative result of overall risk, is used to form a structured information set oriented towards situational awareness, enabling the assessment output to present the overall risk status of the target application from a macro perspective. The risk situational information at least reflects the security profile score itself and its corresponding assessment timeframe, and can be further combined with the calculation caliber of the security profile score to form an interpretable situational expression. This allows the risk situational information to be used for comparative presentation across time windows or versions, supporting the identification and verification of risk change trends. By converting the security profile score into risk situational information, the effect of transforming a single scoring result into a situational expression that can be used for understanding and verification of governance decisions is achieved, improving the explanatory power of the security assessment results in terms of the overall risk status.

[0110] When outputting risk situation information and governance lists through a visual decision dashboard to complete the security assessment results, the dashboard serves as the display medium for the output, uniformly organizing and presenting the risk situation information and governance lists. This ensures a correspondence between macro-level risk status and micro-level governance items on the same output interface. During the output of the visual decision dashboard, the risk situation information presents the overall risk level of the target application, while the governance list presents the vulnerability items requiring action and their remediation priorities. The governance items also include requirement identifiers and code location information to support rapid location and review, enabling the assessment output to simultaneously meet the management's need to grasp the risk situation and the execution side's need for effective location and remediation. By integrating risk situation information and governance lists into the visual decision dashboard, the security assessment results achieve interpretability, traceability, and enforceability, reducing the impact of incomplete assessment information leading to omissions or misjudgments, and enhancing the support capability of the security assessment results for subsequent governance work.

[0111] Figure 2 This is a schematic flowchart illustrating a method for updating scoring weight coefficients provided in an embodiment of this application. Based on the above embodiments, as follows... Figure 2 As shown, it includes:

[0112] S21. Obtain historical governance data within a preset update cycle. The historical governance data includes at least one of the following: vulnerability remediation records, historical security event impact data, and false positive or false negative statistics.

[0113] Specifically, vulnerability remediation records represent the vulnerability entries that have been addressed and their resolution results within the governance closed loop; historical security incident impact data represents the consequences of security incidents in the actual operating environment; and false positive or false negative statistics represent the statistical results of risk item judgment biases during the assessment process. A preset update cycle limits the pace and sample range of parameter updates, enabling the scoring weight coefficients to be updated at a stable frequency, such as by quarterly aggregation of historical governance data. By acquiring historical governance data within the preset update cycle, real governance feedback is incorporated into the optimization of scoring model parameters, providing quantifiable monitoring evidence to improve assessment accuracy.

[0114] S22, obtain code security metrics, dependent component security metrics, configuration security metrics, and historical event metrics corresponding to multiple time periods within a preset update cycle.

[0115] Specifically, the security status of target financial applications within each time period is compiled into a comparable multi-dimensional indicator sequence using a unified standard. Multiple time periods are used to reflect the differences in security posture at different stages, enabling subsequent regression analysis to fit the relationship between indicator changes over time and their impact. Each security dimension indicator is generated according to predetermined data quantification rules within each time period to ensure consistent scale and comparability of the same dimension across different time periods. By constructing a multi-time period security dimension indicator sequence, the stability and generalization ability of the scoring weight coefficient updates are improved.

[0116] S23. Based on historical security incident impact data, determine security impact values ​​corresponding to multiple time periods; wherein, the security impact values ​​include at least one of downtime and financial loss.

[0117] Specifically, quantifiable consequences from historical security incident impact data are extracted as security impact values, which serve as target variables in the training dataset. Security impact values ​​include at least one of downtime and financial loss, used to characterize the actual intensity of the security incident's impact from the perspective of business continuity and business loss. When historical security incident impact data covers multiple incidents or multiple system versions, security impact values ​​are aggregated by time period, so that each time period corresponds to an impact metric matching its security posture. By transforming historical security incident impact data into security impact values, the actual consequences are incorporated into the parameter optimization objective, ensuring that the update direction of the scoring weight coefficients is consistent with the actual risk cost, thereby improving the accuracy of the security profile score in expressing the actual risk status from a mechanistic perspective.

[0118] S24. Associate and match the code security metrics, dependent component security metrics, configuration security metrics, historical event metrics, and corresponding security impact values ​​for the time period to generate sample records, and construct a training dataset from multiple sample records.

[0119] Specifically, multidimensional indicators and safety impact values ​​are aligned using time periods as the association key to form structured samples for training. Each sample record contains at least four safety dimension indicators within the same time period and their corresponding safety impact values ​​for that period, maintaining field consistency and integrity to ensure stable reading for subsequent regression analysis. Multiple sample records are further used to construct the training dataset. By associating and matching multidimensional indicators and safety impact values ​​along the time dimension, a computable mapping between safety status representation and actual impact consequences is established, providing a data foundation for obtaining scoring weight coefficients that more accurately reflect actual risks.

[0120] S25. Perform regression analysis on the training dataset to obtain the candidate score weight coefficients.

[0121] Specifically, regression analysis is used to learn the functional relationship between security dimension indicators and security impact values ​​in the training dataset, and outputs candidate score weight coefficients that reflect the contribution of each security dimension indicator. Regression analysis is a statistical learning method that fits the relationship between input variables and a target variable. It uses code security indicators, dependent component security indicators, configuration security indicators, and historical event indicators as input variables, and security impact values ​​as the target variable. By minimizing the fitting error, candidate score weight coefficients are obtained, enabling them to reflect the relative contribution of different security dimensions to the security impact value. Obtaining candidate score weight coefficients through regression analysis shifts the optimization of score weight coefficients from empirical setting to data-driven optimization, improving assessment accuracy.

[0122] S26, normalize the candidate scoring weight coefficients and update the normalized scoring weight coefficients to the preset scoring weight coefficients.

[0123] Specifically, normalization is used to adjust the candidate scoring weight coefficients to a set of weights that meet preset constraints, ensuring that the updated preset scoring weight coefficients remain stable in both numerical scale and interpretation. Normalization can scale the candidate scoring weight coefficients proportionally to ensure that the sum of the weights is a preset value, preventing overall weight drift that could lead to instability in the security profile scoring scale. After the update, the preset scoring weight coefficients take effect directly in subsequent security profile scoring calculations and remain consistent until the next preset update cycle. Through the normalization and update mechanism, controllable iteration of the scoring weight coefficients is achieved, enabling the scoring model to be periodically optimized based on continuously incorporating historical governance feedback, thereby continuously improving the accuracy of the security profile scoring in representing the risk situation.

[0124] Figure 3 A schematic flowchart illustrating a method for obtaining vulnerability detection results of financial applications, provided in this application embodiment. Based on the above embodiment, it includes:

[0125] S31, Perform static security checks on the code data in the original security data to obtain static vulnerability detection results;

[0126] S32 performs dynamic security checks on the running instances of financial applications to obtain dynamic vulnerability detection results;

[0127] S33 aggregates and processes static vulnerability detection results and / or dynamic vulnerability detection results to obtain vulnerability detection results for financial applications.

[0128] In this embodiment, static security detection is a detection method that performs rule matching, semantic analysis, or defect pattern recognition on code data without triggering the operation of financial applications. Its input is code data, and its output is a structured detection record that characterizes potential vulnerabilities. Static vulnerability detection results are typically generated in the form of a set of vulnerability entries. Each vulnerability entry includes at least a vulnerability identifier, vulnerability type or category information, vulnerability level or severity information, and code location information associated with the code data, enabling subsequent location and verification of vulnerability points based on the code location information. In specific implementations, static security detection can perform incremental or full scans of code data, and retain the scan time, rule version, or detection configuration identifier in the output to ensure the traceability of static vulnerability detection results across different evaluation batches.

[0129] Dynamic security detection is a detection method that verifies the security of running instances of financial applications in an interactive running state based on interface calls, request construction, or behavioral verification. A running instance is an execution entity deployed in a test or operational environment that can provide services externally. Dynamic vulnerability detection results represent risk items that are triggerable or observable in the running state. The output is also generated as a set of vulnerability entries and may include fields such as vulnerability identifier, vulnerability type or category information, vulnerability level or severity information, trigger condition description, and the identifier of the target object interacting with the running instance. In scenarios where the code's location can be pinpointed, dynamic vulnerability detection results can also carry code location information or corresponding interface identifier information that can be aligned with the code data to support alignment and mutual verification with static vulnerability detection results. By generating dynamic vulnerability detection results for running instances, supplementary coverage of runtime risk exposure is achieved, enabling vulnerability detection results to simultaneously reflect risk items that are difficult to reveal through static detection or require runtime interaction for verification. This improves the accuracy of the assessment input in reflecting the actual risk state and reduces misjudgments.

[0130] Next, the aggregation process involves structuring, deduplicating, merging, and unifying the detection results from different detection methods to form a unified vulnerability detection result for subsequent use. Aggregation processing can unify the format of static and dynamic vulnerability detection results at the field level, ensuring that key fields such as vulnerability identifier, vulnerability level or severity information, and code location information meet unified data structure constraints. For vulnerability entries in static and dynamic detection results that point to the same vulnerability location or the same risk item, aggregation processing can match and merge them based on code location information, interface identifier information, or vulnerability feature information to avoid duplicate inclusion and assessment bias. For vulnerability entries existing from only a single source, aggregation processing retains their source identifier to support subsequent review and tracing. By aggregating static and / or dynamic vulnerability detection results to form a unified vulnerability detection result, subsequent quantitative processing and risk assessment can use the vulnerability detection result under a single caliber, improving the stability of vulnerability determination.

[0131] In one embodiment, the method further includes adjusting the weight coefficients of historical events, specifically including: obtaining the occurrence time information of each historical security event in the historical security event data; determining the time difference corresponding to each historical security event based on the current time and the occurrence time information of each historical security event, and determining the time decay coefficient according to a preset time decay rule; adjusting the scoring weight coefficients corresponding to the historical event indicators according to the time decay coefficients to obtain the adjusted historical event weight coefficients; performing weighted calculations on the historical event indicators based on the adjusted historical event weight coefficients, and summarizing the weighted results with code security indicators, dependent component security indicators, and configuration security indicators to obtain a security profile score for the financial application.

[0132] In this embodiment, the event records in the historical security event data are structured and parsed to extract the occurrence time information that characterizes the time of the event, and a mapping relationship is established between the occurrence time information and the corresponding historical security events. The occurrence time information can be standardized using a unified time representation format to eliminate differences in time zones, precision, or time field naming among different data sources. The current time is used as the evaluation point to compare with the occurrence time information of each historical security event to calculate the time difference between each historical security event and the current time. The time difference represents the degree of timeliness of the impact of the historical security event on the current risk situation. A preset time decay rule is used to map the time difference into a time decay coefficient, so that the contribution of historical security events to the scoring weight decreases over time. The preset time decay rule can adopt a monotonically decreasing mapping form to ensure that the time decay coefficient does not increase when the time difference is larger, and key time thresholds can be set to reflect the pattern that recent events contribute more significantly to the risk situation. For example, historical security events that are older than the current time can be assigned smaller time decay coefficients to reduce their impact on subsequent scoring. By introducing time differences and generating time decay coefficients based on preset time decay rules, the safety profile scoring can better highlight recent risk exposure signals and reduce the bias caused by long-term events in the current assessment.

[0133] The time decay coefficient is used to dynamically modulate the contribution of historical event indicators to the overall score, enabling the weight of historical event indicators to adaptively adjust as the time difference of historical security events changes. The decay adjustment scales the scoring weight coefficients corresponding to historical event indicators at the scoring weight coefficient level, resulting in adjusted historical event weight coefficients. This decay adjustment process reduces the disproportionate impact of historical event indicators on the overall score after long-term accumulation, while maintaining the calibrating effect of historical security events on the risk situation. By using the time decay coefficient to adjust the scoring weight coefficients, a dynamic effect of historical event indicator weights changing over time is achieved, allowing the security profile score to more stably reflect the current risk status at different assessment points, thereby reducing the risk of missed or incorrect assessments spreading at the overall assessment level.

[0134] When calculating a security profile score for a financial application by weighting historical event indicators using adjusted historical event weighting coefficients and summing these results with the weighted results of code security indicators, dependent component security indicators, and configuration security indicators, the historical event indicators participate in the comprehensive calculation under the constraint of the adjusted historical event weighting coefficients. This ensures that the contribution of historical event indicators to the security profile score reflects the effective impact after time decay. Simultaneously, the weighted results of code security indicators, dependent component security indicators, and configuration security indicators are summed with the weighted results of historical event indicators under a unified standard, forming a comprehensive expression of the overall risk status of the target financial application. This summarization process allows the security profile score to reflect relatively stable risk sources such as code, dependent components, and configuration, while also incorporating feedback signals from historical security events during operation through a time decay mechanism, reducing the excessive influence of long-standing events on the current assessment.

[0135] Figure 4 This is a schematic diagram of the structure of the security assessment device for financial applications provided in the embodiments of this application, as shown below. Figure 4 As shown, the safety assessment device 40 provided in this embodiment includes:

[0136] The data acquisition module 401 is used to acquire the raw security data of financial applications and to quantify the raw security data according to the preset data quantification rules to obtain multiple security dimension indicators.

[0137] The profile scoring module 402 is used to obtain a security profile score for financial applications based on the business scenario type and multiple security dimension indicators of the financial applications.

[0138] The vulnerability analysis module 403 is used to perform code structure parsing on the code data in the original security data, obtain the code structure representation, and determine the requirement items and corresponding code location information for each vulnerability based on the code structure representation, the vulnerability detection results in the original security data and business metadata, and obtain the vulnerability tracing relationship.

[0139] The vulnerability analysis module 403 is also used to obtain the business system type to which the financial application belongs, and to determine the vulnerability remediation priority of each vulnerability based on the vulnerability detection results and the business system type, using preset priority determination rules.

[0140] The results output module 404 is used to generate and output security assessment results based on security profile scores, vulnerability attribution relationships, and vulnerability remediation priorities.

[0141] In one possible implementation, the raw security data includes at least one of vulnerability detection results, application configuration data, dependent component data, and historical security event data; the security dimension indicators include code security indicators, dependent component security indicators, configuration security indicators, or historical event indicators.

[0142] Accordingly, the data acquisition module 401 is specifically used for: extracting multiple vulnerability entries based on vulnerability detection results, and obtaining code security indicators based on the vulnerability level corresponding to each vulnerability entry and the preset level weight coefficient corresponding to the vulnerability level; and / or matching dependent component data with a preset vulnerability database to obtain the number of dependent component vulnerabilities and the vulnerability severity score corresponding to each dependent component vulnerability, and obtaining dependent component security indicators based on the number of dependent component vulnerabilities and the vulnerability severity score corresponding to each dependent component vulnerability; and / or extracting multiple configuration items based on application configuration data, and performing compliance judgment on multiple configuration items based on a preset compliance benchmark to obtain the configuration item compliance rate, and generating configuration security indicators based on the configuration item compliance rate; and / or obtaining the number of historical security events based on historical security event data within a preset time window, and obtaining the event level coefficient corresponding to each historical security event, and calculating and obtaining historical event indicators based on the number of historical security events and the event level coefficient corresponding to each historical security event.

[0143] In one possible implementation, the profile scoring module 402 is specifically used for: determining the business scenario type of the financial application based on the business metadata of the financial application, and querying and obtaining the business threat coefficient corresponding to the business scenario type; obtaining code security indicators, dependent component security indicators, configuration security indicators, and historical event indicators, and performing weighted calculations on the code security indicators, dependent component security indicators, configuration security indicators, and historical event indicators according to preset scoring weight coefficients to obtain a comprehensive score; and obtaining a security profile score for the financial application based on the comprehensive score and the business threat coefficient.

[0144] In one possible implementation, the raw security data also includes code data and business metadata.

[0145] Accordingly, the vulnerability analysis module 403 is specifically used for: performing abstract syntax tree parsing on code data, establishing the correspondence between syntax nodes and code location information, and obtaining a code structure representation; identifying annotation information corresponding to financial business based on the code structure representation, and determining business processing functions based on the annotation information; obtaining the call chain and / or data flow path associated with the fund flow based on the call relationship of the business processing functions; associating and annotating the call chain and / or data flow path with the regulatory requirement information in the business metadata to update the code structure representation; obtaining the vulnerability identifier of each vulnerability and its corresponding code location information based on the vulnerability detection results, and locating the syntax node corresponding to the code location information in the code structure representation; obtaining the business function identifier corresponding to the syntax node based on the interface definition information and / or functional module division information in the business metadata, and determining the requirement item identifier corresponding to the business function identifier based on the association information between the business function identifier and the requirement item identifier; and generating and recording vulnerability tracing relationships based on the vulnerability identifier, requirement item identifier, and code location information of each vulnerability.

[0146] In one possible implementation, the vulnerability analysis module 403 is specifically used for: determining the business system type of the financial application based on business metadata; wherein the business system type includes core systems, customer systems, and internal systems; querying a preset business impact factor mapping table based on the business system type to obtain the business impact factor; obtaining the vulnerability identifier of each vulnerability based on the vulnerability detection results, and querying a preset vulnerability database based on the vulnerability identifier to obtain the vulnerability severity score corresponding to each vulnerability; and calculating the vulnerability remediation priority of each vulnerability based on the vulnerability severity score and the business impact factor.

[0147] In one possible implementation, the result output module 404 is specifically used for: obtaining the requirement items and code location information corresponding to each vulnerability based on the vulnerability attribution relationship; associating the vulnerability remediation priority, the requirement items and code location information corresponding to each vulnerability, and generating a set of governance items containing vulnerability identifiers, requirement item identifiers, code location information and vulnerability remediation priorities; sorting each governance item in the governance item set based on the vulnerability remediation priority to obtain a governance list; generating risk situation information of the target application based on the security profile score, and outputting the risk situation information and governance list through a visual decision dashboard to complete the output of the security assessment results.

[0148] In one possible implementation, a data update module is also included, used for: acquiring historical governance data within a preset update cycle, the historical governance data including at least one of vulnerability patching records, historical security event impact data, and false positive or false negative statistics; acquiring code security indicators, dependent component security indicators, configuration security indicators, and historical event indicators corresponding to multiple time periods within the preset update cycle; determining security impact values ​​corresponding to multiple time periods based on historical security event impact data; wherein, security impact values ​​include at least one of downtime and financial loss; associating and matching the code security indicators, dependent component security indicators, configuration security indicators, and historical event indicators corresponding to the time periods with the corresponding security impact values ​​to generate sample records, and constructing a training dataset from multiple sample records; performing regression analysis on the training dataset to obtain candidate scoring weight coefficients; normalizing the candidate scoring weight coefficients, and updating the normalized scoring weight coefficients to the preset scoring weight coefficients.

[0149] The safety assessment device 40 provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0150] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the electronic device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0151] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0152] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0153] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0154] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0155] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0156] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0157] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0158] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0159] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0160] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0161] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0162] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0163] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0164] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0165] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A security assessment method for financial applications, characterized in that, include: Obtain raw security data for financial applications, and quantify the raw security data according to preset data quantification rules to obtain multiple security dimension indicators; Based on the business scenario type of the financial application and the multiple security dimension indicators, a security profile score for the financial application is obtained. The code data in the original security data is parsed to obtain a code structure representation. Based on the code structure representation, the vulnerability detection results and business metadata in the original security data, the requirement items and corresponding code location information for each vulnerability are determined, and the vulnerability tracing relationship is obtained. Obtain the business system type to which the financial application belongs, and determine the vulnerability remediation priority of each vulnerability based on the vulnerability detection results and the business system type using preset priority determination rules; Based on the security profile score, the vulnerability attribution relationship, and the vulnerability remediation priority, a security assessment result is generated and output.

2. The method according to claim 1, characterized in that, The raw security data includes at least one of the following: vulnerability detection results, application configuration data, dependent component data, and historical security event data; The security dimension metrics include code security metrics, dependent component security metrics, configuration security metrics, or historical event metrics. Accordingly, the raw security data is quantified according to preset data quantization rules to obtain multiple security dimension indicators, including: Based on the vulnerability detection results, multiple vulnerability entries are extracted, and code security indicators are obtained according to the vulnerability level corresponding to each vulnerability entry and the preset level weight coefficient corresponding to the vulnerability level. And / or match the dependent component data with a preset vulnerability database to obtain the number of dependent component vulnerabilities and the vulnerability severity score corresponding to each dependent component vulnerability, and obtain the security index of the dependent component based on the number of dependent component vulnerabilities and the vulnerability severity score corresponding to each dependent component vulnerability; And / or extract multiple configuration items based on the application configuration data, and determine the compliance of the multiple configuration items according to a preset compliance benchmark to obtain the configuration item compliance rate, and generate configuration security indicators based on the configuration item compliance rate; And / or based on historical security event data within a preset time window, obtain the number of historical security events and obtain the event level coefficient corresponding to each historical security event, and calculate and obtain historical event indicators based on the number of historical security events and the event level coefficient corresponding to each historical security event.

3. The method according to claim 2, characterized in that, The process of obtaining a security profile score for the financial application based on its business scenario type and multiple security dimension indicators includes: Based on the business metadata of the financial application, determine the business scenario type of the financial application, and query and obtain the business threat coefficient corresponding to the business scenario type; Obtain code security metrics, dependent component security metrics, configuration security metrics, and historical event metrics, and calculate a comprehensive score by weighting these metrics according to a preset scoring weight coefficient. The security profile score of the financial application is obtained based on the comprehensive score and the business threat coefficient.

4. The method according to claim 1, characterized in that, The code data in the original security data is subjected to code structure parsing processing to obtain a code structure representation. Based on the code structure representation, the vulnerability detection results in the original security data, and business metadata, the requirement items and corresponding code location information corresponding to each vulnerability are determined, and the vulnerability tracing relationship is obtained, including: The code data is parsed using an abstract syntax tree to establish a correspondence between syntax nodes and code location information, thereby obtaining a code structure representation; Based on the code structure, the annotation information corresponding to financial business is identified, and the business processing function is determined according to the annotation information; Based on the call relationship of the business processing functions, obtain the call chain and / or data flow path associated with the fund flow; Based on the regulatory requirements information in the business metadata, the call chain and / or the data flow path are associated and labeled to update the code structure representation; Based on the vulnerability detection results, obtain the vulnerability identifier of each vulnerability and its corresponding code location information, and locate the syntax node corresponding to the code location information in the code structure representation; Based on the interface definition information and / or functional module division information in the business metadata, obtain the business function identifier corresponding to the syntax node, and determine the requirement item identifier corresponding to the business function identifier based on the association information between the business function identifier and the requirement item identifier. Based on the vulnerability identifiers, requirement item identifiers, and code location information, vulnerability attribution relationships are generated and recorded.

5. The method according to claim 4, characterized in that, Obtain the business system type to which the financial application belongs, and based on the vulnerability detection results and the business system type, determine the vulnerability remediation priority for each vulnerability using preset priority determination rules, including: Based on the business metadata, the business system type of the financial application is determined; wherein, the business system type includes core systems, customer systems, and internal systems; Based on the business system type, query the preset business impact factor mapping table to obtain the business impact factor; Based on the vulnerability detection results, obtain the vulnerability identifier of each vulnerability, and based on the vulnerability identifier, query the preset vulnerability database to obtain the vulnerability severity score corresponding to each vulnerability. Based on the vulnerability severity score and the business impact factor, the vulnerability remediation priority for each vulnerability is calculated.

6. The method according to claim 1, characterized in that, The process of generating and outputting security assessment results based on the security profile score, the vulnerability attribution relationship, and the vulnerability remediation priority includes: Based on the vulnerability attribution relationship, obtain the requirement items and code location information corresponding to each vulnerability; The vulnerability remediation priority, the corresponding requirement items and code location information of each vulnerability are associated to generate a set of governance items containing vulnerability identifiers, requirement item identifiers, code location information and the vulnerability remediation priority; Based on the vulnerability remediation priority, the governance items in the governance item set are sorted to obtain a governance list; Based on the security profile score, risk situation information of the target application is generated, and the risk situation information and the governance list are output through a visual decision dashboard to complete the output of the security assessment results.

7. The method according to claim 3, characterized in that, Also includes: Acquire historical governance data within a preset update cycle. The historical governance data includes at least one of vulnerability remediation records, historical security event impact data, and false alarm or underreporting statistics. Obtain code security metrics, dependent component security metrics, configuration security metrics, and historical event metrics corresponding to multiple time periods within the preset update cycle; Based on the historical security event impact data, determine the security impact values ​​corresponding to the multiple time periods; wherein, the security impact values ​​include at least one of downtime and financial loss; The code security metrics, dependent component security metrics, configuration security metrics, and historical event metrics corresponding to the time period are associated and matched with the corresponding security impact values ​​to generate sample records, and a training dataset is constructed from multiple sample records. Regression analysis is performed on the training dataset to obtain the candidate score weight coefficients; The candidate scoring weight coefficients are normalized, and the normalized scoring weight coefficients are updated to the preset scoring weight coefficients.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images