Security audit

Alibabacloud Dataworks Infra Manage

Security checks across malware telemetry and agentic risk

Overview

This appears to be a real DataWorks management skill, but it needs review because its documentation includes broader cloud, billing, credential, and workspace-member authority than its stated scope requires.

Install only if you intend to let an agent help operate Alibaba Cloud DataWorks through your Aliyun CLI. Use a least-privilege RAM policy that excludes workspace member APIs unless you explicitly need them, avoid BSS payment permissions unless creating billable resource groups, confirm the active Aliyun profile/account/region/workspace before every write, and do not paste real database passwords, access keys, or refresh tokens into chat, command lines, logs, or committed files.

SkillSpector

By NVIDIA

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands

Findings (27)

Description-Behavior Mismatch

Low

Confidence: 94% confidence
Finding: The guide tells users to verify authentication with `aliyun ecs describe-regions`, which exercises ECS permissions outside the skill's declared DataWorks-only scope. Even though the command is read-only, it normalizes broader cloud access and may encourage configuration or testing with credentials that have unnecessary ECS privileges, undermining least-privilege boundaries.

Context-Inappropriate Capability

Low

Confidence: 92% confidence
Finding: Directing users to run an ECS service command in DataWorks infrastructure documentation expands the apparent operational scope of the skill beyond what is justified. In practice this can lead operators to grant or validate unnecessary ECS access for the agent workflow, increasing the blast radius if credentials are later misused or the skill is extended unsafely.

Description-Behavior Mismatch

Medium

Confidence: 95% confidence
Finding: The document includes workspace member management permissions such as creating, deleting, and changing member roles even though the skill is declared to handle only DataWorks infrastructure management and explicitly excludes workspace member management. This creates scope creep and may cause operators to provision broader RAM permissions than necessary, enabling unauthorized identity and privilege administration if copied into production roles.

Description-Behavior Mismatch

Medium

Confidence: 98% confidence
Finding: The Full Access example grants project/member administration actions including CreateProjectMember, DeleteProjectMember, GrantMemberProjectRoles, and RevokeMemberProjectRoles, which exceed the manifest's stated capability set. Users commonly copy policy examples verbatim, so this overbroad sample can lead to unnecessary privilege assignment and unauthorized workspace membership or role changes.

Description-Behavior Mismatch

Low

Confidence: 90% confidence
Finding: Even the Read-Only example includes member visibility permissions such as ListProjectMembers, GetProjectMember, and ListProjectRoles, which are outside the stated purpose of the skill. While read-only access is less severe than write access, it still exposes organizational structure and role assignments that need not be available for datasource or resource-group management.

Description-Behavior Mismatch

Medium

Confidence: 97% confidence
Finding: The file documents workspace member-management APIs such as creating, deleting, granting, and revoking member roles, even though the skill metadata explicitly says workspace member management is out of scope. In an agent setting, related API docs often influence tool selection and action planning, so exposing privileged IAM-like operations can cause the agent to suggest or invoke access-control changes that were not intended by the skill boundary.

Vague Triggers

Medium

Confidence: 91% confidence
Finding: The trigger list contains broad phrases such as 'data source', 'resource group', and 'infrastructure initialization' that can match many ordinary cloud-administration requests. Because this skill includes write-capable operations that can create infrastructure and alter bindings, over-broad activation increases the chance the wrong skill is invoked and the user is steered into impactful actions in the wrong context.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The skill can create Serverless resource groups, a billing-affecting operation, but the user-facing description and flow do not prominently warn that this may incur charges before the action path begins. In a skill that performs infrastructure writes, insufficient upfront cost disclosure can lead to unintended paid resource creation, especially if combined with broad triggering and proactive next-step guidance.

Missing User Warnings

Medium

Confidence: 84% confidence
Finding: The guide includes multiple credential-bearing JSON and CLI examples that normalize placing raw usernames and passwords directly in documentation and command lines, but it does not warn that these values are sensitive or advise safer handling. In an agent skill context, users may copy these examples into shells, logs, chat transcripts, or version-controlled files, increasing the chance of credential exposure through command history, process listings, or stored documentation.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The README contains numerous credential-bearing examples using fields such as password, accessKey, accessId, refreshToken, and auth blobs, but it does not prominently warn users not to paste real secrets into docs, shells, logs, tickets, or version control. In an infrastructure-management skill, operators are likely to copy these templates directly during setup, increasing the chance of accidental secret exposure through command history, screenshots, transcripts, or committed configuration files.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The documentation explicitly provides an anonymous Elasticsearch connection example with `authEnable` set to `disable` and no accompanying warning about the risks of unauthenticated access. In an infrastructure-management skill, this can normalize insecure deployment patterns and lead users to connect DataWorks to exposed or weakly protected clusters, increasing the chance of unauthorized data access or accidental data exposure.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The documentation explicitly models credential handling with a plaintext `password` field and example values, but provides no guidance on secret storage, redaction, or avoiding hardcoding in configs and logs. In an infrastructure-management skill that configures live DataWorks data sources, this can normalize insecure handling of real database credentials and increase the chance of credential leakage through repos, shell history, or task logs.

