Security detection method and device for Android application, equipment and medium

Abstract

The invention discloses a security detection method and device for an Android application, equipment and a medium, and relates to the technical field of computer security detection.The method comprises the steps that an APK construction task is triggered through interaction with a Jenkins server, and APK metadata and an APK file are obtained when the APK construction task is successfully finished; calling a cloud virus scanning platform to perform multi-engine scanning processing on the APK file to obtain a multi-engine scanning result; performing semantic analysis on the multi-engine scanning result by utilizing a large language model, and generating a structured report at least comprising high risk points, code-level repair suggestions and false alarm analysis; and carrying out storage and visual display processing on the APK metadata, the multi-engine scanning result and the structured report. The security detection efficiency of the Android application can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer security detection technology, and in particular to a security detection method, device, equipment and medium for Android applications. Background Art

[0002] With the rapid development of mobile internet technology, the security of Android applications (Android Package Kit, APK) has become a core concern in software development and distribution. As malware attacks become more complex and diverse, traditional Android application security testing processes face challenges such as insufficient automation and a single risk analysis dimension. There is an urgent need to integrate cutting-edge technologies to build a more efficient and intelligent security testing system.

[0003] Existing Android app security testing solutions typically separate the build, scanning, and analysis stages: the build stage relies on manual triggering or semi-automated processes, the scanning stage often uses a single virus engine to identify risks, and the analysis stage can only output a simple conclusion of "whether it is a virus or not." For example, traditional testing systems require manual export of APK files from the build environment and manual upload to the virus scanning platform. After the scan is complete, security personnel then interpret the technical parameters one by one. The entire process requires multiple manual interventions, resulting in long testing cycles and low efficiency. Summary of the Invention

[0004] In view of this, the present application provides a security detection method, apparatus, device and medium for Android applications, which can improve the security detection efficiency of Android applications.

[0005] According to a first aspect of the present application, a security detection method for an Android application is provided, which is applied to an Android application security detection system, and the method includes: By interacting with the Jenkins server, triggering the APK build task, and obtaining the APK metadata and APK file when the APK build task is successfully completed; Calling a cloud-based virus scanning platform to perform a multi-engine scan on the APK file to obtain a multi-engine scan result; Using a large language model to perform semantic analysis on the multi-engine scanning results, generating a structured report that at least includes high-risk risk points, code-level remediation suggestions, and false positive analysis; The APK metadata, the multi-engine scanning results, and the structured report are stored and visually displayed.

[0006] According to a second aspect of the present application, a security detection device for an Android application is provided, comprising: The acquisition module is used to trigger the APK build task by interacting with the Jenkins server and obtain the APK metadata and APK file when the APK build task is successfully completed; A processing module, configured to call a cloud-based virus scanning platform to perform a multi-engine scan on the APK file and obtain a multi-engine scan result; A parsing module, configured to perform semantic parsing on the multi-engine scanning results using a large language model, and generate a structured report containing at least high-risk points, code-level remediation suggestions, and false positive analysis; The storage and display module is used to store and visually display the APK metadata, the multi-engine scanning results and the structured report.

[0007] According to a third aspect of the present application, a storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the above-mentioned method for evaluating the saturation of operation and maintenance work is implemented.

[0008] According to the fourth aspect of the present application, an electronic device is provided, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor implements the above-mentioned method for evaluating the saturation of operation and maintenance work when executing the program.

[0009] By leveraging the aforementioned technical solution, the Android application security testing method, apparatus, device, and medium provided in this application first interact with a Jenkins server to trigger an APK build task and, upon successful completion of the APK build task, retrieve the APK metadata and APK file. This interaction with the Jenkins server automates the APK build process, eliminating manual intervention and improving build efficiency. A cloud-based virus scanning platform is then invoked to perform a multi-engine scan on the APK file, generating multi-engine scan results. This multi-engine scan on the cloud-based virus scanning platform addresses multiple risks, overcoming the limitations of a single engine and enhancing comprehensive detection. The multi-engine scan results are then semantically parsed using a large language model to generate a structured report containing high-risk points, code-level remediation recommendations, and false positive analysis. The APK metadata, scan results, and structured report are then stored and visualized. This solution forms an intelligent, fully closed-loop process from build to analysis and presentation. This unmanned flow mechanism overcomes the fragmented nature of traditional processes, shortening the detection cycle and improving the efficiency of Android application security testing. Furthermore, through in-depth analysis using a large language model, decision-making efficiency is improved while enhancing the depth of analysis, meeting the requirements of automated and intelligent security testing.

[0010] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 A schematic diagram of the system framework of an Android application security detection system provided by an embodiment of the present application is shown; Figure 2 A schematic diagram of a process flow of a security detection method for an Android application provided in an embodiment of the present application is shown; Figure 3 A schematic diagram showing a flow chart of a security detection method for an Android application provided in another embodiment of the present application is shown; Figure 4 A schematic diagram of the structure of a security detection device for an Android application provided in an embodiment of the present application is shown; Figure 5 A schematic diagram showing the structure of another Android application security detection device provided in an embodiment of the present application is shown; In the picture: 101-CI integration module, 102-cloud scanning module, 103-large model analysis module, 104-data storage module, 105-visualization module; 41 - acquisition module, 42 - processing module, 43 - parsing module, 44 - storage and display module, 45 - analysis module. DETAILED DESCRIPTION

[0012] The present application will be described in detail below with reference to the accompanying drawings and in combination with embodiments. It should be noted that, unless there is a conflict, the embodiments and features in the embodiments of the present application can be combined with each other.

