GitHub + ACR 全周期发布管控

• Outcome: Review
• Latest audit: Sep 16, 2026 · 9:19 AM UTC
• Version: 2.1.0

Overview

This release skill is coherent and disclosed, but it gives agents broad release and deployment authority with weak scoping around git staging, triggers, and root SSH deployment.

Review this skill before installing in a real release environment. Use explicit invocation phrases, require review of the exact staged file list and diff before any push, run secret scanning, and replace root SSH deployment with a dedicated least-privilege deploy account or CI/CD-controlled deployment path.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:230

Finding

Unrestricted repository staging may expose sensitive files

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:166 and SKILL.md:230
Vulnerability Type: Unrestricted Git staging and insufficient secret-exposure prevention
Risk Level: Medium

bash

git add -A
git commit
git push

The Skill identifies .gitignore as merely advisory at SKILL.md:166, despite acknowledging that its absence can cause sensitive files to be uploaded. It subsequently instructs the agent to stage every modified, deleted, and untracked file with git add -A at SKILL.md:230.

Technical Analysis

git add -A recursively stages all repository changes. If the project contains an unignored .env file, API token, registry credential, SSH key, generated configuration, database backup, or unrelated local artifact, that file will be included in the release commit.

The requirement for user confirmation before external operations does not specify that the agent must display and obtain approval for the exact staged file list. A general release confirmation therefore may not provide the operator with enough information to detect accidental credential inclusion.

The Skill also does not require a secret scanner, validate ignore rules, or use an allowlist of release files before pushing.

Attack Path

1. A sensitive or attacker-planted file is created within the project directory.
2. The file is not excluded because .gitignore is missing or incomplete.
3. The operator invokes the standard release workflow.
4. The Skill executes git add -A, staging the sensitive file alongside legitimate release changes.
5. The operator approves the general release without reviewing the complete staged diff.
6. The Skill commits and pushes the file to GitHub.
7. Anyone with repository access, and potentially the public, can retrieve the exposed data from Git history.

Impact Assessment

This issue can disclose repository-local secrets and sensitive project data. Exposed credentials may subseq ...[truncated 391 chars]

Remediation

View remediation

Remediation Suggestions

1. Make a reviewed .gitignore mandatory before permitting a release.
2. Replace git add -A with an allowlist of explicitly intended files or directories.
3. Display git status --short before staging and git diff --cached --stat plus git diff --cached afterward.
4. Require explicit approval of the staged file list rather than relying only on general release confirmation.
5. Run a secret scanner such as Gitleaks or TruffleHog against both the working tree and staged changes.
6. Reject common sensitive file types, including .env, private keys, credential files, database backups, and cloud-provider configuration, unless individually approved.
7. If exposure occurs, rotate affected credentials immediately and purge sensitive content from Git history and downstream caches.

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:382

Finding

Remote deployment procedure recommends direct root SSH access

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:232 and SKILL.md:382
Vulnerability Type: Excessive deployment privileges
Risk Level: High

bash

ssh root@HOST "cd PATH && docker compose pull && up -d"

The documented remote deployment procedure connects directly to the target server as root and executes Docker Compose operations. This grants the deployment channel unrestricted administrative access to the host rather than limiting it to the application and deployment directory.

Technical Analysis

Direct root SSH access violates least-privilege principles. Possession or misuse of the deployment credential provides control over the entire server, not merely the deployed application.

Docker deployments are already security-sensitive because Compose definitions can mount host directories, expose the Docker socket, add Linux capabilities, run privileged containers, or override entry points. Executing an attacker-modified Compose configuration through a root SSH session compounds this risk.

User confirmation before SSH execution reduces accidental automation but does not constrain privileges, validate the Compose file, verify the image provenance, or protect against compromised SSH credentials.

Attack Path

1. An attacker compromises the repository, release configuration, container registry, deployment image, or root SSH credential.
2. The attacker introduces a malicious image or modifies the Compose definition to mount host paths, access the Docker socket, or execute a hostile command.
3. The operator invokes and confirms the documented remote deployment procedure.
4. The Skill connects to the deployment server as root.
5. Docker Compose pulls and launches the attacker-controlled image or configuration.
6. The malicious workload accesses host resources and establishes control with administrative scope.

Alternatively, theft of the documented deployment key would allow an att ...[truncated 701 chars]

Remediation

View remediation

Remediation Suggestions

1. Create a dedicated, unprivileged deployment account and disable direct root SSH login.
2. Restrict deployment SSH keys by source address, expiration, permitted command, and environment.
3. Grant only narrowly scoped permissions required to update the specific application.
4. Avoid broad passwordless sudo; if elevation is unavoidable, allowlist exact commands and fixed paths.
5. Validate Compose files before deployment and reject privileged mode, Docker socket mounts, unexpected host mounts, host networking, and excessive capabilities.
6. Pin container images by immutable digest and verify image signatures or attestations before deployment.
7. Protect SSH host-key verification and reject unknown or changed host keys.
8. Keep deployment configuration in a root-owned or otherwise protected directory that the deployment account cannot arbitrarily rewrite.
9. Record deployment actions in centralized audit logs and maintain a tested rollback procedure.

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (5)

Vague Triggers

High

• Category: Not specified by scanner
• Confidence: 96% confidence

Finding

The trigger list includes very broad everyday terms such as “发布”, “push”, and “检查”, which can match ordinary user conversation and unintentionally invoke a high-impact release workflow. In this skill’s context, accidental activation is especially dangerous because the documented flow includes git push, tagging, CI/CD builds, remote deployment, and post-deploy actions, so a false trigger could lead to unintended operational changes.

Content

No source excerpt is available for this finding.

Vague Triggers

High

• Category: Not specified by scanner
• Confidence: 97% confidence

Finding

The skill metadata advertises very broad trigger words such as '发布', '检查', and '热更新', which are common words in normal developer conversation. Because this skill can lead into release, git, image push, and deployment workflows, accidental invocation could cause the agent to enter a high-impact operational flow unexpectedly.

Content

No source excerpt is available for this finding.

Vague Triggers

High

• Category: Not specified by scanner
• Confidence: 98% confidence

Finding

The trigger table uses short, ambiguous phrases like '检查', '发布', 'push', and '下版本' without contextual constraints. In a multi-skill environment, such generic triggers can misroute unrelated user requests into a workflow that performs sensitive repository and deployment actions, increasing the risk of unintended code pushes, tagging, or deployment preparation.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

• Category: Not specified by scanner
• Confidence: 85% confidence

Finding

标题及全文均以中文作为唯一交互与说明语言，未见提供语言/locale 选择或征求用户偏好的描述。按规则，若技能强制特定语言但无用户 opt-in 或正当的地域合规说明，属于自然语言层面的策略问题。

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

• Category: Not specified by scanner
• Confidence: 90% confidence

Finding

技能描述全文以中文规定触发词和交互方式，但未说明是否支持用户选择其他语言，也未给出这是面向特定中文团队或区域场景的合理限制。按组织语言/区域政策，这可能构成未经用户选择即强制特定语言的自然语言策略问题。

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.