CN113761517A

CN113761517A - Method, device, equipment and storage medium for determining third-party SDK

Info

Publication number: CN113761517A
Application number: CN202010492839.7A
Authority: CN
Inventors: 侯柳平
Original assignee: Baidu Online Network Technology Beijing Co Ltd
Current assignee: Baidu Online Network Technology Beijing Co Ltd
Priority date: 2020-06-03
Filing date: 2020-06-03
Publication date: 2021-12-07
Anticipated expiration: 2040-06-03
Also published as: CN113761517B

Abstract

The embodiment of the application discloses a method and a device for determining a third-party SDK, electronic equipment and a computer-readable storage medium, and relates to the field of personal privacy data protection. One embodiment of the method comprises: acquiring each actual SDK contained in the application program to be tested; determining a third-party SDK in each actual SDK by using a pre-constructed knowledge graph; the knowledge graph records the association relationship between each application program and the third-party SDK thereof. According to the embodiment, the knowledge graph technology which is applied to other fields is introduced into a new technical field for identifying the association between the application program and the SDK, and the more comprehensive association between the application program and the SDK can be found from a deeper level by means of the sorting and induction capability of the knowledge graph on the association between the application program and the SDK, so that an accurate identification result is obtained, and the safety risk control of the application program is realized.

Description

Method, device, equipment and storage medium for determining third-party SDK

Technical Field

The embodiment of the application relates to the technical field of feature recognition, in particular to the field of personal privacy data protection.

Background

With the development of electronic information technology, the privacy problem of personal data of users is more and more emphasized by society, and government departments are in turn making laws and regulations for personal information protection.

As stated, the operator of an Application (APP) has security responsibility for the behavior of personal information collected/content transferred/URL transferred by an SDK (Software Development Kit) integrated within its APP. The behavior of the APP developer for the own SDK (also called the first-party SDK) used by the APP developer is certainly clear, but the behavior of the third-party SDK used by the APP developer is little known, so that the APP is required to list the personal information categories and purposes collected by the third-party SDK one by one in the privacy policy of the APP. To meet this requirement, it is necessary to accurately identify which third-party SDKs are integrated in the APP in order to assess the security risk level of the third-party SDKs.

The prior art generally determines the third-party SDK in the APP by a feature matching method based on the SDK package name.

Disclosure of Invention

The embodiment of the application provides a method and a device for determining a third-party SDK, electronic equipment and a computer-readable storage medium.

In a first aspect, an embodiment of the present application provides a method for determining a third-party SDK, including: acquiring each actual SDK contained in the application program to be tested; determining a third-party SDK in each actual SDK by using a pre-constructed knowledge graph; and the knowledge graph records the association relationship between each application program and the third-party SDK thereof.

In a second aspect, an embodiment of the present application provides an apparatus for determining a third-party SDK, including: an actual SDK determining unit configured to acquire each actual SDK included in the application program to be tested; a third-party SDK determining unit configured to determine a third-party SDK of each of the actual SDKs using a pre-constructed knowledge graph; and the knowledge graph records the association relationship between each application program and the third-party SDK thereof.

In a third aspect, an embodiment of the present application provides an electronic device, including: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to cause the at least one processor to perform the method for determining a third party SDK as described in any one of the implementations of the first aspect when executed.

In a fourth aspect, embodiments of the present application provide a non-transitory computer-readable storage medium storing computer instructions for enabling a computer to implement a method for determining a third party SDK as described in any implementation manner of the first aspect.

In order to solve the problem that the conventional identification method by package names has a poor effect due to the complex association relationship between the SDK and the application program, embodiments of the present application provide a method, an apparatus, an electronic device, and a computer-readable storage medium for determining a third-party SDK: firstly, acquiring each actual SDK contained in an application program to be tested; then, determining a third-party SDK in each actual SDK by using a pre-constructed knowledge graph; the knowledge graph records the association relationship between each application program and the third-party SDK thereof.

According to the technical scheme, the knowledge graph technology applied to other fields is introduced into the new technical field of identifying the association between the application program and the SDK, and the knowledge graph is used for sorting and summarizing the association between the application program and the SDK with the help of the capability of the knowledge graph, so that the more comprehensive association between the application program and the SDK can be found from a deeper level, and a more accurate identification result is obtained, and the safety risk control of the application program is realized.

It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:

FIG. 1 is an exemplary system architecture to which the present application may be applied;

FIG. 2 is a flow diagram of one embodiment of a method for determining a third party SDK according to the present application;

FIG. 3 is a flow diagram of another embodiment of a method for determining a third party SDK according to the present application;

FIG. 4 is a schematic diagram of a constructed knowledgegraph in a method for determining third party SDKs provided herein;

FIG. 5 is a schematic diagram of a representation form of associated information between an APP and an SDK in a knowledge graph in the method for determining a third-party SDK provided by the present application;