[0013] Existing Android app security testing solutions typically separate the build, scanning, and analysis stages: the build stage relies on manual triggering or semi-automated processes, the scanning stage often uses a single virus engine to identify risks, and the analysis stage can only output a simple conclusion of "whether it is a virus or not." For example, traditional testing systems require manual export of APK files from the build environment and manual upload to the virus scanning platform. After the scan is complete, security personnel then interpret the technical parameters one by one. The entire process requires multiple manual interventions, resulting in long testing cycles and low efficiency.

[0014] Furthermore, existing technologies have significant analytical limitations. Firstly, they lack in-depth analysis of risk types, making it impossible to correlate risky behaviors with code logic (e.g., the relationship between permission abuse and specific code modules is unclear). Secondly, their visualization is limited, with detection reports often consisting primarily of raw data tables, making it difficult for non-technical personnel to quickly understand the actual impact of risks. Furthermore, the lack of structured data linkage across various links makes it difficult for security teams to track risk trends or conduct cross-version comparative analysis, further limiting the level of intelligence and automation in the detection process.

[0015] In order to solve the above technical problems, the technical concept of this application is to provide an Android application security detection system that can realize the full process closed loop of APK from construction, scanning, analysis to visual display. Figure 1 As shown, the system includes a CI integration module 101, a cloud scanning module 102, a large model analysis module 103, a data storage module 104, and a visualization module 105. The CI integration module 101 can automatically trigger the APK building task of the Jenkins server and obtain the APK metadata and APK file. The cloud scanning module 102 can call the cloud virus scanning platform to perform multi-engine scanning on the APK file to generate multi-dimensional results. The large model analysis module 103 can use a large language model to parse the multi-dimensional results, generate risk summaries, code-level repair suggestions, and false positive analysis and other detection data, and use the data storage module 104 and the visualization module 105 to realize the storage and visualization of the detection data. This application can solve the problems of fragmented traditional detection processes, insufficient analysis capabilities, and poor visualization, and can improve detection efficiency. It is suitable for mobile application development and security detection scenarios.

[0016] Specifically, in the closed loop of the entire process from building APK, scanning, analyzing to visual display, the CI integration module 101 is used to interact with the Jenkins server, trigger the APK building task, and obtain the APK metadata and APK file when the APK building task is successfully completed; the cloud scanning module 102 is used to call the cloud virus scanning platform to perform multi-engine scanning on the APK file to obtain the multi-engine scanning results; the large model analysis module 103 is used to use a large language model to perform semantic analysis on the multi-engine scanning results, and generate a structured report that at least includes high-risk risk points, code-level repair suggestions and false alarm analysis; the data storage module 104 is used to store APK metadata, multi-engine scanning results and structured reports; the visualization module 105 is used to perform visual display processing on the APK metadata, multi-engine scanning results and structured reports.

[0017] Figure 2 A flowchart of a security detection method for an Android application provided by an embodiment of the present invention, which can be performed as follows Figure 1The Android application security detection system shown in the figure is executed. Figure 2 As shown, the method may include the following steps: Step 210: Trigger the APK build task by interacting with the Jenkins server, and obtain the APK metadata and APK file when the APK build task is successfully completed.

[0018] Among them, the Jenkins server is an open source continuous integration (CI) tool used to automate the build, test, and deployment processes. It supports integration with external systems through API interfaces, enabling remote triggering and status monitoring of build tasks. The APK build task refers to the Android application packaging process executed in the Jenkins server, which generates an APK installation package through operations such as compiling code, integrating resource files, and signing. APK metadata refers to descriptive information related to the APK file, including the version number (such as VERSION=1.0.0), build time, and compilation environment variables (such as the target SDK version and compilation tool chain). This data can be extracted from Jenkins build environment variables or logs to identify the basic properties and build context of the APK. The APK file refers to the Android application installation package, a binary file generated by the build task, containing application code, resources, manifest files, etc., which can be installed and run on Android devices.

[0019] According to the embodiments of the present disclosure, the CI integration module in the Android application security detection system can interact with the Jenkins server automatically to achieve unmanned intervention in the entire process of APK construction and product acquisition.

[0020] Step 220: Call the cloud virus scanning platform to perform multi-engine scanning on the APK file to obtain the multi-engine scanning result.

[0021] Among them, the cloud-based virus scanning platform is a security detection service platform built on a cloud computing architecture (such as VirusTotal, etc.), which integrates the detection engines and risk databases of multiple security vendors to provide users with file security scanning services; the multi-engine scanning results are structured data output by the cloud-based virus scanning platform after security detection of APK files, which may include independent conclusions and comprehensive statistical information of multiple detection engines.

[0022] In the disclosed embodiments, APK files can be uploaded to a cloud-based virus scanning platform, which then uses multiple independent detection engines to simultaneously scan the APK file. Each detection engine independently determines whether the APK file presents a security threat based on its own virus database and detection algorithm. After the scan is complete, the cloud-based virus scanning platform aggregates the detection results of each detection engine to generate a multi-engine scan result containing each engine's detection conclusion (e.g., "safe," "malware," "suspicious," etc.). This multi-engine scan result reflects the security status of the APK file under multiple detection criteria, providing a basis for subsequent risk assessment and resolution.

[0023] The steps of this embodiment use the computing power and multi-engine resources of the cloud platform to convert the APK file into quantifiable security risk data, which can provide a basis for subsequent risk assessment and processing.

[0024] Step 230: Use a large language model to perform semantic analysis on the multi-engine scanning results to generate a structured report that at least includes high-risk points, code-level repair suggestions, and false positive analysis.

[0025] Among them, Large Language Model (LLM) refers to a model that has undergone large-scale text training and has language processing capabilities, such as GPT-4o and N-gram models. There is no specific restriction on the selected model here.

