腾讯营销 datanexus sdk 接入助手

• Outcome: Review
• Latest audit: May 26, 2026, 9:45 AM
• Version:
  1.0.1

Overview

This SDK helper is mostly purpose-aligned, but it can write analytics/tracking code and mishandles secrets in generated plans, so it needs careful review before installation.

Install only if you are comfortable reviewing every generated change before applying it. Do not paste production secrets unless you understand they may appear in generated code or /tmp plan files, and do not commit those files without redaction. Before using the automation, verify privacy consent gating, URL sanitization, requested permissions, and whether the SDK is allowed under your app-store and regional compliance requirements.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (25)

Intent-Code Divergence

Medium

• Confidence: 96% confidence
• Finding: The protocol explicitly says secret_key must not be committed or broadly exposed, yet it also instructs that generated code may contain a literal secret by default. In an auto-editing workflow, this creates a realistic path for credentials to be written into source files, checked into git, leaked via diffs, IDE history, or shared repositories, directly undermining the stated safety boundary.

Intent-Code Divergence

Medium

• Confidence: 93% confidence
• Finding: The README gives conflicting security assurances: it first states that `校验数据源配置.py` calls the DataNexus API, but later claims all scripts make no external network requests and support fully offline execution. In a security-sensitive SDK integration workflow, this can cause operators or agents to run a script under false assumptions about data flow, which may expose project metadata or credentials to a remote service contrary to user expectations.

Intent-Code Divergence

Medium

• Confidence: 98% confidence
• Finding: The CLI explicitly tells users that the secret_key will not be written to disk, but the generated plan embeds that secret into code snippets and the full JSON is written when --output is used. This creates a direct secret disclosure risk through local files, IDE artifacts, logs, backups, or accidental commits, and the misleading help text increases the chance users will handle the key unsafely.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The FAQ explicitly instructs developers to call `GDTAction.start()` to begin collecting personal/device information and says the SDK cannot work normally without it, but it provides no warning about consent, privacy notices, platform policy constraints, or applicable legal disclosure requirements. In an SDK integration assistant, this omission is materially risky because developers may implement tracking exactly as shown and collect identifiers or device data before obtaining valid user permission, creating compliance and privacy exposure.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The document explicitly instructs developers to call `GDTAction.start()` to begin personal information collection, but it does not pair that instruction with privacy, consent, disclosure, retention, or transmission safeguards. In an SDK integration guide, this omission can lead downstream app developers to enable device/user data collection by default without implementing legally required notice and consent flows, increasing privacy and compliance risk.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The guide recommends sensitive permissions such as `READ_PHONE_STATE` and `WRITE_EXTERNAL_STORAGE` for attribution optimization, but it does not clearly warn about the privacy impact, reduced necessity, or safer alternatives. This can cause developers to over-request high-risk permissions, exposing device identifiers or storage access beyond what is strictly needed and increasing abuse, compliance, and app-store rejection risk.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The FAQ explicitly instructs developers to report `open_url` values and references device identifiers/IDFA handling, but it does not pair that guidance with minimization, consent, or privacy-notice requirements. Full URLs can contain tokens, referral data, PII, or deep-link secrets, so encouraging collection/transmission without safeguards can lead to privacy violations and unintended leakage.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The document exposes an interface to retrieve CAID, which is an identifier tied to device/user tracking, but provides no accompanying privacy notice, consent requirements, permitted-use constraints, or data-handling guidance. In an SDK integration assistant, this omission is risky because developers may implement identifier collection by copy/pasting documentation and unintentionally violate platform privacy rules, consent requirements, or internal compliance expectations.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The guide explicitly instructs automatic collection of app/activity events such as foreground/background and startup behavior, but provides no requirement to obtain user consent, present a privacy notice, or gate collection based on platform/privacy settings. In an SDK integration context this is dangerous because developers may implement telemetry exactly as shown, leading to non-compliant data collection and privacy violations at scale.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The examples send the full URL in an `open_url` parameter for URL Scheme and Universal Links flows. Full URLs commonly contain tokens, auth codes, invitation identifiers, email addresses, campaign parameters, or other sensitive data, so forwarding them verbatim to analytics systems can leak secrets and personal data into logs, storage, and downstream processing.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The guide tells integrators to obtain and use a `secretKey` and later shows initialization with a literal secret string, but gives no warning about secure storage, rotation, or keeping secrets out of source control and client binaries. In a mobile SDK guide, this can normalize embedding long-lived credentials in an app, making reverse engineering and credential extraction more likely.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The document instructs developers to embed a `secret_key` directly in client-side小游戏 code and demonstrates setting persistent user identifiers such as `openid` and `unionId` without any warning about secure handling, minimization, or privacy obligations. In this context, the issue is more dangerous because this is an SDK integration guide: readers are likely to copy the example verbatim, which can expose credentials to client extraction and encourage collection of regulated identifiers without consent or protection.