FIG. 6 is a block diagram illustrating one embodiment of an apparatus for determining a third party SDK according to the present application;

fig. 7 is a block diagram of an electronic device suitable for implementing a method for determining a third party SDK of an embodiment of the present application.

Detailed Description

The present application will be described in further detail with reference to the following drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant invention and not restrictive of the invention. It should be noted that, for convenience of description, only the portions related to the related invention are shown in the drawings.

It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The present application will be described in detail below with reference to the embodiments with reference to the attached drawings.

Fig. 1 illustrates an exemplary system architecture 100 to which embodiments of the method, apparatus, electronic device, and computer-readable storage medium for determining a third party SDK of the present application may be applied.

As shown in fig. 1, the system architecture 100 may include

terminal devices

101, 102, 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the

terminal devices

101, 102, 103 and the server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

A user may use the

terminal devices

101, 102, 103 to interact with the server 105 over the network 104 to receive or transmit data or the like. Various applications for realizing data transmission between the

terminal devices

101, 102, 103 and the server 105 can be installed on the

terminal devices

101, 102, 103, for example, an application publishing class application, an application security inspection class application to be published, an instant messaging class application, and the like.

The

terminal apparatuses

101, 102, 103 and the server 105 may be hardware or software. When the

terminal devices

101, 102, 103 are hardware, they may be various electronic devices with display screens, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like; when the

terminal devices

101, 102, and 103 are software, they may be installed in the electronic devices listed above, and they may be implemented as multiple software or software modules, or may be implemented as a single software or software module, and are not limited in this respect. When the server 105 is hardware, it may be implemented as a distributed server cluster composed of multiple servers, or may be implemented as a single server; when the server is software, the server may be implemented as a plurality of software or software modules, or may be implemented as a single software or software module, which is not limited herein.

The server 105 may provide various services through various built-in applications, taking an application to be issued for providing the third-party SDK determination service as an example, when the server 105 runs the application to be issued, the following effects may be achieved: firstly, receiving an application program to be tested sent by

terminal equipment

101, 102 or 103 through a network 104, and then acquiring each actual SDK contained in the application program to be tested; and then, determining the third-party SDK in each actual SDK by utilizing a pre-constructed knowledge graph recorded with the association relation between each application program and the third-party SDK. That is, the server 105 determines the third-party SDK in the application to be executed through the above processing steps, and outputs the third-party SDK as a result. Further, the to-be-issued application security audit class application may also provide a targeted security risk test based on the output third-party SDK to finally determine whether the to-be-issued application conforms to the security rule, and return the notification to the

terminal device

101, 102, or 103.

It should be noted that, in addition to real-time reception from the

terminal devices

101, 102, and 103 via the network 104, the application to be tested may be pre-stored locally in the server 105 in various ways. Thus, when the server 105 detects that the data is already stored locally (e.g., there remains an application under test in the pending queue), the application under test may be obtained directly from the local, in which case the exemplary system architecture 100 may also not include the

terminal devices

101, 102, 103 and the network 104.

For the purpose of accurately determining the third-party SDK, the knowledge graph used in the present application needs to occupy more computing resources and have stronger computing power no matter how it is constructed and used, so the method for determining the third-party SDK provided in the subsequent embodiments of the present application is generally executed by the server 105 having stronger computing power and more computing resources, and accordingly, the device for determining the third-party SDK is generally disposed in the server 105. However, it should be noted that, when the

terminal devices

101, 102, and 103 also have computing capabilities and computing resources meeting the requirements, the

terminal devices

101, 102, and 103 may also complete the above-mentioned operations performed by the server 105 through the to-be-issued application security audit class application installed thereon, and then output the same result as the result of the server 105. Especially, when there are a plurality of terminal devices with different computing capabilities, if the application to be issued for security inspection determines that the terminal device has a strong computing capability and a large amount of computing resources are left, the terminal device may execute the above computation, thereby appropriately reducing the computing pressure of the server 105. Correspondingly, the means for determining the third party SDK may also be provided in the

terminal device

101, 102, 103. In such a case, the exemplary system architecture 100 may also not include the server 105 and the network 104.

It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

With continuing reference to fig. 2, an implementation flow 200 of one embodiment of a method for determining a third party SDK according to the present application is shown, including the steps of:

step 201: acquiring each actual SDK contained in the application program to be tested;

this step is intended to acquire each actual SDK included in the application under test by an executing agent (e.g., the server 105 shown in fig. 1) of the method for determining the third-party SDK.