Missing User Warnings

Medium

Confidence: 96% confidence
Finding: The documentation allows `authTypeNone` and describes it as 'No SSL' without warning that credentials and session data may be exposed to interception if connections traverse untrusted or misconfigured networks. Because this skill manages production infrastructure and database connectivity, presenting non-SSL authentication as a normal option can lead users to deploy insecure MongoDB connections into real environments.

Missing User Warnings

Medium

Confidence: 89% confidence
Finding: The documentation explicitly states that both AccessKey material and username/password are used, including for actual runtime data writing, but it provides no warning about secure secret handling, least-privilege scoping, storage practices, or the operational consequences of write-capable credentials. In an infrastructure-management skill that helps configure live DataWorks data sources, this omission can lead users to paste high-value credentials into unsafe locations or use overly privileged accounts, increasing the chance of credential leakage and unintended modification of production OpenSearch data.

Missing User Warnings

Medium

Confidence: 87% confidence
Finding: The document includes an AK authentication example with explicit `accessId` and `accessKey` fields but does not pair it with a clear warning about secret handling, storage, rotation, or avoidance in logs and source control. In an infrastructure-management skill that helps users configure live DataWorks data sources, this can normalize long-lived credential use and increase the chance that operators paste sensitive keys into prompts, config files, or versioned artifacts.

Missing User Warnings

Medium

Confidence: 93% confidence
Finding: The documentation explicitly requires sensitive secrets such as database passwords, truststore passwords, and keystore passwords, but provides no guidance on secure handling, storage, redaction, or use of secret-management mechanisms. In an infrastructure-management skill that is likely used operationally, this omission increases the chance that users place credentials directly in plaintext configs, logs, prompts, or version-controlled files.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The cross-account mode documents use of another cloud account ID and RAM role name without warning about least-privilege design, trust policy restrictions, or the risks of overbroad cross-account access. In a skill for managing DataWorks infrastructure, this is security-relevant because users may configure privileged role assumptions that expand blast radius across accounts if misconfigured.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The documentation explicitly instructs users to supply a plaintext `password` value without any warning about secret handling, storage, redaction, or use of a secrets manager. In an infrastructure-management skill that configures live data sources, this increases the likelihood that operators place credentials directly into examples, tickets, logs, shell history, or version-controlled config files, leading to credential disclosure.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The JSON example includes a `password` field in a realistic connection configuration but provides no accompanying warning that this value is a secret. Because this skill is specifically for provisioning and managing DataWorks infrastructure via CLI/API, users are especially likely to copy examples into automation or local files, where secrets can be exposed through repos, CI logs, command history, and support artifacts.

Missing User Warnings

Medium

Confidence: 89% confidence
Finding: The documentation explicitly requires a long-lived Salesforce refresh token but does not warn that it is a sensitive credential equivalent to durable API access. In an infrastructure-management skill, users may copy this value into configs, logs, or version control, increasing the chance of credential leakage and unauthorized access to Salesforce data.

Missing User Warnings

Medium

Confidence: 92% confidence
Finding: The sample JSON normalizes placing a refresh token directly in plaintext configuration without any warning that real credentials must not be embedded in files. Because this skill is for DataWorks infrastructure setup, users are especially likely to reuse the example in automation or repositories, creating a practical secret-exposure risk.

Missing User Warnings

Medium

Confidence: 93% confidence
Finding: The documentation presents authTypeNone as the default and uses it in examples without warning that this disables SSL protection for SQL Server connections. In an infrastructure-management skill that helps configure real DataWorks data sources, users may copy these examples directly, leading to plaintext or insufficiently protected database connections and increased risk of credential interception or man-in-the-middle attacks.

Missing User Warnings

Medium

Confidence: 83% confidence
Finding: The documentation includes concrete examples showing sensitive SSH authentication fields such as passwords, private key file identifiers, and key passphrases without any warning about secure handling, storage, masking, or rotation. In an infrastructure-management skill context, users are likely to paste real credentials into configs or logs, increasing the chance of credential leakage through screenshots, shell history, version control, or agent/tool output.

Missing User Warnings

Low

Confidence: 92% confidence
Finding: The documentation explicitly includes sensitive fields such as password and cross-account account identifiers, but provides no warning about secret handling, redaction, storage, or log exposure. In an agent skill that helps users configure real infrastructure through CLI/API flows, this increases the chance that operators paste real credentials into prompts, examples, shell history, tickets, or logs, leading to accidental credential disclosure.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The documentation includes `accessId` and `accessKey` as inline configuration fields and example values without explicitly warning that they are secrets that must not be hardcoded, logged, or committed to source control. In an infrastructure-management skill that helps users configure live DataWorks data sources, this increases the chance that operators will paste real credentials into configs, tickets, or repositories, leading to credential exposure and unauthorized access to TableStore resources.

VirusTotal

64/64 vendors flagged this skill as clean.

View on VirusTotal

Static analysis

No suspicious patterns detected.