Missing User Warnings

Medium

• Confidence: 86% confidence
• Finding: The guide shows direct use of `track()` to upload gameplay or behavior events but does not warn implementers that this constitutes collection and transmission of user behavioral data that may trigger consent, disclosure, and compliance requirements. In an SDK onboarding document, omission of these notices increases the chance of silent telemetry deployment, making the skill context materially more dangerous because it operationalizes data collection for downstream apps.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The guide enables automatic collection of user/game events and directs developers to inspect live network transmission, but it does not warn about privacy, consent, disclosure, or minimization requirements. In an SDK integration context, this omission can cause adopters to collect and transmit behavioral data by default without ensuring lawful notice and configuration, creating privacy and compliance risk.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The instructions tell developers to initialize the SDK with a secret_key plus persistent identifiers such as openid, unionid, and user_unique_id, but provide no warning about secure storage, exposure risk, or key-management boundaries. In a developer-facing skill, this is dangerous because readers may embed secrets client-side or mishandle identifiers, enabling credential leakage, unauthorized data submission, and privacy violations.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The documentation instructs developers to initialize the SDK with sensitive identifiers and a `secret_key`, and to set `openid`/`unionid` while enabling automatic tracking, but it does not clearly disclose that these values and collected events are transmitted to `api.datanexus.qq.com`. In a mini-program context, this can lead to unsafe credential handling, privacy non-compliance, and inadvertent exposure of personal data because developers may embed secrets client-side or collect identifiers without adequate user notice and consent.

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: The documentation instructs developers to initialize a mini-program SDK with a `secret_key` directly in client-side code. In a WeChat mini-program, client assets can be inspected or extracted, so embedding a long-lived secret exposes credentials that could let attackers forge telemetry, abuse the API, or impersonate the data source. Because this is an SDK integration guide, developers are likely to copy the example verbatim, increasing real-world exposure.

Missing User Warnings

High

• Confidence: 99% confidence
• Finding: Multiple framework-specific examples repeat the same insecure pattern of placing `secret_key` into front-end mini-program initialization code without any warning or safe alternative. Repetition across Taro, mpvue, uni-app, and Remax makes the issue more dangerous because it normalizes secret-in-client usage across ecosystems, likely leading many integrators to leak production credentials in distributed app packages.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The document explicitly instructs users to obtain and use a secret_key but provides no guidance on treating it as a sensitive credential. In an AI-assisted SDK integration context, this omission is risky because users may paste the key into source code, prompts, logs, or generated examples, leading to credential leakage and unauthorized use of the data source.

Missing User Warnings

Medium

• Confidence: 87% confidence
• Finding: The FAQ explicitly tells integrators to call start() to begin data collection, but it does not pair that guidance with any privacy, consent, or disclosure requirement. In an SDK-integration assistant, omission of consent guidance can lead developers to enable analytics collection immediately at app startup without validating lawful basis or user notice, creating real privacy and compliance risk.

Missing User Warnings

Medium

• Confidence: 81% confidence
• Finding: The FAQ discusses checking for SDK network requests and confirming successful uploads, but it does not clearly warn that analytics data is transmitted off-device and may contain user or device-related information. In the context of a data-collection SDK, this omission can cause developers to integrate reporting flows without adequate user disclosure, data-minimization review, or secure transport verification.

Missing User Warnings

High

• Confidence: 95% confidence
• Finding: Recommending OAID together with a tracking-related permission, without any warning about consent, platform policy, or privacy obligations, is a significant issue because OAID is a device identifier often used for tracking and attribution. In an SDK integration guide, this materially increases the chance that developers will implement persistent identifier collection in a non-compliant way, with heightened privacy, regulatory, and app-store enforcement risk.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: This documentation explicitly instructs developers to report user behavior data and lists automatically collected lifecycle events, but it provides no privacy notice, consent guidance, or data-minimization constraints. In an SDK integration assistant, that omission is risky because it can directly encourage deployments that collect telemetry without adequate user disclosure or lawful basis.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The interface documentation exposes use of a secret_key and a custom user identifier but does not warn that these are sensitive values that must be protected and handled carefully. In the context of an SDK onboarding skill, this can lead developers to hardcode secrets in client code or misuse persistent identifiers, creating credential exposure and privacy risks.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The guide instructs developers to initialize the SDK and immediately start automatic data collection, including app lifecycle events and optional OAID-related capabilities, but does not require any privacy notice, consent gating, or legal/compliance review before collection begins. In an SDK integration context, this omission is dangerous because developers may copy the example verbatim and deploy telemetry collection that violates privacy policies, platform rules, or applicable data protection laws.

VirusTotal

59/59 vendors flagged this skill as clean.