T09 · Insecure Skill Coding Practices
- Location
analyze.cjs:278- Finding
Unsubstantiated Security Ratings Can Encourage Installation of Unsafe Third-Party Skills
- Content
View full analysis
Vulnerability Details
File Location:
analyze.cjs:278-299
Vulnerability Type: Security decisions based solely on hardcoded popularity data
Risk Level: MediumVulnerable Code
js generateReport(skillNames) { const skills = skillNames.map(name => this.skillsDatabase[name]).filter(Boolean); if (skills.length === 0) { return "未找到相关技能"; } const topSkill = skills[0]; return `🎯 推荐技能: ${topSkill.name} (${topSkill.downloads.toLocaleString()}+ 下载, ⭐⭐⭐⭐⭐)\n✅ 安全评级: 高 (满足100/3规则)\n📋 功能: ${topSkill.description}\n🚀 安装: ${topSkill.installCmd}`; } securityCheck(skillName) { const skill = this.skillsDatabase[skillName]; if (!skill) { return "未找到指定技能"; } const meets100Rule = skill.downloads >= 100; const safetyRating = meets100Rule ? "高" : "需要谨慎评估"; return `🛡️ 安全评估: ${skill.name}\n- 下载量: ${skill.downloads.toLocaleString()}\n- 安全评级: ${safetyRating}\n- 建议: ${meets100Rule ? "可以安全使用" : "建议先在测试环境验证"}`; }Technical Analysis
The security check equates a hardcoded download count of at least 100 with a high security rating and an affirmative recommendation that the skill is safe to use. The generated recommendation likewise assigns five stars and a high security rating without inspecting the recommended package.
Download volume is not evidence of code integrity or safety. The implementation does not verify the package publisher, immutable version, package digest, requested permissions, dependency tree, source code, installation instructions, or malware indicators. The catalog's popularity and safety values are static and may become stale or may not correspond to the package currently available under the displayed slug.
The documentation also describes permission analysis and malware scanning, but those controls are not implemented in the reviewed code. Consequently, users may interpret a popularity heuristic as a substantive security assessment.
...[truncated 1584 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace categorical statements such as “safe to use” and “high security rating” with an explicit popularity-only assessment until substantive security validation is implemented.
- Retrieve current package metadata from an authoritative registry rather than relying on hardcoded download and rating values.
- Verify package identity using the publisher, exact version, cryptographic digest, and signed provenance where available.
- Pin installation recommendations to an audited immutable version or digest instead of an unqualified mutable slug.
- Inspect package source code, installation hooks, dependencies, requested permissions, external network destinations, and executable instructions before assigning a security rating.
- Integrate real malware and reputation checks only if their results are actually obtained and validated. Clearly report unavailable or inconclusive checks.
- Use a multi-factor risk model and present each factor separately. Popularity may be one informational signal but must not independently establish safety.
- Add freshness timestamps and fail closed when registry data, provenance, or integrity information cannot be verified.
- Require explicit confirmation before offering installation guidance and warn that third-party skills execute with the permissions granted by the user or agent runtime.
- Update
README.mdandSKILL.mdso documented security capabilities accurately match the implemented controls.