Specifically, in the step, in the execution process, the first-hand data may be divided into two types according to the specific type of the first-hand data, one of which is that, when the first-hand data acquired by the execution main body is an application program to be tested (which will be hereinafter referred to as APP to be tested for short), the operation of determining each actual SDK included in the first-hand data may be executed by the execution main body, or the execution main body may forward the received APP to be tested to other execution main bodies to complete and receive the determination result, where the feature of each actual SDK included in the first-hand data may be used to determine, without limitation, the packet name, the flow feature, the code feature, and the like of the SDK; secondly, when the execution main body can directly acquire each actual SDK included in the APP to be tested, that is, when the first-hand data is the list/set including each actual SDK, the execution main body only needs to receive a ready-made result, and does not need to perform other operations.

It should be understood that the purpose of this step is to obtain an actual SDK list/set of which SDKs are actually included in the APP to be tested, so as to subsequently determine which SDKs in the actual SDK list/set belong to the third-party SDKs in the APP to be tested.

It should be noted that, which actual SDKs are included in an APP to be determined, but it does not mean that which actual SDKs belong to the third-party SDKs in the APP to be determined can be directly determined, because whether an actual SDK is the third-party SDK of the APP to be determined often depends on a lot of influence factors, and an accurate determination result can be obtained not only based on features of the surface layer, such as the SDK packet name and the flow rate.

It should be noted that the APP to be tested or each actual SDK included in the APP to be tested may be directly obtained from a local storage device by the execution main body, or may be obtained from a non-local storage device (for example,

terminal devices

101, 102, and 103 shown in fig. 1). The local storage device may be a data storage module arranged in the execution main body, such as a server hard disk, in which case, the APP to be tested or each actual SDK included in the APP to be tested may be read locally and quickly; the non-local storage device may also be any other electronic device configured to store data, for example, some user terminals, and in this case, the execution main body may obtain the required APP to be tested or each actual SDK included in the APP to be tested by sending an obtaining command to the electronic device.

Step 202: and determining the third-party SDK in each actual SDK by using a pre-constructed knowledge graph.

On the basis of step 201, this step is intended to determine the third-party SDK among the actual SDKs by the executing agent using the pre-constructed knowledge graph. For the purpose of the step, a knowledge graph recording the association relationship between each APP and the third-party SDK is constructed in advance.

It should be appreciated that having the ability to accurately identify third party SDKs is essential to the fields of APP security, privacy compliance, etc. But the number of APPs is numerous (on the order of tens of millions), and the total number of third party SDKs is also thousands. Identifying and obtaining information (developers, codes, features, and the like) of the APP or the SDK is relatively easy, that is, determining which SDKs are relatively easy to include in the APP based on the identified information of the SDK, and most difficult to determine how to determine the relationship between the SDK developer and the APP developer (for determining whether the own SDK or the third-party SDK is present), which cannot be obtained by analyzing the code of the APP itself, or by simple accumulation of knowledge, that is, how to determine which of the actual SDKs are third-party SDKs belonging to the APP to be measured is a current difficulty.

In order to solve the difficulty, the Knowledge Graph concept is introduced, the Knowledge Graph (Knowledge Graph) appears in the book information field at the earliest, is also called Knowledge domain visualization or Knowledge domain mapping map, is a series of different graphs for displaying the relation between the Knowledge development process and the structure, describes Knowledge resources and carriers thereof by using visualization technology, and excavates, analyzes, constructs, draws and displays Knowledge and the mutual relation between the Knowledge resources and the carriers. Current knowledge-graphs are mainly applied: search engines, social networking, human resources and recruitment, finance, insurance, retail, advertising, logistics, communications, IT, manufacturing, media, medical, e-commerce and logistics. Aiming at the field of risk control, the method is mainly applied to scenes such as anti-fraud, anti-money laundering, internet credit granting, insurance fraud, bank fraud, e-commerce fraud, project audit counterfeiting, enterprise relationship analysis, criminal tracing and the like.

Based on the characteristics of the knowledge graph, the knowledge graph formed by the nodes and the relations is used for visually modeling the APP and the SDK with complex association between the nodes and the SDK, so that a more visual and clear mesh knowledge structure is formed by analyzing and sorting the association between different knowledge. The process of forming this knowledge map is essentially creating the cognitive abilities of machines or automated devices to associate APP and SDK, and can make such cognitive abilities more and more powerful through the accumulation of knowledge.

To construct a knowledge graph that can achieve the objective of this step, it is necessary to find all possible information characterizing the association between APP and SDK from as many channels as possible, including but not limited to: version numbers of APP and SDK, package names, Application names, class name lists, method lists, certificate signatures, class signatures, applied authority lists, function call graphs, sensitive API (Application Programming Interface) call information, UI (User Interface) layout information, icons, Resource files, string resources, addresses and IP addresses accessed, URIs (Uniform Resource identifiers) built into programs, personal information protection policies (privacy policies), official addresses, at least one of official server address, historical version, distribution channel, user distribution, full name, alias, abbreviation, company property, country, company registration name, contact address, responsible person, operation range, establishment time, stock right relationship, subsidiary company information, parent company information and related company information of developer (manufacturer). Based on the above, different knowledge graphs are flexibly constructed by combining the construction sequence of the knowledge graphs and the actual requirements under the actual application scene, and the construction is not specifically limited here. Meanwhile, in order to guarantee the accuracy of the knowledge graph, the associated information in the knowledge graph can be updated and adjusted in an incremental mode according to a preset period, and therefore the adjustment workload is reduced as far as possible.