[0026] For the disclosed embodiment, a large language model can be used to perform in-depth semantic analysis of the multi-engine scanning results, converting the original detection data into actionable security insights. First, a prompt word containing analysis instructions, data field placeholders, and output format requirements can be generated based on the multi-engine scanning results (such as "Analyze the risk of permission abuse in APK and provide repair suggestions"), and then the prompt word and the scanning results (such as the details of each engine's virus report and the permission list) are input into the large language model. Based on its knowledge base and reasoning capabilities, the large language model will identify high-risk risk points, generate code-level repair suggestions, and analyze possible false positives. Finally, the risk points, repair plans, and false positive analysis are mapped to preset templates to form clear security assessment conclusions, which can provide the development team with directly executable improvement guidelines.

[0027] This process can achieve a leap from "detection result presentation" to "solution output", and can solve the pain point that traditional security scanning tools only provide a risk list and require manual interpretation. Through the semantic understanding ability of the large language model, the system can correlate the detection conclusions of different engines, analyze the risk priority in combination with the context, and provide a repair path for specific code implementations, significantly improving the efficiency of handling security issues. For example, the report may point out that "APK has a hard-coded key risk (high risk), it is recommended to use the Android Keystore system instead, and add key encryption logic on line 37", and at the same time mark "a certain engine's virus report is a false positive, it is actually the normal communication behavior of the third-party SDK." In this way, it can help the development team accurately locate and solve the problem.

[0028] Step 240: Store and visualize the APK metadata, multi-engine scanning results, and structured reports.

[0029] For the disclosed embodiments, the persistent management and intuitive presentation of detection data can be achieved through the data storage and visualization module: first, the APK metadata (such as version number, build time), multi-engine scanning results (such as the positive rate of each engine, risk behavior) and the structured report generated by the large language model (such as high-risk risk points, repair suggestions) are structured and stored in a relational database (such as MySQL) according to the preset data table structure to ensure data traceability and reuse; at the same time, multi-dimensional visualization content is generated based on the stored data, such as using a pie chart to display the risk level distribution (high / medium / low risk ratio), using a bar chart to compare the positive rate differences of each detection engine, and using a line chart to display the risk trend changes of historical versions. It is dynamically displayed in the user interface through front-end technologies such as React+ECharts, and combined with natural language reports to assist non-technical personnel to quickly understand the risk impact, forming a complete closed loop from data storage to decision support, and improving the readability and application value of security detection results.

[0030] In summary, the Android application security testing method provided by the present invention first triggers an APK build task by interacting with a Jenkins server. Upon successful completion of the APK build task, APK metadata and the APK file are obtained. This interaction with the Jenkins server automates the APK build process, eliminating manual intervention and improving build efficiency. A cloud-based virus scanning platform is then invoked to perform a multi-engine scan on the APK file, generating multi-engine scan results. This multi-engine scan on the cloud-based virus scanning platform addresses multiple risks, overcoming the limitations of a single engine and enhancing comprehensive detection. The multi-engine scan results are then semantically parsed using a large language model to generate a structured report containing high-risk points, code-level remediation recommendations, and false positive analysis. The APK metadata, scan results, and structured report are then stored and visualized. This solution forms an intelligent, fully closed-loop process from build to analysis and presentation. This unmanned flow mechanism overcomes the fragmented nature of traditional processes, shortening the detection cycle and improving the efficiency of Android application security testing. Furthermore, the in-depth analysis of the large language model improves decision-making efficiency while enhancing the depth of analysis, meeting the requirements of automated and intelligent security testing.

[0031] Furthermore, as a refinement and extension of the specific implementation of the above embodiment, in order to fully illustrate the implementation of this embodiment, this embodiment also provides another Android application security detection method, such as Figure 3 As shown, the method includes: Step 310: Trigger the APK build task by interacting with the Jenkins server, and obtain the APK metadata and APK file when the APK build task is successfully completed.

[0032] In the disclosed embodiments, Jenkins' REST API or the python-jenkins library (e.g., the jenkins.Jenkins class) can be used to send an APK build trigger request to the Jenkins server. The APK build trigger request includes parameterized information (e.g., version number VERSION=1.0.0). Upon receiving the APK build trigger request, the Jenkins server can execute the corresponding APK build task based on the parameterized information. For example, an APK build task named "apk_project" can be triggered using server.build_job("apk_project", parameters={...}) and passed along parameters such as the version number. After triggering the APK build, the CI integration module polls the Jenkins server in real time to obtain task status. Upon detecting that the APK build task has successfully completed (with an execution status of "SUCCESS"), it automatically downloads the generated APK file from the specified path and extracts APK metadata, including the version number, build time, and compilation environment variables, from Jenkins' environment variables or build logs. When interacting with the Jenkins server, the CI integration module automatically collects build failure logs generated by the Jenkins server if it detects an APK build task failure (i.e., if the execution status indicates an APK build task failure). It analyzes the log contents, extracts, and outputs key error information (such as compilation error codes and missing dependency warnings) for feedback to developers. Furthermore, key error information is accompanied by relevant APK build task parameters and timestamps, making it easier for developers to locate issues.

[0033] Accordingly, for the embodiment of the present disclosure, triggering the APK build task by interacting with the Jenkins server in step 310 of the embodiment and obtaining the APK metadata and APK file when the APK build task is successfully completed may include the following steps: Step 310-1: Use the Jenkins REST API or python-jenkins library to send an APK build trigger request to the Jenkins server, and attach parameterized information to the APK build trigger request. The parameterized information is used by the Jenkins server to respond and execute the APK build task.

[0034] Among them, the Jenkins REST API is the HTTP interface provided by Jenkins, allowing external systems to trigger build tasks through POST requests, pass parameters and obtain status; the python-jenkins library is a Python-encapsulated client tool used to simplify interaction with the Jenkins server, such as directly triggering tasks through the server.build_job method; parameterized information is dynamically configured build parameters used to control the build process (such as version number and compilation environment) to achieve the generation of APKs with different configurations for the same task.

[0035] In the disclosed embodiments, a network request can be sent to the Jenkins server via the Jenkins REST API or the python-jenkins library to trigger an APK build task. For example, using the python-jenkins library's build_job function, specify the build task name (e.g., "apk_project") and pass parameterized information (e.g., version number VERSION=1.0.0, environment variable ENV=prod). These parameters are parsed by the Jenkins server and used to execute differentiated build logic (e.g., generating APKs for different environments).

[0036] Step 310 - 2 : After determining that the Jenkins server receives the APK build trigger request, monitor the execution status of the APK build task in the Jenkins server in real time.

[0037] In the disclosed embodiment, after determining that the Jenkins server has received an APK build trigger request, the execution status of the APK build task in the Jenkins server can be queried in real time by looping through Jenkins interfaces (such as the get_build_info function). For example, the build result is continuously checked to see if it is None (indicating an incomplete task) until the execution status is updated to "SUCCESS," "FAILURE," or "ABORTED." If and only if the execution status is updated to "SUCCESS," the subsequent step 310-3 of the embodiment is executed. This ensures that the system executes subsequent operations only after the build is complete, avoiding the processing of incomplete APK files. Step 310-3: When the execution status reflects that the APK build task has been successfully completed, the generated APK file is automatically downloaded from the storage path specified by the Jenkins server. At the same time, the APK metadata including the version number, environment variables and build time is extracted from the build environment variables or build log of the Jenkins server.

[0038] In the disclosed embodiment, when the APK build task's execution status on the Jenkins server reaches "SUCCESS," it indicates successful completion. The system then automatically downloads the generated APK file from a specified path on the Jenkins server (e.g., output.apk in the workspace). Simultaneously, APK metadata, including version number, build time, and compilation environment (e.g., target SDK version), is extracted from Jenkins build environment variables (e.g., BUILD_NUMBER, VERSION) or build logs.

[0039] Step 320: Call the cloud virus scanning platform to perform multi-engine scanning on the APK file to obtain the multi-engine scanning result.

[0040] In the embodiment of the present disclosure, calling the cloud virus scanning platform to perform multi-engine scanning on the APK file in step 320 to obtain the multi-engine scanning result may include the following steps: Step 320-1: Upload the APK file to the cloud server in binary stream form, and after the upload is successful, receive the scanning task ID sent in response by the cloud server. The cloud server is configured with a cloud virus scanning platform that provides multi-engine scanning services.

[0041] In the disclosed embodiments, a standardized interface enables automated transmission of APK files to a cloud-based virus scanning platform. The system converts the generated APK file into a binary data stream and sends it to a cloud server via an HTTP request (e.g., POST method). Upon receiving the APK file, the cloud-based virus scanning platform (e.g., VirusTotal) deployed on the cloud server immediately generates an ID (e.g., in UUID format) uniquely identifying the scan task and returns it to the system. This process ensures that the APK file is transmitted intact as a raw byte stream, avoiding detection errors caused by format conversion. Furthermore, the scan task ID establishes a mapping between the APK file and subsequent multi-engine scan results, providing a key index for automated scan report generation. This enables digital management of the entire process, from APK file upload to task tracking.

[0042] Step 320 - 2 : Based on the scanning task ID, the multi-engine scanning result is retrieved from the cloud server. The multi-engine scanning result is obtained by performing a multi-engine scan on the APK file by multiple detection engines on the cloud virus scanning platform.

[0043] After successfully uploading the APK file and receiving the scan task ID returned by the cloud server, the system can use this scan task ID to query the cloud server for multi-engine scan results. The cloud-based virus scanning platform uses multiple detection engines (such as Avast and Kaspersky) to perform security scans on the APK file in parallel. Based on the scan task ID, the system retrieves the platform database to obtain the complete multi-engine scan results, including each engine's detection conclusion (such as positive / negative verdict and threat type), comprehensive risk statistics (such as the percentage of virus-reporting engines), and file metadata (such as hash values ​​and permission lists). This process ensures that the scan results accurately match the original uploaded file, providing a reliable data source for subsequent large-scale language model analysis and risk assessment.

[0044] In specific application scenarios, when the APK file size is large, it may cause a significant increase in the time required to download and install the application, especially in a weak network environment, where it is prone to transmission interruption and failure, affecting the user experience; an excessively large file size will take up more device storage space, which may trigger a system storage warning or cause other applications to run out of memory; in addition, large files are susceptible to platform file size restrictions when uploaded to the cloud detection platform (such as being rejected if they exceed 200MB), making it impossible to complete security scanning. Moreover, if the network fluctuates during the overall transmission, the entire file needs to be re-uploaded, which is inefficient. At the same time, the client performance may be slowed down or even crashed due to loading the file into memory at one time.

[0045] Therefore, as a preferred approach, the APK file can be evaluated before being uploaded to the cloud server. Specifically, it can be compared with the maximum file size supported by the corresponding application programming interface of the cloud virus scanning platform. If the APK file size does not exceed the maximum file size limit, the method of steps 320-1 and 320-2 can be used to directly upload the APK file to the cloud server in the form of a binary stream. After the upload is successful, the cloud server responds with a scan task ID and retrieves the multi-engine scan results from the cloud server based on the scan task ID. The multi-engine scan results are obtained by performing a multi-engine scan on the APK file using multiple detection engines on the cloud virus scanning platform. Conversely, if the APK file size exceeds the maximum file size limit (e.g., 200MB), the APK file can be split into binary blocks of a fixed size (e.g., 50MB / block). A unique identifier is generated for each block, along with metadata such as the block number. Each block is then uploaded to the cloud server, carrying the identifier and metadata. Upon successful upload, the corresponding sub-scan task ID is obtained. The cloud platform then performs a multi-engine scan on each block in parallel. The system uses the sub-scan task ID to query the sub-scan data (e.g., each engine's detection conclusion for that block). Finally, based on the unique identifier and block number, all sub-scan data is sequentially spliced ​​together to reconstruct the multi-engine scan results for the complete APK file. This mechanism overcomes the platform's file size limit, ensuring that even large APKs can receive comprehensive security testing. Unique identifiers ensure accurate reassembly of the block data, maintaining the integrity of the test results.

[0046] Correspondingly, as an embodiment step parallel to steps 320-1 and 320-2, the embodiment step may also include: obtaining the APK file size of the APK file and comparing it with the maximum file limit supported by the corresponding application programming interface of the cloud virus scanning platform; if the APK file size exceeds the maximum file limit, triggering the block upload mechanism, cutting the APK file into multiple fixed-size file blocks, and generating a unique identifier and block metadata for each file block, the block metadata at least including the block number; uploading each file block to the cloud server block by block in the form of a binary stream, and carrying the corresponding unique identifier and block metadata; after each file block is successfully uploaded, receiving the file block scanning task ID sent by the cloud server in response, and querying the sub-scan data of each file block based on the file block scanning task ID, the sub-scan data is obtained by multiple detection engines on the cloud virus scanning platform performing multi-engine scanning on the file block; based on the unique identifier and block metadata, sequentially splicing the sub-scan data of each file block to obtain the multi-engine scanning result of the APK file.

[0047] For example, consider a cloud-based virus scanning platform's API with a maximum file size limit of 200MB. A 350MB game APK requires inspection. The system first compares the file size. If it finds the limit exceeded, it triggers the chunking mechanism, splitting the APK file into two fixed-size chunks (200MB and 150MB). Each chunk is uniquely identified (e.g., chunk_01, chunk_02) and appended with chunk number metadata (1 / 2, 2 / 2). Each chunk is then uploaded, each with its identifier and metadata. Upon successful upload, each chunk is assigned a file chunk scanning task ID (task_001, task_002). The system uses the task ID to query the sub-scan data: For chunk 1, all engines found no risks. For chunk 2, Engine B detected unencrypted user data storage logic. Finally, based on the unique identifier and chunk number, the sub-scan data is sequentially assembled to generate a multi-engine scan result for the complete APK file. This pinpoints the risk point in chunk 2 to the specific code segment, enabling comprehensive detection of files exceeding the limit.

[0048] Step 330: Generate prompt words containing preset fields based on the multi-engine scanning results. The prompt words are semantic inputs that can be understood by the large language model, and at least include analysis instructions, data field placeholders, and output format requirements.

[0049] For the embodiments of the present disclosure, the multi-engine scanning results can be converted into semantic instructions that can be parsed by a large language model through a standardized template: the system extracts key data (such as engine positive rate, risky permissions, and threat types) from the multi-engine scanning results, and fills them into the prompt word template according to preset fields (such as {engine positive rate}, {risky behavior list}), forming a semantic input that includes clear analysis instructions (such as "Identify high-risk permission abuse risks in APK"), data field placeholders, and structured output requirements (such as "Return high-risk risk points and repair suggestions in JSON format").

[0050] For example, if the scan result shows "25 / 60 engines report virus, and the READ_CONTACTS permission has an unspecified purpose," the prompt word may be designed as: "Analyze the security risks of the following APKs: Engine positive rate {25 / 60}, permission list {READ_CONTACTS, ACCESS_FINE_LOCATION}, risky behavior {background reading of address book without prompting the user}. Requirements: 1. List high-risk risk points (mark the corresponding engines); 2. Provide code-level remediation suggestions; 3. Output format is Markdown table." This process converts raw detection data into semantic instructions that can be understood by the large language model, ensuring that the large language model parses the data according to the preset logic and generates a security analysis report that meets the requirements.

[0051] Step 340: Input the prompt words and multi-engine scanning results into the large language model, trigger the semantic parsing and knowledge reasoning process, and generate raw text output including high-risk points, code repair suggestions and false positive analysis.

[0052] In the disclosed embodiment, the system can input a prompt containing analysis instructions, data fields, and formatting requirements (e.g., "Identify the risk of dangerous permission abuse in APK and provide a remediation solution") along with multi-engine scanning results (e.g., virus detection details from each engine and a list of permissions) into a large language model, triggering the model's semantic parsing and knowledge reasoning mechanisms. Based on the code knowledge base, security specifications, and engine detection logic in its training data, the large language model extracts high-risk risk points (e.g., "Hardcoded keys are not encrypted") from the multi-engine scanning results. Based on the code context, the large language model generates specific remediation suggestions (e.g., "Replace the hardcoded key with AndroidKeystore and add encryption logic on line 45"). Furthermore, by comparing risk characteristics with historical false positive patterns, the system identifies potential false positives (e.g., "An engine misjudged the normal log printing function"). The system ultimately outputs raw text containing a risk description, remediation solution, and false positive analysis, providing the core content for subsequent structured report generation.

[0053] Step 350: Structural processing is performed on the original text output, and high-risk points, code repair suggestions, and false positive analysis are mapped to preset data field positions of the structured report template to obtain a structured report.

[0054] For the disclosed embodiments, the natural language output of the large language model can be converted into a standardized security report through data mapping and template filling: the system first performs semantic analysis on the original text to identify the risk description, repair suggestions and false alarm analysis content, and maps the text fragments to the preset report template fields (such as high_risk_points, code_fix_suggestions) through keyword matching (such as "high risk" and "repair plan") and semantic classification algorithms; then, the key information such as the code line number and API call in the repair suggestion is extracted and formatted to generate code fragments that can be directly used for development and repair; finally, the content of each part is laid out according to the template structure (such as the risk level table and the repair step list) to form a structured report with numbering, priority and detailed description.

[0055] For example, the original text "Add a permission request pop-up window on line 45 of MainActivity.java" is converted into the template {"file":"MainActivity.java","line":45,"fix_code": "ActivityResultLauncher <string>requestPermission = ..."} format to ensure that the report content can be directly understood and implemented by the development team.

[0056] Step 360: Store and visualize the APK metadata, multi-engine scanning results, and structured reports.

[0057] For the embodiment of the present disclosure, the storage and visual display of APK metadata, multi-engine scanning results, and structured reports in step 360 of the embodiment may include the following steps: Step 360 - 1 : Structural processing is performed on the APK metadata, multi-engine scanning results, and structured reports, and they are stored in a relational database according to a preset data table structure.

[0058] For the embodiments of the present disclosure, structured storage of security detection data can be achieved through data modeling and relationship mapping: the system first standardizes APK metadata (such as package name, version number), multi-engine scanning results (such as each engine's detection conclusion, threat type) and structured reports (such as risk level, repair suggestions), extracts key fields (such as risk_level, engine_name) and establishes association relationships between entities (such as the APK_METADATA table is associated with the SCAN_RESULTS table through scan_id); then, data mapping is performed according to the preset relational data table structure (such as MySQL's apk_info, engine_scans, and security_risks tables), converting unstructured text into two-dimensional table records that conform to the paradigm to ensure data integrity and consistency; finally, the related data is written to the database through a transaction mechanism, and an index is established (such as a clustered index based on risk_level) to support subsequent fast query and statistical analysis, providing basic support for security situation monitoring and historical data comparison.

[0059] Step 360-2: Generate a multi-dimensional chart based on the APK metadata, multi-engine scanning results, and structured reports. The multi-dimensional chart is used to visually display at least one of the following: risk level distribution, comparison of positive rates of each detection engine, and historical version risk trends.

[0060] For the disclosed embodiments, data visualization technology can be used based on the stored APK metadata, multi-engine scanning results and structured reports to present the security status of APK files from multiple dimensions. Specifically, the system can first extract key data from the database, such as generating a risk level distribution pie chart based on the risk level data in the structured report, visually showing the proportion of high-risk, medium-risk and low-risk risks; by counting the number of positive results of each detection engine in the multi-engine scanning results, a bar chart is drawn to compare the positive rates of different engines, making it easy to view the differences in detection sensitivity of each engine; and then, combined with the version information in the APK metadata and the corresponding scanning results, a line chart is generated to track the risk trends of historical versions, clearly presenting the evolution of application security performance. These multi-dimensional charts convert complex data into intuitive images, helping users quickly understand the security situation of APK files and provide visual support for decision-making.

[0061] In summary, the technical solution in this application triggers the build task through the Jenkins REST API or python-jenkins library and automatically obtains APK metadata and files, which can realize parameterized configuration and unattended monitoring of the build process, eliminate manual export and parameter configuration errors, improve build efficiency and ensure metadata integrity; call the cloud virus scanning platform to support single-file binary stream upload and large file block upload, cover multiple risks through multi-engine parallel scanning, and solve the file size limitation problem through the block mechanism. At the same time, based on the scan task ID, real-time acquisition of scan results containing multi-dimensional data such as positive rate and risk behavior can significantly improve the comprehensiveness and accuracy of detection; use the scan results to generate a virus scan containing the sub- Analyze the prompt words of instructions and data fields, drive the large language model to generate structured reports, and convert raw data into high-risk risk points, code-level repair suggestions and false alarm analysis, which can reduce the technical threshold and decision-making costs of the security team; structured storage of detection data and generation of multi-dimensional charts such as risk level distribution and engine positive rate comparison, combined with natural language reports to achieve data visualization, non-technical personnel can quickly understand the impact of risks, historical trend analysis supports long-term security policy optimization, forming a full-process closed loop from construction, scanning, analysis to decision-making, improving overall detection efficiency, and effectively solving the core problems of traditional solutions such as process fragmentation, insufficient analysis capabilities and poor visualization.

[0062] Further, as Figure 2 and Figure 3 The specific implementation of the method shown in this embodiment provides a security detection device for Android applications, such as Figure 4 As shown, the device includes: an acquisition module 41, a processing module 42, a parsing module 43 and a storage and display module 44.

[0063] The acquisition module 41 can be used to trigger the APK build task by interacting with the Jenkins server and obtain the APK metadata and APK file when the APK build task is successfully completed; The processing module 42 may be used to call the cloud virus scanning platform to perform a multi-engine scan on the APK file and obtain the multi-engine scan result; The processing module 42 can be used to use a large language model to perform semantic analysis on the multi-engine scanning results and generate a structured report that at least includes high-risk risk points, code-level repair suggestions, and false positive analysis; The storage and display module 44 can be used to store and visualize APK metadata, multi-engine scanning results, and structured reports.

[0064] In some embodiments of the present application, the acquisition module 41 can be specifically used to use the Jenkins REST API or the python-jenkins library to send an APK build trigger request to the Jenkins server, and attach parameterized information in the APK build trigger request, and the parameterized information is used by the Jenkins server to respond to and execute the APK build task; after determining that the Jenkins server has received the APK build trigger request, the execution status of the APK build task in the Jenkins server is monitored in real time; when the execution status reflects that the APK build task has been successfully completed, the generated APK file is automatically downloaded from the storage path specified by the Jenkins server, and at the same time, the APK metadata containing the version number, environment variables and build time is extracted from the build environment variables or build log of the Jenkins server.

[0065] In some embodiments of the present application, Figure 5 As shown, the device may further include: an analysis module 45; The analysis module 45 can be used to collect the build failure log generated by the Jenkins server when the execution status reflects that the APK build task has failed, analyze the log content of the build failure log, extract and output key error information, and attach relevant parameters and timestamps of the APK build task.

[0066] In some embodiments of the present application, the processing module 42 can be specifically used to upload the APK file to the cloud server in the form of a binary stream, and after the upload is successful, receive the scanning task ID sent in response by the cloud server, and the cloud server is configured with a cloud virus scanning platform that provides multi-engine scanning services; based on the scanning task ID, the multi-engine scanning result is retrieved in the cloud server, and the multi-engine scanning result is obtained by multiple detection engines on the cloud virus scanning platform performing multi-engine scanning on the APK file.

[0067] In some embodiments of the present application, the processing module 42 can also be used to obtain the APK file size of the APK file and compare it with the maximum file limit supported by the corresponding application programming interface of the cloud virus scanning platform; if the APK file size exceeds the maximum file limit, the block upload mechanism is triggered to cut the APK file into multiple fixed-size file blocks, and generate a unique identifier and block metadata for each file block, and the block metadata at least includes a block number; each file block is uploaded to the cloud server block by block in the form of a binary stream, and carries the corresponding unique identifier and block metadata; after each file block is successfully uploaded, the file block scanning task ID sent by the cloud server in response is received, and the sub-scan data of each file block is queried based on the file block scanning task ID. The sub-scan data is obtained by multiple detection engines on the cloud virus scanning platform performing multi-engine scanning on the file block; based on the unique identifier and block metadata, the sub-scan data of each file block are spliced ​​in sequence to obtain the multi-engine scanning result of the APK file.

[0068] In some embodiments of the present application, the processing module 42 can be specifically used to generate prompt words containing preset fields based on the multi-engine scanning results, where the prompt words are semantic inputs that can be understood by the large language model, and at least include analysis instructions, data field placeholders, and output format requirements; the prompt words and the multi-engine scanning results are input into the large language model to trigger the semantic parsing and knowledge reasoning process to generate original text output containing high-risk points, code repair suggestions, and false alarm analysis; the original text output is structured, and the high-risk points, code repair suggestions, and false alarm analysis are respectively mapped to the preset data field positions of the structured report template to obtain a structured report.

[0069] In some embodiments of the present application, the storage and display module 44 can be used to perform structured processing on APK metadata, multi-engine scanning results, and structured reports, and store them in a relational database according to a preset data table structure; based on the APK metadata, multi-engine scanning results, and structured reports, a multi-dimensional chart is generated, and the multi-dimensional chart is used to visually display at least one of the following: risk level distribution, comparison of the positive rates of each detection engine, and historical version risk trends.

[0070] It should be noted that for other corresponding descriptions of the functional units involved in the security detection device for Android applications provided in this embodiment, please refer to Figure 2 and Figure 3 The corresponding description in will not be repeated here.

[0071] Based on the above Figure 2 and Figure 3 The method shown in FIG. 1 is a method for performing the above-mentioned operation. Accordingly, this embodiment further provides a storage medium on which a computer program is stored. When the program is executed by a processor, the above-mentioned Figure 2 and Figure 3 The security detection method of Android applications shown in Figure 2 is shown in Figure 2.

[0072] Based on this understanding, the technical solution of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, USB flash drive, mobile hard disk, etc.), and includes a number of instructions for enabling an electronic device (which can be a personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of the present application.

[0073] Based on the above Figure 2 and Figure 3 The method shown, and Figure 4 and Figure 5 In order to achieve the above-mentioned purpose, the embodiment of the present application further provides an electronic device, which can be a personal computer, a tablet computer, a server, or other network equipment, etc. The device includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to achieve the above-mentioned Figure 2 and Figure 3 The security detection method of Android applications shown in Figure 2 is shown in Figure 2.

[0074] Optionally, the physical device may also include a user interface, a network interface, a camera, a radio frequency (RF) circuit, a sensor, an audio circuit, a Wi-Fi module, and the like. The user interface may include a display screen and an input unit such as a keyboard. Optional user interfaces may also include a USB interface and a card reader interface. Optionally, the network interface may include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0075] Those skilled in the art will understand that the above-mentioned physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or a combination of certain components, or different component arrangements.

[0076] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the physical device, supporting the execution of information processing programs and other software and / or programs. The network communication module is used to enable communication between components within the storage medium, as well as with other hardware and software within the physical information processing device.

[0077] Through the description of the above implementation methods, those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform, or by hardware.

[0078] The embodiment of the present invention triggers the build task through the Jenkins REST API or python-jenkins library and automatically obtains APK metadata and files, which can realize parameterized configuration and unattended monitoring of the build process, eliminate manual export and parameter configuration errors, improve build efficiency and ensure metadata integrity; call the cloud virus scanning platform to support single file binary stream upload and large file block upload, cover multiple risks through multi-engine parallel scanning, and solve the file size limitation problem through the block mechanism. At the same time, based on the scan task ID, the scan results containing multi-dimensional data such as positive rate and risk behavior are obtained in real time, which can significantly improve the comprehensiveness and accuracy of detection; the scan results are used to generate a virus scan containing the sub- Analyze the prompt words of instructions and data fields, drive the large language model to generate structured reports, and convert raw data into high-risk risk points, code-level repair suggestions and false alarm analysis, which can reduce the technical threshold and decision-making costs of the security team; structured storage of detection data and generation of multi-dimensional charts such as risk level distribution and engine positive rate comparison, combined with natural language reports to achieve data visualization, non-technical personnel can quickly understand the impact of risks, historical trend analysis supports long-term security policy optimization, forming a full-process closed loop from construction, scanning, analysis to decision-making, improving overall detection efficiency, and effectively solving the core problems of traditional solutions such as process fragmentation, insufficient analysis capabilities and poor visualization.

[0079] Those skilled in the art will understand that the accompanying drawings are only schematic diagrams of a preferred implementation scenario, and the modules or processes in the accompanying drawings are not necessarily required to implement the present application. Those skilled in the art will understand that the modules in the devices in the implementation scenario can be distributed in the devices of the implementation scenario according to the implementation scenario description, or can be changed accordingly and located in one or more devices different from the implementation scenario. The modules of the above-mentioned implementation scenario can be combined into one module, or can be further split into multiple sub-modules.

[0080] The serial numbers of the above application are for descriptive purposes only and do not represent the advantages or disadvantages of the implementation scenarios. The above disclosure only discloses several specific implementation scenarios of the present application, but the present application is not limited thereto. Any changes that can be conceived by those skilled in the art should fall within the scope of protection of the present application.< / string>

Claims

1. A security detection method for Android applications, characterized in that: The method is applied to an Android application security detection system, and the method includes: By interacting with the Jenkins server, triggering the APK build task, and obtaining the APK metadata and APK file when the APK build task is successfully completed; Calling a cloud-based virus scanning platform to perform a multi-engine scan on the APK file to obtain a multi-engine scan result; Using a large language model to perform semantic analysis on the multi-engine scanning results, generating a structured report that at least includes high-risk risk points, code-level remediation suggestions, and false positive analysis; The APK metadata, the multi-engine scanning results, and the structured report are stored and visually displayed.

2. The method according to claim 1, characterized in that The process of interacting with the Jenkins server to trigger the APK build task and obtaining the APK metadata and APK file upon successful completion of the APK build task includes: Use the Jenkins REST API or the python-jenkins library to send an APK build trigger request to the Jenkins server, and attach parameterized information to the APK build trigger request. The parameterized information is used by the Jenkins server to respond and execute the APK build task; After determining that the Jenkins server receives the APK build trigger request, monitoring the execution status of the APK build task in the Jenkins server in real time; When the execution status reflects that the APK build task has been successfully completed, the generated APK file is automatically downloaded from the storage path specified by the Jenkins server, and at the same time, APK metadata including version number, environment variables and build time is extracted from the build environment variables or build log of the Jenkins server.

3. The method according to claim 1, characterized in that The method further comprises: When the execution status reflects that the APK build task has failed, the build failure log generated by the Jenkins server is collected, the log content of the build failure log is analyzed, and key error information is extracted and output, along with relevant parameters and timestamps of the APK build task.

4. The method according to claim 1, wherein Call the cloud virus scanning platform to perform a multi-engine scan on the APK file to obtain the multi-engine scan results, including: Uploading the APK file to a cloud server in binary stream form, and receiving a scan task ID sent in response by the cloud server after the upload is successful. The cloud server is equipped with a cloud virus scanning platform that provides multi-engine scanning services; A multi-engine scanning result is retrieved from the cloud server based on the scanning task ID, where the multi-engine scanning result is obtained by performing a multi-engine scan on the APK file by multiple detection engines on the cloud virus scanning platform.

5. The method according to claim 3, characterized in that The calling of the cloud virus scanning platform to perform a multi-engine scan on the APK file to obtain a multi-engine scan result further includes: Obtaining the APK file size of the APK file and comparing it with the maximum file size supported by the corresponding application programming interface of the cloud virus scanning platform; If the APK file size exceeds the maximum file limit, a block upload mechanism is triggered to cut the APK file into multiple fixed-size file blocks, and generate a unique identifier and block metadata for each file block, where the block metadata includes at least a block number; Uploading each file block to the cloud server in the form of a binary stream, along with the corresponding unique identifier and the block metadata; After each file block is successfully uploaded, receiving the scanning task ID of each file block sent in response by the cloud server, and querying sub-scan data of each file block based on the scanning task ID of each file block, wherein the sub-scan data is obtained by performing a multi-engine scan on the file block by multiple detection engines on the cloud virus scanning platform; Based on the unique identifier and the block metadata, the sub-scan data of each file block are sequentially spliced ​​to obtain a multi-engine scanning result of the APK file.

6. The method according to claim 1, wherein The multi-engine scanning results are semantically parsed using a large language model to generate a structured report containing at least high-risk points, code-level remediation suggestions, and false positive analysis, including: Generate a prompt word containing preset fields based on the multi-engine scanning results, where the prompt word is a semantic input understandable by a large language model and at least includes an analysis instruction, a data field placeholder, and an output format requirement; Input the prompt words and the multi-engine scanning results into a large language model, triggering the semantic parsing and knowledge reasoning process to generate raw text output containing high-risk points, code repair suggestions, and false positive analysis; The original text output is structured, and the high-risk points, the code repair suggestions, and the false positive analysis are respectively mapped to the preset data field positions of the structured report template to obtain a structured report.

7. The method according to claim 1, characterized in that Storing and visually displaying the APK metadata, the multi-engine scanning results, and the structured report, including: Structuring the APK metadata, the multi-engine scanning results, and the structured report, and storing them in a relational database according to a preset data table structure; Based on the APK metadata, the multi-engine scanning results and the structured report, a multi-dimensional chart is generated, and the multi-dimensional chart is used to visually display at least one of the following: risk level distribution, comparison of positive rates of each detection engine, and historical version risk trends.

8. A security detection device for Android applications, characterized in that: include: The acquisition module is used to trigger the APK build task by interacting with the Jenkins server and obtain the APK metadata and APK file when the APK build task is successfully completed; A processing module, configured to call a cloud-based virus scanning platform to perform a multi-engine scan on the APK file and obtain a multi-engine scan result; A parsing module, configured to perform semantic parsing on the multi-engine scanning results using a large language model, and generate a structured report containing at least high-risk points, code-level remediation suggestions, and false positive analysis; The storage and display module is used to store and visually display the APK metadata, the multi-engine scanning results and the structured report.

9. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

10. An electronic device comprising a storage medium, a processor, and a computer program stored in the storage medium and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.

Images