Further, in order to achieve highly accurate determination, besides relying on collecting more information and knowledge, the method also relies on deep processing of the acquired information and knowledge, taking "XX company" as an example, which may represent a plurality of registered company entities named "XX", and what meaning of the specific representation thereof needs to be analyzed and processed by comprehensively using natural language processing and data analysis technology.

Furthermore, since the third-party SDK is generally released to the outside in JAR or AAR format, the APP developer cannot read the source code, and therefore the APP developer does not know the full function and security risk of the third-party SDK. Meanwhile, the APP and the third-party SDK run in the same process, the two share the authority, the third-party SDK can collect personal information under the condition that a user or an APP developer does not know, malicious codes can be embedded, and the existing access control mechanism cannot distinguish the source of the personal information access request. Therefore, on the basis of accurately identifying the third-party SDK, in order to prevent the APP to be tested containing the third-party SDK with the safety risk from being issued to the intelligent mobile terminal of the user, the safety risk test can be performed on the third-party SDK based on the preset safety risk management and control standard so as to prevent the application program which does not meet the requirement from being issued to the user side.

The present embodiment provides a method for determining a third party SDK: firstly, acquiring each actual SDK contained in an application program to be tested; then, determining a third-party SDK in each actual SDK by using a pre-constructed knowledge graph; the knowledge graph records the association relationship between each application program and the third-party SDK thereof. In the embodiment, the knowledge graph technology applied to other fields is introduced into a new technical field for identifying the association between the application program and the SDK through the technical scheme, and by means of the sorting and induction capability of the knowledge graph on the association between the application program and the SDK, a more comprehensive association between the application program and the SDK can be found from a deeper level, so that a more accurate identification result is obtained, and the security risk control of the application program is realized.

On the basis of the above embodiment, the present application further provides another flow 300 of a method for determining a third-party SDK through fig. 3, and on the basis of the above embodiment, not only is a specific scheme for constructing a knowledge graph provided, but also a scheme for determining a security risk level of the third-party SDK and how to perform subsequent processing is provided based on the determined third-party SDK, including the following steps:

step 301: acquiring basic information from each known application program information base and a known SDK information base;

wherein the basic information includes and is not limited to: version number, package name, application name, class name list, method list, certificate signature, class signature, authority list of application, function call graph, sensory API call information, UI layout information, icon, resource file, character string resource, website and IP address of access, URI built in program, personal information protection policy (privacy policy), and the like. Besides being obtained directly from the information base, the basic information can be obtained by dynamic and static extraction of known APP and known SDK, so as to complement and improve accuracy by comparison.

Step 302: acquiring other information of each known application program and the known SDK from a preset public channel;

the other information refers to information obtained from various authoritative public channels, such as official websites of APP and SDK, various large APP markets, open source technology websites, mobile developer platforms, financial websites, national business administration websites, and the like. Specific other information includes, but is not limited to: APP and SDK files in various formats (e.g., APK, IPA, JAR, AAR, ZIP, etc.), package names, application names, official website addresses, official server addresses, historical versions, distribution channels, user distribution, full name of developer (vendor), alias, acronym, company nature, country, company registration name, contact address, principal, business scope, time of establishment, equity relationship, subsidiary information, parent information, related company information, etc.

Step 303: according to the basic information and other information, sorting to obtain the associated information between each application program and the first-party SDK and the third-party SDK respectively;

in this step, the execution subject arranges the basic information and other information obtained in

steps

301 and 302 to obtain the association information between each application program and its first party SDK (also called own SDK) and third party SDK.

Step 304: constructing according to the associated information and the characteristics of the knowledge graph to obtain the knowledge graph;

on the basis of step 303, this step aims to construct a knowledge graph according to the characteristics of the knowledge graph according to the associated information. In order to more intuitively understand the construction of the knowledge graph, the application also provides a schematic diagram corresponding to the scheme from step 301 to step 304, please refer to fig. 4.

Meanwhile, based on the characteristic that the knowledge graph uses nodes and relationships between the nodes to represent, main entities (nodes), important attributes and relationships in the knowledge graph are also exemplified:

(1) entity:

APP: the mobile application is also called APK format file under an Android system, and IPA format file under an IOS system;

and (3) SDK: is a software development kit, provides certain functions for the APP, such as: the GSON library of Google provides a JSON analysis function for the APP, and certain mobile statistic SDK provides free mobile application analysis statistics for the APP. The SDK may be generally divided into a first-party SDK and a third-party SDK, for example, for an APP, the first-party SDK is generally named as a certain mobile statistics SDK of the APP, and the GSON library is a third-party library (or called third-party SDK).

(2) Important attributes:

personal information protection policy: also called privacy policy, the personal information protection policy is responsible for explaining how the APP collects and protects personal information, and also should explain the main third party SDK contained in the APP;

APP name: generally contained within the APP file, such as "some map", "some trip", etc.;

APP package name: unique identification of APP, typically contained within APP files such as com.

Permission list: access to mobile devices and information typically requires operating system privileges, common sensitive system privileges such as: access camera authority, access body sensor authority, storage authority, short message read-write authority, acquisition geographic position authority and the like

Categories of APP and SDK: the categories classified according to functions are commonly classified as: map navigation, network car booking, instant messaging, network payment, news information, online shopping and the like

Signing the certificate: the APP certificate generally comprises a secret key, a valid year, the name of a publisher, a unit, a city where the publisher is located, a province, a country and other information;

class name: a list of class names in the APP and program libraries;

the method name is as follows: function name lists in APP and program libraries;

website address: the APP and the library may contain a large number of websites (or URIs, Uniform Resource identifiers) for implementing various functions, uploading data to the server, and the like;

official website: the APP and the program library generally have official websites which can provide development packages or download APP files, and provide technical support for developers and users;

company name: the authors of APPs and libraries are typically companies (also individuals or institutional developers) that are collectively referred to as company names for convenience. The company names are classified into full names and short names, the full names are generally names registered by the company, and the company may have a plurality of short names, such as 'a certain online network technology (Beijing) cable company' which can be called 'a certain company' for short;

(3) the important relationship is as follows:

the relationship between APP and library can be divided into first and third parties, for example: for a certain APP, a certain mobile statistic SDK is a first party program library, and a GSON library is a third party library;

company association relationship: for example, company A is a subsidiary of company B, so the map SDK released by company A is a first library of some APP released by company B;

name peer relationship: the full name and the short name are also alias names, such as "a certain online network technology (beijing) limited company" and "a certain company" can be regarded as different names of the same company. For another example: for a certain mobile statistics SDK, there may be multiple aliases (certain statistics SDK, xxxx _ static, etc.).

A schematic diagram of a mesh knowledge graph constructed based on the above example can be seen in fig. 5.

Step 305: acquiring each actual SDK contained in the application program to be tested;

step 306: determining a third-party SDK in each actual SDK by using a knowledge graph;

the above step 305-.

Step 307: determining an actual privacy risk level for the third-party SDK;

in this step, the actual privacy risk level of the third-party SDK determined in the executing subject determining step 306 is mainly used, that is, the actual privacy risk level of the third-party SDK is evaluated mainly against the threat of the third-party SDK to the personal privacy data of the user, and an evaluation rule or an evaluation standard may be preset, which is not specifically limited herein and can be flexibly formulated in combination with the actual situation.

Step 308: judging whether the actual privacy risk level of the third-party SDK is smaller than a preset level, if so, executing a step 309, otherwise, executing a step 310;

on the basis of step 307, this step is intended to determine whether the actual privacy risk level of the third party SDK is less than a preset level, where the preset level exists as a boundary for determining whether the third party SDK meets the security privacy requirement, and is included in a preset evaluation rule and an evaluation standard, and the actual parameter may be calculated based on a national standard or an industry standard.

Step 309: returning a notice that the application program to be tested meets the safety and privacy requirements;

this step is established on the basis that the determination result in step 308 is that the actual privacy risk level of the third-party SDK is smaller than the preset level, and under the condition that the APP to be detected only contains the third-party SDK, the actual privacy risk level of the third-party SDK is smaller than the preset level, it can be determined that the APP to be detected meets the security privacy requirement, and therefore, a notification that the APP to be detected meets the security privacy requirement is returned to one end where a detection request (for example, a terminal device that sends the APP to be detected) is initiated. Of course, if the APP to be tested contains a plurality of third-party SDKs, it is often necessary to determine that the APP to be tested meets the requirement of security privacy only when the actual privacy risk levels of all the third-party SDKs are less than the preset level.

Step 310: and returning a notice that the application program to be tested does not meet the safety privacy requirement.

This step is established on the basis that the determination result in step 308 is that the actual privacy risk level of the third-party SDK is not less than the preset level, and under the condition that the APP to be detected only contains the third-party SDK, the actual privacy risk level of the third-party SDK is not less than the preset level, it is determined that the APP to be detected does not comply with the security privacy requirement, and therefore a notification that the APP to be detected does not comply with the security privacy requirement is returned to one end that initiates a detection request (for example, a terminal device that sends the APP to be detected). Of course, if the APP to be tested contains a plurality of third-party SDKs, the actual privacy risk level of any third-party SDK is not less than the preset level, and the APP to be tested can be determined not to meet the requirement of the security privacy.

Further, for convenience of rectification, information of which third-party SDKs are determined to have an actual privacy risk level not less than a preset level due to which reasons can be returned at the same time. Meanwhile, in order to facilitate identification and subsequent unified processing, unqualified labels can be attached to the to-be-detected application programs with the actual privacy risk level not less than the preset level, and other safety detection information of all the application programs with the unqualified labels is recorded, so that whether other problems exist can be found from other angles through other safety detection information.

On the basis of containing the whole beneficial effects of the last embodiment, this embodiment provides a knowledge map construction scheme more specific, be convenient for carry out, also through the subsequent processing to third party's SDK, has accomplished the judgement whether to await measuring APP accords with safe privacy requirement simultaneously for whether the scheme that this application provided will be can directly obtain the APP that awaits measuring and satisfy the result in APP privacy audit, compliance field.

Further, considering that the information collected from various channels may overlap and be inconsistent, the problem can be solved as much as possible by performing a further processing on the information, and one of the processing methods, including but not limited to, may be:

carrying out standardization processing on various names, acronyms and non-standard sentences in the basic information and other information through a natural language understanding technology to obtain first standardized information;

carrying out knowledge extraction on various description information, privacy policies, file characteristics and the like in the basic information and other information, and carrying out standardization processing on the information obtained after the knowledge extraction to obtain second standardized information;

and according to the first standardized information and the second standardized information, the association information between each application program and the first party SDK and the third party SDK of each application program is obtained through arrangement.

By carrying out different standardization treatments on different types of information and assisting the knowledge extraction technology, the problem of inconsistent or conflicting information contents of different channels can be eliminated as much as possible.

In order to deepen understanding, the application also provides a specific implementation scheme by combining a specific application scene:

1) the APP publisher X sends the APP to be published to a security privacy audit server for publication and audit;

2) the safety privacy auditing server determines that the APP to be issued contains 4 SDKs in total through packet names, flow characteristics, code characteristics and the like, and the numbers are respectively referred to as 01, 02, 03 and 04;

3) the safety privacy auditing server sequentially inputs the information of each numbered SDK into a pre-constructed knowledge map;

4) the security privacy audit server finds out that:

the SDK with the number 01 and the APP to be issued have the same developer signature, so that the SDK with the number 01 is judged to belong to the own SDK (first-party SDK) of the APP to be issued;

the SDK with the number 02 is different from the APP to be published in official websites and company simple names, and the similarity of package names is obviously different, so that the SDK with the number 02 is judged to belong to a third-party SDK of the APP to be published;

the unique package name of the SDK with the number 03 appears in a product list of an official website of a developer of the APP to be published for many times, so that the SDK with the number 03 is judged to belong to an own SDK (first-party SDK) of the APP to be published;

through testing, the APP to be issued has all the resolution permissions of the SDK of the number 04, and therefore it is determined that the SDK of the number 04 belongs to the own SDK (first-party SDK) of the APP to be issued.

5) The safety privacy auditing server carries out safety privacy risk test on the third-party SDK of the code 02 according to a preset test case, finds that the third-party SDK is called privately after the APP to be issued runs for 10 minutes, sends the acquired personal account password of the user to a specified mailbox and stops, and therefore the third-party SDK with the serial number of 02 is judged to violate relevant safety privacy regulations;

6) the security privacy audit server returns an audit failure notice that the third party SDK containing the number 02 violates the relevant security privacy regulations to the APP developer X.

With further reference to fig. 6, as an implementation of the methods shown in the above-mentioned figures, the present application provides an embodiment of an apparatus for determining a third party SDK, where the embodiment of the apparatus corresponds to the embodiment of the method shown in fig. 2, and the apparatus may be applied to various electronic devices.

As shown in fig. 6, the apparatus 600 for determining a third party SDK of the present embodiment may include: an actual SDK determining unit 601, a third party SDK determining unit 602. The actual SDK determining unit 601 is configured to obtain each actual SDK included in the application to be tested; a third-party SDK determining unit 602 configured to determine a third-party SDK among the actual SDKs using a pre-constructed knowledge graph; the knowledge graph records the association relationship between each application program and the third-party SDK thereof.

In the present embodiment, in the apparatus 600 for determining a third party SDK: the detailed processing of the actual SDK determining unit 601 and the third-party SDK determining unit 602 and the technical effects thereof can refer to the related descriptions of

step

201 and 202 in the corresponding embodiment of fig. 2, which are not repeated herein.

In some optional implementations of this embodiment, the means 600 for determining a third party SDK may further include: a basic information acquisition unit configured to acquire basic information from each of the known application information base and the known SDK information base; the other information acquisition unit is configured to acquire other information of each known application program and the known SDK from a preset public channel; the associated information sorting unit is configured to sort and obtain associated information between each application program and the first party SDK and the third party SDK of the application program respectively according to the basic information and other information; and the knowledge map construction unit is configured to construct a knowledge map according to the associated information and the characteristics of the knowledge map.

In some optional implementations of this embodiment, the association information sorting unit may be further configured to: carrying out standardization processing on various names, acronyms and non-standard sentences in the basic information and other information through a natural language understanding technology to obtain first standardized information; carrying out knowledge extraction on various description information, privacy policies, file characteristics and the like in the basic information and other information, and carrying out standardization processing on the information obtained after the knowledge extraction to obtain second standardized information; and according to the first standardized information and the second standardized information, the association information between each application program and the first party SDK and the third party SDK of each application program is obtained through arrangement.

In some optional implementations of this embodiment, the means 600 for determining a third party SDK may further include: an actual privacy risk level determination unit configured to determine an actual privacy risk level of the third-party SDK after determining the third-party SDK; the notification issuing unit is configured to return a notification that the application program to be tested meets the safety privacy requirement when the actual privacy risk level is less than the preset level; and the non-compliance security privacy requirement notification sending unit is configured to return the notification that the application program to be tested does not comply with the security privacy requirement when the actual privacy risk level is not less than the preset level.

In some optional implementations of this embodiment, the means 600 for determining a third party SDK may further include: the unqualified label attachment unit is configured to attach an unqualified label to the application program to be tested, the actual privacy risk level of which is not less than the preset level; and the other safety detection information recording unit is configured to record other safety detection information of all the application programs with the unqualified labels.

In some optional implementations of this embodiment, the means 600 for determining a third party SDK may further include: and the incremental updating and adjusting unit is configured to perform incremental updating and adjusting on the associated information in the knowledge graph according to a preset period.

The device for determining the third-party SDK according to the embodiment introduces a new technical field of identifying the association between the application program and the SDK to the knowledge graph technology applied to other fields through the technical scheme, and finds a more comprehensive association relationship between the application program and the SDK from a deeper level by means of the sorting and induction capabilities of the knowledge graph on the association relationship between the application program and the SDK, so as to obtain an accurate identification result, thereby realizing security risk control of the application program.

According to an embodiment of the present application, an electronic device and a computer-readable storage medium are also provided.

Fig. 7 shows a block diagram of an electronic device suitable for implementing the method for determining a third party SDK of an embodiment of the application. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the present application that are described and/or claimed herein.

As shown in fig. 7, the electronic apparatus includes: one or more processors 701, a memory 702, and interfaces for connecting the various components, including a high-speed interface and a low-speed interface. The various components are interconnected using different buses and may be mounted on a common motherboard or in other manners as desired. The processor may process instructions for execution within the electronic device, including instructions stored in or on the memory to display graphical information of a GUI on an external input/output apparatus (such as a display device coupled to the interface). In other embodiments, multiple processors and/or multiple buses may be used, along with multiple memories and multiple memories, as desired. Also, multiple electronic devices may be connected, with each device providing portions of the necessary operations (e.g., as a server array, a group of blade servers, or a multi-processor system). In fig. 7, one processor 701 is taken as an example.

The memory 702 is a non-transitory computer readable storage medium as provided herein. Wherein the memory stores instructions executable by the at least one processor to cause the at least one processor to perform the method for determining a third party SDK provided herein. The non-transitory computer readable storage medium of the present application stores computer instructions for causing a computer to perform the methods for determining a third party SDK provided herein.

The memory 702, which is a non-transitory computer-readable storage medium, may be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as program instructions/modules corresponding to the method for determining a third party SDK in the embodiments of the present application (e.g., the actual SDK determining unit 601, the third party SDK determining unit 602 shown in fig. 6). The processor 701 executes various functional applications of the server and data processing by running non-transitory software programs, instructions, and modules stored in the memory 702, that is, implements the method for determining the third party SDK in the above method embodiment.

The memory 702 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store various types of data created by the electronic device in performing the method for determining the third party SDK, and the like. Further, the memory 702 may include high speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory 702 optionally includes memory located remotely from the processor 701, and such remote memory may be connected over a network to an electronic device adapted to perform the method for determining a third party SDK. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The electronic device adapted to perform the method for determining a third party SDK may further comprise: an input device 703 and an output device 704. The processor 701, the memory 702, the input device 703 and the output device 704 may be connected by a bus or other means, and fig. 7 illustrates an example of a connection by a bus.

The input device 703 may receive input numeric or character information and generate key signal inputs related to user settings and function control of an electronic apparatus suitable for performing a method for determining a third party SDK, such as a touch screen, keypad, mouse, track pad, touch pad, pointer stick, one or more mouse buttons, track ball, joystick or like input device. The output devices 704 may include a display device, auxiliary lighting devices (e.g., LEDs), and tactile feedback devices (e.g., vibrating motors), among others. The display device may include, but is not limited to, a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display, and a plasma display. In some implementations, the display device can be a touch screen.

Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, application specific ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.

These computer programs (also known as programs, software applications, or code) include machine instructions for a programmable processor, and may be implemented using high-level procedural and/or object-oriented programming languages, and/or assembly/machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), Wide Area Networks (WANs), and the Internet.

The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

According to the technical scheme provided by the embodiment of the application, the knowledge graph technology applied to other fields is introduced into the new technical field of identifying the association between the application program and the SDK, and the more comprehensive association between the application program and the SDK can be found from a deeper level by means of the sorting and induction capability of the knowledge graph on the association between the application program and the SDK, so that an accurate identification result is obtained, and the safety risk control of the application program is realized.

It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present application may be executed in parallel, sequentially, or in different orders, and the present invention is not limited thereto as long as the desired results of the technical solutions disclosed in the present application can be achieved.

The above-described embodiments should not be construed as limiting the scope of the present application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for determining a third party SDK, comprising:

acquiring each actual SDK contained in the application program to be tested;

determining a third-party SDK in each actual SDK by using a pre-constructed knowledge graph; and the knowledge graph records the association relationship between each application program and the third-party SDK thereof.

2. The method of claim 1, wherein constructing the knowledge-graph comprises:

acquiring basic information from each known application program information base and a known SDK information base;

acquiring other information of each known application program and the known SDK from a preset public channel;

according to the basic information and the other information, sorting to obtain the associated information between each application program and the first party SDK and the third party SDK of the application program respectively;

and constructing the knowledge graph according to the associated information and the characteristics of the knowledge graph to obtain the knowledge graph.

3. The method of claim 2, wherein the association information between each application and the first and third party SDKs respectively is obtained by sorting the basic information and the other information, including

Standardizing various names, acronyms and non-standard sentences in the basic information and the other information by a natural language understanding technology to obtain first standardized information;

carrying out knowledge extraction on various description information, privacy policies, file characteristics and the like in the basic information and the other information, and carrying out standardization processing on the information obtained after the knowledge extraction to obtain second standardized information;

and according to the first standardized information and the second standardized information, sorting to obtain the associated information between each application program and the first party SDK and the third party SDK of the application program respectively.

4. The method of claim 1, wherein after determining the third party SDK, further comprising:

determining an actual privacy risk level for the third-party SDK;

when the actual privacy risk level is smaller than a preset level, returning a notice that the application program to be tested meets the safety privacy requirement;

and when the actual privacy risk level is not less than the preset level, returning a notice that the application program to be tested does not meet the safety privacy requirement.

5. The method of claim 4, further comprising:

attaching an unqualified label to the application program to be tested, of which the actual privacy risk level is not less than the preset level;

and recording other safety detection information of all the application programs attached with the unqualified labels.

6. The method of any of claims 1 to 5, further comprising:

and updating and adjusting the associated information in the knowledge graph in an incremental manner according to a preset period.

7. An apparatus for determining a third party SDK, comprising:

an actual SDK determining unit configured to acquire each actual SDK included in the application program to be tested;

a third-party SDK determining unit configured to determine a third-party SDK of each of the actual SDKs using a pre-constructed knowledge graph; and the knowledge graph records the association relationship between each application program and the third-party SDK thereof.

8. The apparatus of claim 7, further comprising:

a basic information acquisition unit configured to acquire basic information from each of the known application information base and the known SDK information base;

the other information acquisition unit is configured to acquire other information of each known application program and the known SDK from a preset public channel;

the associated information sorting unit is configured to sort and obtain associated information between each application program and the first-party SDK and the third-party SDK of the application program according to the basic information and the other information;

a knowledge graph constructing unit configured to construct the knowledge graph according to the associated information and the characteristics of the knowledge graph.

9. The apparatus of claim 8, wherein the association information collating unit is further configured to:

10. The apparatus of claim 7, further comprising:

an actual privacy risk level determination unit configured to determine an actual privacy risk level of the third-party SDK after determining the third-party SDK;

the notification issuing unit is configured to return a notification that the application program to be tested meets the safety privacy requirement when the actual privacy risk level is less than a preset level;

and the non-compliance security privacy requirement notification sending unit is configured to return the notification that the application program to be tested does not comply with the security privacy requirement when the actual privacy risk level is not less than the preset level.

11. The apparatus of claim 10, further comprising:

an unqualified label attachment unit configured to attach an unqualified label to the application program to be tested, the actual privacy risk level of which is not less than the preset level;

and the other safety detection information recording unit is configured to record other safety detection information of all the application programs attached with the unqualified labels.

12. The apparatus of any of claims 7 to 11, further comprising:

and the incremental updating and adjusting unit is configured to perform incremental updating and adjustment on the associated information in the knowledge graph according to a preset period.

13. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method for determining a third party SDK of any of claims 1-6.

14. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method for determining a third party SDK of any of claims 1-6.